[armando-rodriguez-cko]

Summary
The Payment Setup API names the Pay by Bank method paybybank. PayByBankPaymentMethod existed but nothing documented which key to send it under, so it could not be used. This PR documents the paybybank key and adds the risk object (enabled).

Changes

• setups/pay_by_bank_payment_method.rb: documents the payment_methods.paybybank key and how to send and read it, so the class is usable
• setups/payment_setup_risk.rb (new): enabled; required in payments.rb
• setups/payment_setups_client.rb: create and update docs list :paybybank and :risk
• setup_payment_methods_serialization_spec.rb: 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.

README
No change needed.

Local CI
Ran build-pull-request (Ruby 3.1) with act against the sandbox: 830 examples, 2 failures, both in transfers_integration_spec.rb (the sandbox answers 422 to POST /transfers). Unrelated to this change; master passed on 2026-10-08.

[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 documentation, new Ruby data-class stubs (PaymentSetupRisk with a single attr_accessor), and spec coverage for already-existing endpoints and serialization paths, with no new external integrations, no persisted data, no auth changes, and no new background processes.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 5

---

_{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 documentation, new Ruby data-class stubs (PaymentSetupRisk with a single attr_accessor), and spec coverage for already-existing endpoints and serialization paths, with no new external integrations, no persisted data, no auth changes, and no new 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 PR only adds documentation comments, a small new plain data class (PaymentSetupRisk with a single attr_accessor), and tests — it reuses existing serialization paths and endpoints without adding new external integrations, persisted data, auth changes, or background workers.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 5

---

_{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 only adds documentation comments, a small new plain data class (PaymentSetupRisk with a single attr_accessor), and tests — it reuses existing serialization paths and endpoints without adding new external integrations, persisted data, auth changes, or background workers.	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 PR only adds documentation comments, a new simple data-class (PaymentSetupRisk with one attr_accessor), and tests for existing serialization paths—it introduces no new endpoints, external integrations, persisted data, auth changes, or background workers, and is a natural extension of already-existing PayByBank and setup abstractions.

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