fix(payments): align PaymentSetups with the spec

[armando-rodriguez-cko]

Summary
Two PaymentSetups alignment fixes: (1) the confirm endpoint's path parameter description still referenced "payment method option" though the underlying param was already correctly named payment_method_name in code — the docstring/description text is now consistent; (2) documented the billing_descriptor, presentment_details and terminal sub-schemas on the create/update/get request and response bodies, which were previously undocumented (this SDK models request/response shapes via JSDoc prose, not typed classes).

Changes

• src/api/payment-setups/payment-setups.js — JSDoc for billing_descriptor/presentment_details/terminal added to createAPaymentSetup, updateAPaymentSetup, getAPaymentSetup; confirm endpoint's description/param doc corrected to match its already-correct payment_method_name parameter
• test/payment-setups/payment-setups-unit.js — added coverage for the three documented fields round-tripping on create, and for the confirm URL building with payment_method_name

API Reference

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

Breaking changes
None — documentation and test additions only; no runtime behavior changed.

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 diff contains only JSDoc comment additions and test coverage for existing endpoints, with no runtime behavior, new endpoints, new data persistence, or auth changes.

Operational gates

• ✅ jira_ticket (INT-1669)
• ✅ independent_review

Files analysed: 2

---

_{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 diff contains only JSDoc comment additions and test coverage for existing endpoints, with no runtime behavior, new endpoints, new 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}

[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 diff contains only JSDoc comment additions and test coverage for already-existing parameters/endpoints, with no runtime behavior, auth, persistence, or new integrations changed.

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

[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