[armando-rodriguez-cko]

Summary
customer_retry on HostedPaymentsSessionRequest, PaymentLinkRequest and PaymentSessionsRequest was documented as PaymentRetryRequest, the retry object of POST /payments. Code that followed the documented type sent enabled, dunning and downtime, which the API rejects in customer_retry, and had no typed way to set max_attempts; the limit could only be sent by assigning a raw array or an untyped object. It now uses a dedicated CustomerRetry class with max_attempts (0 to 5, default 5).

Changes

• lib/Checkout/Payments/Request/CustomerRetry.php: new class with max_attempts.
• HostedPaymentsSessionRequest, PaymentLinkRequest, PaymentSessionsRequest: customer_retry documented as CustomerRetry.
• PaymentRetryRequest: stays as the retry object of PaymentRequest, now with a class description.
• Complete PHPDoc from the API spec on every property of HostedPaymentsSessionRequest, PaymentLinkRequest, PaymentRequest and PaymentSessionsRequest: description, required or optional, format, pattern, length, range, enum and deprecation.
• test/.../RetryRequestsSerializationTest.php: PaymentRetryRequest (all properties, enabled false, only spec properties), CustomerRetry with the swagger example, and max_attempts including 0 on all three endpoints.

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 at runtime: the change is to PHPDoc types only. Arrays such as ['max_attempts' => n] assigned to customer_retry keep working. Code that assigned a PaymentRetryRequest should switch to 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/Payments/Sessions/PaymentSessionsRequest.php

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 6

---

_{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/Payments/Sessions/PaymentSessionsRequest.php	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.

Introduces a dedicated CustomerRetry class with only max_attempts and wires it into the three hosted-payment endpoints that accept customer_retry, replacing the incorrectly-typed PaymentRetryRequest. The change is narrow, correct, and well-tested.

What I checked

• The new CustomerRetry class contains only max_attempts, matching the API spec for hosted-payments, payment-links, and payment-sessions endpoints.
• All three request classes (HostedPaymentsSessionRequest, PaymentLinkRequest, PaymentSessionsRequest) now import and type customer_retry as CustomerRetry instead of PaymentRetryRequest.
• PaymentRequest::$retry is left typed as PaymentRetryRequest, which is correct since the POST /payments endpoint uses a different schema.
• The new test file covers: property-list assertions to guard against accidental field additions, serialization of enabled=false and max_attempts=0 (falsy-value edge cases), roundtrip JSON fidelity, and the spec example across all three endpoints via a data provider — coverage is solid.
• The testPaymentRetryRequestHasOnlySpecProperties test uses get_class_vars to assert exact property lists for CustomerRetry, PaymentRetryRequest, DunningRetryRequest, and DowntimeRetryRequest; this will fail and catch any future accidental field additions, which is a useful regression guard.
• No existing tests are weakened or removed.

⚠️ 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/Payments/Sessions/PaymentSessionsRequest.php

Operational gates

• ✅ jira_ticket (INT-1748)
• ✅ independent_review

Files analysed: 7

---

_{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/Payments/Sessions/PaymentSessionsRequest.php	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
1 New issue
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