feature/INT-1724 - CashApp payment method integration

[david-ruiz-cko]

This pull request adds comprehensive support for Cash App Pay in the payment setups API and enhances the handling and serialization of customer device and identification fields. It updates the public API documentation, adds new integration and serialization tests, and ensures that the new fields are correctly processed and echoed by the API.

Cash App Pay support:

• Added support for Cash App Pay in payment setups, including serialization/deserialization of payment_methods.cashapp, its actions, and customer profiles. Includes tests for request/response structure and round-trip serialization. [1] [2] [3]
• Added integration and unit tests to verify Cash App Pay setup, confirmation, and the handling of Cash App–specific fields and actions. [1] [2] [3]

Customer device and identification fields:

• Added support for new customer.device fields (fingerprint, ipv4, ipv6, client, os) and ensured they are accepted and echoed by the API. Also added tests for these fields. [1] [2]
• Added support for customer.id, customer.country, and customer.tax_number, with tests to verify round-trip serialization and correct field mapping. [1] [2]

API documentation improvements:

• Enhanced docstrings for the create_payment_setup, update_payment_setup, get_payment_setup, and confirm_payment_setup methods in setups_client.py to clarify usage, arguments, and Cash App Pay–specific behavior. [1] [2] [3]

These changes ensure robust support for Cash App Pay and new customer fields, with thorough test coverage and improved documentation for API consumers.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1069>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 5

---

_{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 — 1069>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: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

Adds Cash App Pay support, new customer device/identification fields, and improved docstrings to the payment setups API. The change looks technically sound — new enums, data classes, tests, and serialization all appear self-consistent — but correctness of the wire format (especially the cashapp key name and field names like customer_profile_sharing) against the actual Cash App Pay API spec cannot be verified from the diff alone.

For you to decide

• The serialization test asserts the wire key is exactly "cashapp" (not cash_app or cashApp) and "customer_profile_sharing" — a reviewer should confirm this matches the live API spec, since a key-name mismatch would silently drop the payment method.
• The CashAppAction, CashAppAddress, CashAppCustomerProfile, and CashAppActionType classes are imported and used in serialization tests but their definitions are in the truncated portion of setups.py; a reviewer should verify these are actually defined and not just stubs.
• The integration test test_should_create_payment_setup_with_cash_app uses getattr(response, 'available_payment_methods', []) with pytest.skip — this guard means the test will never fail even if Cash App is misconfigured, so the skip condition should be validated as the right signal for the sandbox environment.
• The integration tests for customer.device fields (fingerprint, ipv4, ipv6, client, os) assert the API echoes them back verbatim, which assumes the sandbox echoes all fields — a reviewer should confirm this is true and not environment-specific behaviour.
• CashApp.initialization defaults to 'disabled' per the serialization test; a reviewer should confirm this default is intentional and won't silently disable Cash App when a caller creates a CashApp() object but forgets to set initialization.
• The diff is truncated and the actual class bodies for CashApp, CashAppAction, CashAppCustomerProfile, PaymentMethods (with cashapp field), and PaymentSetupsRequest are not visible — full correctness of field mapping and serializer behaviour cannot be confirmed without seeing those definitions.

⚠️ 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:1074>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 5

---

_{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 — 1074>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:1070>250

Operational gates

• ✅ jira_ticket (INT-1724)
• ✅ independent_review

Files analysed: 5

---

_{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 — 1070>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
0 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