feature/INT-1724 - CashApp payment method integration

[david-ruiz-cko]

This pull request introduces support for the Cash App payment method in the payment setup flow, along with enhancements to customer and device information handling. It adds new model classes for Cash App-specific data, extends device and customer models with additional fields, and improves test coverage for these features. The main changes are grouped below.

Cash App Payment Method Integration:

• Added a new CashApp payment method model, including support for customer profile sharing, actions, and customer profile details, with associated classes such as CashAppCustomerProfile, CashAppAddress, CashAppAction, and CashAppActionType. (lib/Checkout/Payments/Setups/Common/PaymentMethods/CashApp/CashApp.php [1] CashAppCustomerProfile.php [2] CashAppAddress.php [3] CashAppAction.php [4] CashAppActionType.php [5]
• Registered the CashApp payment method in the PaymentMethods class, allowing it to be serialized and used like other payment methods. (PaymentMethods.php [1] [2]

Customer and Device Model Enhancements:

• Extended the Customer model with new optional fields: id, country, and tax_number, improving support for customer identification and compliance. (Customer.php lib/Checkout/Payments/Setups/Common/Customer/Customer.phpR10-R65)
• Enhanced the Device model with new fields: fingerprint, ipv4, ipv6, client (with enum via DeviceClient), and os (with enum via DeviceOs), supporting richer device context for risk and eligibility checks. (Device.php [1] DeviceClient.php [2] DeviceOs.php [3]

Payment Method Base Improvements:

• Documented and clarified the meaning of status, flags, and initialization fields in PaymentMethodBase, including their possible values and usage. (PaymentMethodBase.php lib/Checkout/Payments/Setups/Common/PaymentMethods/Common/PaymentMethodBase.phpR8-R29)

Test Coverage:

• Added new integration tests to verify the correct handling and echoing of device fields, customer identifiers, and the Cash App payment method in payment setup requests and responses. (PaymentSetupsIntegrationTest.php test/Checkout/Tests/Payments/Setups/PaymentSetupsIntegrationTest.phpR143-R219)
• Added a unit test for confirming a payment setup with Cash App. (PaymentSetupsClientTest.php test/Checkout/Tests/Payments/Setups/PaymentSetupsClientTest.phpR118-R139)

These changes collectively enable richer customer and device data handling and introduce full support for the Cash App payment method in the payment setup workflow.

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• exceeds_bounded_scope:400>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 14

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
exceeds_bounded_scope — 400>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟢 Advisory review: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Adds CashApp payment method support with new model classes, extends Customer and Device models with new fields, adds enum helpers, and covers everything with unit and integration tests. The implementation is consistent and matches the stated intent.

What I checked

• New CashApp, CashAppCustomerProfile, CashAppAddress, CashAppAction, CashAppActionType classes are all coherent and correctly namespaced.
• DeviceClient and DeviceOs enum classes use static string properties consistently with the existing pattern in the codebase.
• PaymentMethodStatus and PaymentMethodInitialization enum helpers are added and their values match the documented API enums in PaymentMethodBase.
• CashApp is correctly registered in PaymentMethods.php under the property name 'cashapp', which matches both the serialization key and the confirm-endpoint path segment used in the client test.
• The integration test for CashApp correctly uses markTestSkipped when the sandbox channel does not have Cash App enabled, avoiding false failures.
• The serialization test explicitly checks that customer_profile_sharing: false is preserved (not stripped as null), which is an important correctness guard for the boolean field.
• The truncated diff means the full PaymentSetupFieldsSerializationTest body was not visible, but the visible portions look correct and targeted.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• exceeds_bounded_scope:434>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 14

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
exceeds_bounded_scope — 434>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• exceeds_bounded_scope:477>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 16

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
exceeds_bounded_scope — 477>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
22 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud