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

• PaymentMethods.java: @SerializedName("paybybank") on payByBank (the field name is unchanged)
• entities/risk/PaymentSetupRisk.java (new): Boolean enabled
• PaymentSetupsRequest.java, PaymentSetupsResponse.java: risk added
• PaymentSetupsPayByBankSerializationTest.java (new) and PaymentSetupsNewFieldsSerializationTest.java: literal key, response action, risk roundtrip and swagger example

API Reference

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

Breaking changes
None. The public member is unchanged; only the wire key is fixed.

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 fixes a serialization key name, adds a new simple data-only class with one Boolean field, and wires it into existing request/response DTOs — all non-destructive, no new endpoints, no auth/authz, no persistence, no external integrations, and fully within existing abstractions.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 6

---

_{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 fixes a serialization key name, adds a new simple data-only class with one Boolean field, and wires it into existing request/response DTOs — all non-destructive, no new endpoints, no auth/authz, no persistence, no external integrations, and fully within existing abstractions.	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 fixes a serialization key name, adds a simple new data-only class (PaymentSetupRisk) with no persistence or auth implications, and extends existing request/response POJOs with an optional field, all within existing endpoints and abstractions without introducing new integrations or background processes.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 6

---

_{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 fixes a serialization key name, adds a simple new data-only class (PaymentSetupRisk) with no persistence or auth implications, and extends existing request/response POJOs with an optional field, all within existing endpoints and abstractions without introducing new integrations 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 PR only fixes a serialization key annotation, adds a simple new data-only class with one Boolean field, and wires it into existing request/response objects — all non-destructive, function-preserving extensions of existing abstractions with no new endpoints, auth changes, persisted data, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1717)
• ✅ independent_review

Files analysed: 6

---

_{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 fixes a serialization key annotation, adds a simple new data-only class with one Boolean field, and wires it into existing request/response objects — all non-destructive, function-preserving extensions of existing abstractions with no new endpoints, auth changes, persisted data, or external integrations.	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 fixes a serialized wire key on an existing field, adds a simple new optional field to existing request/response DTOs using an existing abstraction pattern, introduces no new endpoints or external integrations, persists no new data, and crosses no trust boundary.

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