[armando-rodriguez-cko]

Summary
Loads the payment retry types and aligns the payment retry, hosted payments, payment links and payment sessions requests with the API reference, including Dunning and Downtime retries and customer retries on payment sessions.

Changes

• lib/checkout_sdk/payments/payments.rb: requires dunning_retry_request, downtime_retry_request and payment_retry_request (the retry class was never loaded before).
• lib/checkout_sdk/payments/payment_retry_request.rb: PaymentRetryRequest now has enabled, dunning and downtime.
• lib/checkout_sdk/payments/dunning_retry_request.rb: new DunningRetryRequest (enabled, max_attempts, end_after_days).
• lib/checkout_sdk/payments/downtime_retry_request.rb: new DowntimeRetryRequest (enabled).
• lib/checkout_sdk/common/customer_retry.rb: CustomerRetry moves to CheckoutSdk::Common::CustomerRetry; CheckoutSdk::Accounts::CustomerRetry stays as a deprecated alias.
• lib/checkout_sdk/payments/sessions/payment_sessions_request.rb: adds customer_retry and instruction; deprecates retry and ip_address; payment_type documented as a PaymentType string.
• lib/checkout_sdk/payments/links/payment_link.rb: adds instruction and payment_method_configuration; deprecates payment_ip.
• lib/checkout_sdk/payments/hosted/hosted_payments_session.rb: customer_retry documented as CheckoutSdk::Common::CustomerRetry; deprecates payment_ip.
• lib/checkout_sdk/payments/payment_request.rb: retry documented.
• Doc comments completed on every attribute of HostedPaymentsSession, PaymentLink and PaymentSessionsRequest, with ranges and defaults from the API reference.
• spec/checkout_sdk/payments/retry_request_serialization_spec.rb: PaymentRetryRequest, DunningRetryRequest, DowntimeRetryRequest, CustomerRetry (all properties, swagger example, false and zero values, alias identity, use from the three endpoints), plus instruction and payment_method_configuration.
• spec/checkout_sdk/payments/hosted/hosted_payments_integration_spec.rb: uses CheckoutSdk::Common::CustomerRetry.

API Reference

• POST /payments (retry): https://api-reference.checkout.com/tag/payments/POST/payments.body.retry
• POST /hosted-payments (customer_retry): https://api-reference.checkout.com/tag/hosted-payments-page/POST/hosted-payments.body.customer_retry
• POST /payment-links (customer_retry): https://api-reference.checkout.com/tag/payment-links/POST/payment-links.body.customer_retry
• POST /payment-sessions (customer_retry): https://api-reference.checkout.com/tag/flow/POST/payment-sessions.body.customer_retry

Breaking changes

• The top-level max_attempts and end_after_day accessors are removed from PaymentRetryRequest. The class could never be loaded before this change, so no working code is affected. Use dunning.max_attempts and dunning.end_after_days.
• Deprecated, still available until the next major version: PaymentSessionsRequest#retry (not part of the payment sessions request; the API ignores it), PaymentSessionsRequest#ip_address, HostedPaymentsSession#payment_ip, PaymentLink#payment_ip and the CheckoutSdk::Accounts::CustomerRetry alias.

README
Not affected: the README does not document retries or these request fields.

[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.

This PR fixes a real NameError (PaymentRetryRequest never required), corrects the misspelled end_after_day attribute, moves CustomerRetry to the right module with a backward-compatible alias, adds customer_retry to PaymentSessionsRequest, and ships serialization tests for all new types. The diff does exactly what the description claims and no blocking problems were found.

What I checked

• The load order in payments.rb correctly places dunning/downtime before payment_retry_request, which in turn sits before payment_request — no circular dependency or undefined constant at require time.
• The deprecated Accounts::CustomerRetry alias is a constant assignment to the same class object, so is_a? checks and equal? identity both work; the spec explicitly verifies this.
• PaymentRetryRequest drops max_attempts and end_after_day (the misspelled one) from attr_accessor — any existing callers of those methods will get NoMethodError. The PR description calls this a breaking change only for end_after_day/end_after_days, but the diff shows no deprecation shim on the class itself (only docs), so callers using the old attributes will break silently at runtime rather than getting a deprecation warning.
• The hosted_payments_integration_spec fix from PaymentRetryRequest to Common::CustomerRetry is correct — the hosted payments API takes customer_retry (a CustomerRetry), not a PaymentRetryRequest.
• The new serialization spec covers all three new types plus the alias and cross-class customer_retry assignment; the max_attempts = 0 edge case is explicitly tested, which is good given the minimum-0 constraint.
• The diff is truncated (payment_link.rb and payment_sessions_request.rb are cut off), so the attr_accessor :customer_retry additions to those classes cannot be fully verified from the diff alone, but the spec exercises them and would fail if the accessors were missing.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{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}

[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}

[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