fix(payments): align PaymentSetups confirm param with the spec

[armando-rodriguez-cko]

Summary
The PaymentSetups 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 the real path POST /payments/setups/{id}/confirm/{payment_method_name}. Also corrected the (currently skipped) confirm integration test, whose expected response fields modeled a payments-charge shape (action_id/processed_on) instead of the actual PaymentSetup response the endpoint returns.

Changes

• checkout_sdk/payments/setups/setups_client.py — confirm_payment_setup() param renamed payment_method_option_id → payment_method_name (signature, path build)
• tests/payments/setups/payment_setups_client_test.py — updated confirm test to use the correct param name
• tests/payments/setups/payment_setups_integration_test.py — renamed var and corrected the confirm response's expected fields to the PaymentSetup shape

Verified separately: the create/update request already models billing_descriptor, presentment_details, terminal, and this client has no typed response models to misalign (responses are dynamic/raw), so no further changes were needed for those.

API Reference

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

Breaking changes
None — the old parameter name never worked against the real API, so no working caller can regress.

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:The change is a pure parameter rename in an existing function signature and path construction, reusing the same endpoint and code path with no new integrations, data persistence, or auth changes.

Operational gates

• ✅ jira_ticket (INT-1669)
• ✅ independent_review

Files analysed: 3

---

_{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 — The change is a pure parameter rename in an existing function signature and path construction, reusing the same endpoint and code path with no new integrations, data persistence, or auth changes.	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 is a pure parameter rename to align a broken path parameter with the actual API spec, reusing existing code paths and abstractions without any new endpoints, persistence, auth changes, or external integrations.

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