[armando-rodriguez-cko]

This release adds the Payment Setup payment type, the risk settings on the Payment Setup confirm response and the Tamara risk assessment fields. It also adds the subscription details and the retry attempt count to payment responses, and lets you revoke and suspend Issuing cards without a request body. Customer retries on hosted payments and payment links now use the type the API accepts, and the update card headers the API no longer documents are deprecated. Every deprecated member keeps working and will be removed in the next major version.

Added

Issuing (#697)

• IssuingClient#revokeCard(String cardId), #suspendCard(String cardId), #revokeCardSync(String cardId) and #suspendCardSync(String cardId). The existing overloads that take a RevokeCardRequest or SuspendCardRequest now accept null, because the request body is optional in the API.

Payment Setups (#700)

• PaymentSetupPaymentType with the values of the Payment Setups API: REGULAR (regular), RECURRING (recurring), MOTO (moto), INSTALLMENT (installment), PAY_LATER (pay_later), UNSCHEDULED (unscheduled).
• PaymentSetupsConfirmResponse#risk (PaymentSetupRisk).
• Tamara#initialization (PaymentMethodInitialization, default DISABLED) and Tamara#riskAssessment, with the new TamaraRiskAssessment (premiumCustomer, riskScore, orderCountLast24h, linkedDeviceCount).

Payments (#701)

• PaymentResponse#subscription (PaymentSubscription).
• PaymentRetryResponse#attemptsMade, returned by get payment details.

Changed

• PaymentRetryRequest#enabled is no longer deprecated. It is the required switch for asynchronous retries on payment requests (fix(payments): align retry and customer retry types with the spec #701).
• Request and response fields of payments, payment retries, hosted payments, payment links, payment sessions and Payment Setups now document whether they are required or optional, with the limits, defaults and enum values of the API reference (feat(setups): add the setup payment type, confirm risk and tamara fields #700, fix(payments): align retry and customer retry types with the spec #701).
• Payment Setup payment methods document that an update replaces the payment methods, so initialization must be sent as ENABLED again to keep a method enabled (feat(setups): add the setup payment type, confirm risk and tamara fields #700).

Fixed

• The Retry response of a payment request no longer reports maxAttempts as 6 when the API did not return it (fix(payments): align retry and customer retry types with the spec #701).

Deprecated

All deprecated members keep working and will be removed in the next major version.

• CardUpdateHeaders and the IssuingClient#updateCard and #updateCardSync overloads that take it: the API no longer documents the return-encrypted-cvv and Encryption-Key headers. Headers that are set are still sent. Use updateCard(String, UpdateCardRequest) or updateCardSync(String, UpdateCardRequest) (deprecate(issuing): deprecate the update-card headers and allow revoke and suspend without a body #697).
• HostedPaymentRequest#setCustomerRetry(PaymentRetryRequest) and HostedPaymentRequestBuilder#customerRetry(PaymentRetryRequest): customer retries only accept max_attempts, so only that value is kept. Use the CustomerRetry overloads (fix(payments): align retry and customer retry types with the spec #701).
• PaymentLinkRequest#setCustomerRetry(PaymentRetryRequest) and PaymentLinkRequestBuilder#customerRetry(PaymentRetryRequest): same reason. Use the CustomerRetry overloads (fix(payments): align retry and customer retry types with the spec #701).

Breaking changes required by the API ⚠️

• PaymentSetupsRequest#paymentType, PaymentSetupsResponse#paymentType and PaymentSetupsConfirmResponse#paymentType change from com.checkout.payments.PaymentType to PaymentSetupPaymentType. The Payment Setups API only accepts the lowercase values; the old type sent PayLater, which the API rejects with a 422, and read every value except regular as null. Migration: replace PaymentType.X with PaymentSetupPaymentType.X (feat(setups): add the setup payment type, confirm risk and tamara fields #700).
• MerchantAccount#lastPaymentAmount (Payment Setups customer) changes from Long to Double, because the API defines it as a number (for example 55.99). Migration: pass a Double (for example 500d) and read the getter as Double (feat(setups): add the setup payment type, confirm risk and tamara fields #700).
• HostedPaymentRequest#customerRetry and PaymentLinkRequest#customerRetry change from PaymentRetryRequest to CustomerRetry, because customer retries only accept max_attempts (0 to 5). Code that sets the field keeps compiling through the deprecated overloads; code that reads getCustomerRetry() now gets a CustomerRetry. Migration: CustomerRetry.builder().maxAttempts(n).build() (fix(payments): align retry and customer retry types with the spec #701).

Dependencies

• gson 2.14.0, slf4j-api 2.0.18 and commons-codec 1.22.1, all still compatible with Java 8 (chore(deps): update runtime dependencies, build plugin and CI actions #702).

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

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

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: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The diff only shows a version bump from 8.8.0 to 8.9.0; all substantive code changes described in the PR body are not visible in this diff. The PR explicitly flags breaking type changes (PaymentSetupPaymentType, Double vs Long, CustomerRetry vs PaymentRetryRequest) yet increments only the minor version, which a reviewer should consciously sign off on.

For you to decide

• The diff is partial — none of the new classes, deprecated overloads, response fields, or dependency updates described in the PR body appear in the diff, so their correctness cannot be assessed here.
• The PR describes three explicit breaking API changes (paymentType enum type swap, Long→Double on MerchantAccount#lastPaymentAmount, PaymentRetryRequest→CustomerRetry on getCustomerRetry()) yet the version goes from 8.8.0 to 8.9.0 rather than 9.0.0; a reviewer should confirm this is intentional project versioning policy and not an oversight.
• If this project follows semver strictly, breaking changes in a minor release could surprise consumers who rely on automated dependency updates.

---

_{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: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

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

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]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

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

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]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

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

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