[armando-rodriguez-cko]

Summary
PaymentRetryRequest was never loaded by the gem, so using it raised NameError. It also misspelled end_after_days and had no dunning or downtime. CustomerRetry lived in the wrong module, and payment sessions had no customer_retry but an off-spec retry.

Changes

• lib/checkout_sdk/payments/payments.rb: requires the retry request files
• lib/checkout_sdk/payments/payment_retry_request.rb: adds dunning and downtime; deprecates max_attempts, end_after_days and the misspelled end_after_day in favour of dunning
• lib/checkout_sdk/payments/dunning_retry_request.rb, downtime_retry_request.rb (new)
• lib/checkout_sdk/common/customer_retry.rb: class moved to CheckoutSdk::Common; CheckoutSdk::Accounts::CustomerRetry kept as a deprecated alias
• lib/checkout_sdk/payments/sessions/payment_sessions_request.rb: adds customer_retry; deprecates retry, which the API does not define for payment sessions
• hosted/hosted_payments_session.rb, links/payment_link.rb, payment_request.rb: docs
• spec/checkout_sdk/payments/retry_request_serialization_spec.rb (new); the hosted integration spec builds Common::CustomerRetry

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

Breaking changes
None. Deprecated, to be removed in the next major version: PaymentRetryRequest#max_attempts, #end_after_days and #end_after_day (use dunning), PaymentSessionsRequest#retry (use customer_retry), CheckoutSdk::Accounts::CustomerRetry (use CheckoutSdk::Common::CustomerRetry).

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

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:lib/checkout_sdk/payments/sessions/payment_sessions_request.rb

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 11

---

_{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
security_sensitive_path — lib/checkout_sdk/payments/sessions/payment_sessions_request.rb	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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]

🟢 Advisory review: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Adds missing require statements for retry types, introduces DunningRetryRequest and DowntimeRetryRequest, moves CustomerRetry to Common with a backward-compatible alias, and adds customer_retry to PaymentSessionsRequest — all matching the stated intent with new serialization tests covering the key cases.

What I checked

• The load order in payments.rb correctly requires dunning and downtime before payment_retry_request, which references neither at load time (plain attr_accessor), so no circular dependency issue.
• The Accounts::CustomerRetry constant alias is set after Common::CustomerRetry is defined in the same file, so the assignment is safe and the deprecation test verifying object identity will pass.
• The deprecated end_after_day (misspelled) accessor is preserved in PaymentRetryRequest and explicitly tested to serialize under its own misspelled key, which is the correct backward-compatible behaviour.
• The integration spec change from PaymentRetryRequest.new to Common::CustomerRetry.new for hosted payments customer_retry is correct per the API spec.
• The serialization spec uses top-level helper methods rather than shared contexts, which is fine functionally; no missing requires are visible in the diff (assumes spec_helper loads the SDK).
• No existing tests are weakened or removed; coverage is only added.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[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