Release 6.7.0 - CashApp payment method integration

[david-ruiz-cko]

This release introduces several enhancements and new features to the payment setup entities, with a focus on improving support for the Cash App Pay payment method and refining the customer data model. The main changes include adding new models and properties for Cash App integration, restructuring customer-related entities for better clarity and extensibility, and improving documentation throughout the codebase.

Cash App Pay Integration:

• Added the CashApp payment method, including models for customer profile sharing, action handling, and address details (CashApp, CashAppCustomerProfile, CashAppAction, CashAppAddress). This enables full support for Cash App Pay, including handling customer consent and profile data. [1] [2] [3] [4]
• Updated the PaymentMethods class to support the new CashApp payment method, including explicit JSON property mapping for correct serialization.

Customer Entity Refactoring:

• Refactored the Customer class to move CustomerEmail and CustomerDevice into their own files and classes, improving modularity and clarity. Introduced new properties such as Id and Country, and marked BillingAddress as obsolete in favor of using PaymentSetupsRequest.Billing. [1] [2] [3] [4]
• Added new enums CustomerDeviceClient and CustomerDeviceOs to capture device client type and operating system, enhancing device information granularity. [1] [2]

Payment Method Status Improvements:

• Expanded and documented the PaymentMethodStatus enum to align with the latest API specification, adding new statuses such as action_required, ready, initialization_required, and invalid.
• Improved documentation and property descriptions in PaymentMethodBase, including additional details for status, flags, and initialization fields.

General Enhancements:

• Enhanced XML comments and documentation across customer and payment method models for better clarity and maintainability. [1] [2]

These changes collectively improve the SDK's support for modern payment methods, especially Cash App Pay, and lay the groundwork for more robust customer and device data handling.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{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
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

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.

The diff provided shows only a version bump from 6.6.0 to 6.7.0, but the PR description claims substantial new code (CashApp payment integration, Customer refactoring, new enums, PaymentMethodStatus changes). The actual implementation changes are not visible in this diff.

For you to decide

• The diff is partial — it contains only Directory.Build.props but the PR description references multiple new files and modified classes; a reviewer cannot verify correctness of the implementation from this diff alone.
• The human reviewer must confirm that all described changes (CashApp models, Customer refactoring, CustomerDeviceClient/CustomerDeviceOs enums, PaymentMethodStatus additions, obsolete BillingAddress marking) are actually present and correct in the full changeset before approving.
• The version bump itself (6.6.0 → 6.7.0) is consistent with the claimed scope of changes (new payment method, model refactoring), but whether this warrants a minor rather than patch version is a product/semver policy decision the human must verify.

---

_{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
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