fix(setups): send pay by bank under the paybybank key

[armando-rodriguez-cko]

Summary
The Payment Setup API names the Pay by Bank method paybybank. This SDK sent it as pay_by_bank, which the API ignores without an error, so Pay by Bank configuration was silently dropped. This PR sends the correct key and adds the risk object (enabled).

Changes

• payments/setups/setups.py: new paybybank; pay_by_bank kept and marked deprecated (the API ignores that key); new PaymentSetupRisk (enabled) and PaymentSetupsRequest.risk
• payments/setups/setups_client.py: docstrings point to payment_methods.paybybank and risk
• tests/payments/setups/payment_setups_serialization_test.py: literal key, response action, risk serialization

API Reference

• POST /payments/setups: payment_methods.paybybank, risk
• PUT /payments/setups/{id}: payment_methods.paybybank, risk
• GET /payments/setups/{id}

Breaking changes
None. pay_by_bank is deprecated, not removed; it will be removed in a future major.

README
No change 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 PR adds a new field alias (paybybank), a small new data class (PaymentSetupRisk), and a new request field (risk) that are all natural extensions of existing abstractions on the same endpoint, with no new external integrations, auth changes, persisted data, or background processes.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 3

---

_{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.
2.2.6_logical_extension — The PR adds a new field alias (paybybank), a small new data class (PaymentSetupRisk), and a new request field (risk) that are all natural extensions of existing abstractions on the same endpoint, with no new external integrations, auth changes, persisted data, or background processes.	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]

🟢 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 only adds a new field alias (paybybank) to an existing data class, deprecates an incorrect field (pay_by_bank), adds a small new data class (PaymentSetupRisk) with a single bool field to an existing request object, and updates docstrings — all reusing existing endpoints, abstractions, and code paths with no new external integrations, persisted data, auth changes, or background processes.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 3

---

_{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.
2.2.6_logical_extension — The change only adds a new field alias (paybybank) to an existing data class, deprecates an incorrect field (pay_by_bank), adds a small new data class (PaymentSetupRisk) with a single bool field to an existing request object, and updates docstrings — all reusing existing endpoints, abstractions, and code paths with no new external integrations, persisted data, auth changes, or background processes.	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 only adds a correctly-named field alias (paybybank) alongside the deprecated pay_by_bank, adds a small PaymentSetupRiskdata class with a single bool field, wiresrisk into the existing request object, and updates docstrings—all within the existing endpoints, abstractions, and serialization path with no new external integrations, persisted data, auth changes, or background processes.

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}