fix(payments): align PaymentSetups with the spec

[armando-rodriguez-cko]

Summary
Two PaymentSetups alignment fixes: (1) the confirm endpoint's path parameter was named payment_method_option_id, a name that does not exist in the API and so could never work against the server — renamed to payment_method_name, matching POST /payments/setups/{id}/confirm/{payment_method_name}; (2) documented the billing_descriptor, presentment_details and terminal sub-schemas, which this client (hash-based, no typed request/response classes) previously modeled with no doc-only YARD classes at all, unlike the existing account_funding_transaction sub-schema.

Changes

• lib/checkout_sdk/payments/setups/payment_setup_billing_descriptor.rb (new) — YARD doc class: name, city, reference
• lib/checkout_sdk/payments/setups/payment_setup_presentment_details.rb (new) — YARD doc class: amount, currency
• lib/checkout_sdk/payments/setups/payment_setup_terminal.rb (new) — YARD doc class: id, local_date_time
• lib/checkout_sdk/payments/payments.rb — require the three new files
• lib/checkout_sdk/payments/setups/payment_setups_client.rb — confirm_payment_setup param renamed payment_method_option_id → payment_method_name (signature, path build, docs)
• spec/checkout_sdk/payments/setups/payment_setups_client_spec.rb — updated confirm test, added round-trip coverage for the three new fields
• spec/checkout_sdk/payments/setups/payment_setups_helper.rb — sandbox request builder includes billing_descriptor/presentment_details
• spec/checkout_sdk/payments/setups/payment_setups_integration_spec.rb — renamed param throughout, added assertions on the new response fields

The confirm response already returns the raw API payload as-is (no typed/slimmer shape to misalign), so no fix was needed there.

API Reference

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

Breaking changes
None — the old confirm parameter name never worked against the real API, so no working caller can regress; the rest is additive documentation.

README
No README changes needed.

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:All changes are non-destructive documentation additions (new YARD-only classes), a bug-fix rename of a method parameter that never worked (no behavioral change to callers), and corresponding test updates — no new endpoints, persisted data, auth changes, or external integrations are introduced.

Operational gates

• ✅ jira_ticket (INT-1669)
• ✅ independent_review

Files analysed: 8

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[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.
2.2.6_logical_extension — All changes are non-destructive documentation additions (new YARD-only classes), a bug-fix rename of a method parameter that never worked (no behavioral change to callers), and corresponding test updates — no new endpoints, persisted data, auth changes, or external integrations are introduced.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

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

[agent-wall-e]

✅ Auto-approved — this PR meets all Low-risk criteria.

All checks passed, no unresolved comments, and the change classification is:

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:The change renames a broken path parameter to match the actual API spec, adds three doc-only YARD classes with no new persisted data or external integrations, and updates tests accordingly — all within existing code paths and abstractions without crossing any trust boundary.

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}