[rodrigojara-cko]

Summary

The PaymentSetup schema nests the card fields under payment_methods.card.details and types the Apple Pay and Google Pay token as an object. The SDK sent the card fields at the top level of the card object and the wallet token as a string, so the API ignored them. This adds the spec shape, keeps the old card attributes as deprecated, and adds the missing auto_confirm, metadata and instrument.type.

Changes

• checkout_sdk/payments/setups/setups.py:
  • Card: adds details (CardDetails, the 11 card fields), token (CardToken), schemes and preferred_scheme. The flat attributes (number, last4, bin, scheme, expiry_month, expiry_year, name, cvv, stored, expires_on, allow_update) are deprecated: they are kept until the next major version, and their docs say the API does not read them at that level, so details must be used.
  • ApplePay, GooglePay: token is now a WalletToken (id, expires_on). The flat expires_on is deprecated in favour of token.expires_on. Adds schemes and preferred_scheme.
  • New enums PaymentSetupCardScheme (17 values) and GooglePayPreferredScheme (visa, mastercard). Card and Apple Pay reuse PreferredSchema.
  • PaymentMethods.auto_confirm, PaymentSetupsRequest.metadata, and the read-only PaymentSetupInstrument.type.
  • excluded_payment_methods is documented as a list of payment method names.
• tests/payments/setups/payment_setups_serialization_test.py: literal wire keys, roundtrip and spec-shaped bodies for every new property, the deprecated attributes still being declared, the Apple Pay token_data.header in the wallet roundtrip, and enum completeness.

API Reference

• POST /payments/setups
• PUT /payments/setups/{id}
• GET /payments/setups/{id}
• POST /payments/setups/{id}/confirm/{payment_method_name}

Breaking changes

Forced by the API, so this is a minor release, to be called out in the release notes: ApplePay.token and GooglePay.token change from str to WalletToken. A string token was never accepted by the API, so nothing that worked stops working. Every other replaced attribute is kept as a deprecated attribute.

README

No change needed.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:277>250

Operational gates

• ✅ jira_ticket (INT-1725)
• ✅ independent_review

Files analysed: 2

---

_{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 — 277>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.

The PR restructures payment setup request shapes to match the API spec, but the truncated diff reveals a typo (PreferredSchem instead of PreferredSchema) in the ApplePay class definition, and the diff is incomplete so other issues may exist.

Concerns

• In the truncated ApplePay class definition, preferred_scheme: PreferredSchem is missing the trailing 'a' — this is a NameError at runtime when ApplePay is instantiated or serialized with preferred_scheme set.
• The diff is truncated at the ApplePay.preferred_scheme annotation and again mid-test (card = s), so the full extent of changes cannot be verified — the reviewer must inspect the complete file to confirm no further issues exist.
• The deprecated flat card attributes (number, last4, etc.) on the Card class are described as kept, but the truncated diff does not show their retention in setups.py; the reviewer should confirm they still exist as annotations on Card itself (not just on CardDetails).
• The PaymentSetupInstrument.type field is annotated readOnly in the SDK yet is included in the class body — the reviewer should confirm serialization logic skips read-only fields to avoid sending type in PUT/POST request bodies.
• The test file imports CardDetails, CardToken, WalletToken, PaymentSetupCardScheme, GooglePayPreferredScheme from setups.py — these must all be exported from that module's __init__ or the imports will fail at test time; the diff does not show the __init__.py update.

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

Operational gates

• ✅ jira_ticket (INT-1725)
• ✅ independent_review

Files analysed: 2

---

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

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket (INT-1725)
• ✅ independent_review

Files analysed: 2

---

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

[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