feature/INT-1724 - CashApp payment method integration

[david-ruiz-cko]

This pull request introduces support for the Cash App Pay payment method and enhances customer and device data models to support new payment flows and risk checks. The most important changes are summarized below:

Cash App Pay Integration:

• Added the CashApp payment method, including its configuration, initialization state, customer profile sharing, and next action handling, to PaymentMethods and as a new class with supporting entities (CashAppAction, CashAppActionType, CashAppCustomerProfile, CashAppAddress). [1] [2] [3] [4] [5] [6] [7]

Customer and Device Model Enhancements:

• Extended the Customer model to include id, country, and taxNumber fields, and improved documentation for all fields. [1] [2]
• Enhanced the CustomerDevice model by adding fields for fingerprint, ipv4, ipv6, client (with a new enum CustomerDeviceClient), and os, and improved field descriptions. [1] [2] [3]

Common Types and Documentation Improvements:

• Improved the OsType enum documentation and clarified its use across wallet payment methods and customer devices.
• Expanded the PaymentMethodStatus enum with additional statuses and detailed documentation for each value.

These changes collectively enable Cash App Pay support and improve the flexibility and clarity of customer and device data handling.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:435>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 — 435>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: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

Adds Cash App Pay payment method integration with supporting model changes and serialization tests; the implementation looks broadly correct but there is a concrete serialization bug and a questionable default in the CashApp model.

Concerns

• CashApp.java sets a default field value private PaymentMethodInitialization initialization = PaymentMethodInitialization.DISABLED; — Gson serializes the current field value at serialization time, not the absence of a value, so every outbound request that omits initialization will silently send "initialization":"disabled" to the API even when the caller never set it, which could suppress a Cash App setup that would otherwise default to enabled on the server.
• PaymentMethods.java field is named cashapp with a comment explaining that the naming policy would turn cashApp into cash_app — this is a valid workaround, but the field name cashapp is all-lowercase which is unusual in a Java class; more importantly, if the global naming policy is LOWER_CAMEL_TO_LOWER_UNDERSCORE then cashapp serializes as cashapp (no underscore, correct), but the comment's claim should be verified against the actual Gson naming policy configured in GsonSerializer, since the correctness of the whole cashapp key depends on it.
• CashAppCustomerProfile.java stores birthDate and customerSince as raw Strings with a comment explaining the provider format may vary — this is a deliberate choice, but reviewers should confirm it aligns with SDK conventions for other date fields and that downstream consumers are warned.
• The IT test createPaymentSetupWithCustomerIdentifiers_ShouldEchoThem calls request.getCustomer().setId(...) etc. after building the request, which requires Customer to be mutable via setters (not final/immutable) — this works with Lombok @DaTa but is worth a reviewer noting as inconsistent with the builder pattern used elsewhere.
• The IT test createPaymentSetupWithDeviceDetails_ShouldEchoDeviceAndReadEveryStatus asserts device.getIpv6() is NOT checked (only ipv4 is asserted), leaving ipv6 round-trip coverage absent in the integration test.
• No migration or backward-compatibility note covers the PaymentMethodStatus enum additions (INITIALIZATION_REQUIRED, INVALID) — if existing code switches exhaustively on this enum without a default, adding values is a compile break for callers on older SDK versions; the existing test correctly adds cases but the risk to SDK consumers should be acknowledged.

⚠️ 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}

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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