[armando-rodriguez-cko]

Summary
Aligns the payment retry types with the API. customerRetry on hosted payments and payment links only accepts max_attempts (0 to 5), but used PaymentRetryRequest, the retry object of POST /payments. PaymentRetryRequest.enabled was deprecated although it is the required switch for asynchronous retries. The retry responses were missing attempts_made and one of them reported a max_attempts the API did not return.

Changes

• payments/hosted/HostedPaymentRequest.java, payments/links/PaymentLinkRequest.java: customerRetry now uses CustomerRetry
• handlepaymentsandpayouts/flow/entities/CustomerRetry.java, flow/requests/PaymentSessionCreateRequest.java: docs aligned with the spec
• payments/request/PaymentRetryRequest.java: enabled no longer deprecated; maxAttempts and endAfterDays stay deprecated with an updated message
• payments/request/DunningRetryRequest.java, DowntimeRetryRequest.java, PaymentRequest.java: docs, required markers and ranges from the spec
• payments/response/PaymentRetryResponse.java: attemptsMade added, every field documented; PaymentResponse and GetPaymentResponse retry documented
• postpayments/.../retry/Retry.java: maxAttempts no longer defaults to 6 when the API leaves it out
• Tests: CustomerRetrySerializationTest, PaymentRetryResponseSerializationTest, RetrySerializationTest (new), PaymentRetryRequestSerializationTest (rewritten with exact JSON assertions), TestHelper fixtures

API Reference

• POST /payments (retry): https://api-reference.checkout.com/tag/payments/POST/payments
• POST /hosted-payments (customer_retry): https://api-reference.checkout.com/tag/hosted-payments-page/POST/hosted-payments
• POST /payment-links (customer_retry): https://api-reference.checkout.com/tag/payment-links/POST/payment-links
• POST /payment-sessions (customer_retry): https://api-reference.checkout.com/tag/flow/POST/payment-sessions
• GET /payments/{id} (retry, payment_ip): https://api-reference.checkout.com/tag/payments/GET/payments/%7Bid%7D

Breaking changes
The customerRetry builder on HostedPaymentRequest and PaymentLinkRequest now takes CustomerRetry instead of PaymentRetryRequest. This is forced by the API, so it ships in a minor release. Retry.getMaxAttempts() on the request payment response now returns null when the API omits the field instead of 6.

README
Not affected: the README does not document these types.

[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:All changes are non-destructive doc/type alignment fixes (swapping one existing type for another, adding missing response fields, un-deprecating a field, removing a default value) that reuse existing code paths and abstractions without introducing new endpoints, external integrations, persisted data, auth changes, or background processes.

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 17

---

_{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 — All changes are non-destructive doc/type alignment fixes (swapping one existing type for another, adding missing response fields, un-deprecating a field, removing a default value) that reuse existing code paths and abstractions without introducing new endpoints, 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}