feat(payments): add fallback_source to the payment request

[rodrigojara-cko]

Summary

POST /payments accepts fallback_source, an alternative card source the platform attempts when the payment with the primary source fails. The Java SDK only modelled the fallback_source_used response flag, so merchants could not send it. PaymentRequest now exposes it as fallbackSource, typed as the existing RequestCardSource.

RequestCardSource was also missing allow_update (Real-Time Account Updater), which the spec defines on both the primary card source and the fallback source, so the card used in source gains it too.

Changes

• payments/request/PaymentRequest.java: added fallbackSource (RequestCardSource). Doc comments completed: amount range (max 9999999999), description and [Optional] for the deprecated paymentIp and marketplace.
• payments/request/source/RequestCardSource.java: added allowUpdate. Every doc comment rewritten from the spec: [Required] on number, expiryMonth and expiryYear, min 1 max 12 on expiryMonth, min 3 max 4 characters on cvv.
• PaymentRequestSerializationTest.java: new tests asserting the literal fallback_source key with all 12 properties, a roundtrip, the swagger example, omission when null, and allow_update on the primary source.

API Reference

• POST /payments: PaymentRequest.fallback_source (PaymentRequestFallbackSource)
• PaymentRequestCardSource.allow_update

Breaking changes

None. Both fields are additive and optional; the RequestCardSource builder gains one optional setter.

README

Not affected.

[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 optional fields to existing request/source model classes and new serialization tests, reusing existing abstractions without new endpoints, auth changes, persisted data, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1719)
• ✅ 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 only adds optional fields to existing request/source model classes and new serialization tests, reusing existing abstractions without 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
9.1% 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 an optional field to an existing request model, improves doc comments, and adds a field to an existing source class, all reusing existing types and abstractions without new endpoints, persistence, auth changes, or external integrations.

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