[armando-rodriguez-cko]

Summary
Aligns the payment retry request types with the API. CustomerRetry is now one shared type used by hosted payments, payment links and payment sessions, and the top-level max_attempts and end_after_days of PaymentRetryRequest are deprecated in favour of dunning.

Changes

• checkout_sdk/common/common.py: CustomerRetry (max_attempts, 0 to 5, default 5) now lives here and is documented from the spec.
• checkout_sdk/payments/sessions/sessions.py: the duplicate CustomerRetry is removed; the module imports the shared one, so payment_sessions.CustomerRetry keeps working.
• checkout_sdk/payments/payments.py: PaymentRetryRequest, DunningRetryRequest and DowntimeRetryRequest documented from the spec (required, ranges, defaults). Top-level max_attempts and end_after_days marked # Deprecated:; use dunning.max_attempts and dunning.end_after_days. They still serialize when set and will be removed in the next major version.
• tests/payments/retry_request_serialization_test.py: every property, enabled=False, max_attempts=0, deprecated fields only when set, PaymentRetryRequest roundtrip with nested DunningRetryRequest and DowntimeRetryRequest, and CustomerRetry on the three endpoints plus its roundtrip.

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
None. The deprecated fields still serialize when set.

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:checkout_sdk/payments/sessions/sessions.py

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 4

---

_{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 — checkout_sdk/payments/sessions/sessions.py	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.

Deprecates top-level max_attempts and end_after_days on PaymentRetryRequest, adds docstrings to retry types, consolidates the duplicate CustomerRetry class, and adds a thorough serialization test suite. The change matches its stated intent and introduces no breaking changes.

What I checked

• Verified the duplicate CustomerRetry in sessions.py is removed and replaced by the import from common.common, and the module-level attribute is confirmed to be the same object in test_sessions_module_exposes_shared_type.
• Deprecated fields are preserved on PaymentRetryRequest with inline comments; they are not removed, which is consistent with the stated non-breaking intent.
• The test for enabled=False and max_attempts=0 correctly verifies that falsy values are serialized rather than dropped, which is an important edge case for the JsonSerializer.
• No migration, no removal of existing tests, and no existing callers were broken — the old import path (from checkout_sdk.payments.sessions.sessions import CustomerRetry) continues to work via the re-exported name.

---

_{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:checkout_sdk/payments/sessions/sessions.py

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 4

---

_{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 — checkout_sdk/payments/sessions/sessions.py	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