feat(setups): add the setup payment type, confirm risk and tamara fields by rodrigojara-cko · Pull Request #700 · checkout/checkout-sdk-java

rodrigojara-cko · 2026-10-26T14:21:05Z

Summary

payment_type on Payment Setup used the payments PaymentType, which sends values such as PayLater that the API rejects with 422 and reads every lowercase value except regular as null. It now has its own enum with the six spec values. The confirm response gets the risk it was missing and Tamara gets initialization and risk_assessment. last_payment_amount takes the specification's number type.

Changes

entities/paymentType/PaymentSetupPaymentType.java (new): REGULAR, RECURRING, MOTO, INSTALLMENT, PAY_LATER, UNSCHEDULED, sent lowercase. Used by PaymentSetupsRequest (default REGULAR), PaymentSetupsResponse and PaymentSetupsConfirmResponse; com.checkout.payments.PaymentType is unchanged.
PaymentSetupsConfirmResponse.java: risk (PaymentSetupRisk).
tamara/Tamara.java: initialization (default DISABLED, as the other methods) and riskAssessment; tamara/TamaraRiskAssessment.java (new).
customer/MerchantAccount.java: lastPaymentAmount is Double (was Long), the specification's number type, as the other last_payment_amount fields of the SDK. Its doc notes that the API currently stores it as an integer.
Klarna, Bacs, CashApp, PayPal, Stcpay, Tabby, Tamara: the initialization doc gives the spec description and default, and says that an update replaces the payment methods, so ENABLED must be sent again to keep a method enabled (API behaviour, not stated in the spec).
PaymentMethods.java, Order.java, the request and both responses: docs completed against the spec.
ideal/Ideal.java description, knet/Knet.java language, bancontact/Bancontact.java accountHolderName: the doc says that the specification marks the field optional, but the API keeps the method invalid until it is sent.
Tests: every PaymentSetupPaymentType value written and read, the default, round trips through the request and both responses; confirm risk; Order and Tamara round trips with literal keys and the spec examples; PaymentSetupsTestIT uses the new enum.
PaymentSetupsPaymentMethodsSerializationTest.java (new): a round trip with every property under its literal wire key and a spec example test for Ach, Sepa, Swish, P24, Qpay, Ideal, Knet, Bancontact, Multibanco, Blik, Bacs, Alipay CN, Alipay HK, GCash, TNG, Dana, KakaoPay, TrueMoney, Alma, Benefit, EPS, MBWay, MobilePay, Octopus, PayNow, Sequra, Twint, Vipps and WeChatPay; last_payment_amount round trip under its literal key with the spec example 55.99.
PaymentSetupsNewFieldsSerializationTest.java, LocalDateFieldsRegressionTest.java: lastPaymentAmount uses 55.99.

API Reference

Breaking changes required by the API

paymentType on PaymentSetupsRequest, PaymentSetupsResponse and PaymentSetupsConfirmResponse is PaymentSetupPaymentType; code passing com.checkout.payments.PaymentType must switch, including PaymentType.REGULAR, which no longer compiles there (use PaymentSetupPaymentType.REGULAR).
The all-args constructor of PaymentSetupsConfirmResponse takes the new risk argument.

Breaking changes chosen by the SDK

MerchantAccount.lastPaymentAmount is Double instead of Long: aligned with the specification type; the same type in every SDK. Code that passes a Long (for example lastPaymentAmount(1000L)) or reads the value as Long stops compiling and must use Double.

Follow-ups

Reported internally, for later:

Order.items and Order.shipping keep the payments types until the next major version.
The confirm response keeps its own class (PaymentSetupsConfirmResponse, a duplicate of PaymentSetupsResponse) until the next major version.
The responses inherit the Resource links, which the Payment Setups specification does not define.
CardAccountHolder keeps its name (the spec calls it PaymentSetupAccountHolder) until the next major version.
terminal.local_date_time is an Instant and loses the offset (tracked separately).
Tamara and the other methods with initialization send disabled by default. An update replaces the payment methods, so this matches omitting it.

README

No change needed.

payment_type used the payments PaymentType, which sends PayLater (rejected with 422) and cannot read the lowercase values the API returns. The confirm response gets risk, Tamara gets initialization and risk_assessment, and card_present is deprecated.

agent-wall-e · 2026-10-26T14:21:09Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:425>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 19

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-26T14:21:10Z

🔬 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
`exceeds_bounded_scope` — `425>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-26T14:21:18Z

🟢 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 a dedicated PaymentSetupPaymentType enum with correct lowercase wire values, fixes missing risk on the confirm response, adds Tamara initialization and riskAssessment, and changes lastPaymentAmount to Double — all matching the stated API spec. The changes are correct and well-tested.

What I checked

PaymentSetupPaymentType uses @SerializedName with the six lowercase values the API expects, correctly replacing the PascalCase values from the shared PaymentType enum that caused 422 errors.
The default PaymentSetupPaymentType.REGULAR on PaymentSetupsRequest is preserved via @Builder.Default, maintaining backward behaviour for callers that don't set payment_type.
PaymentSetupsConfirmResponse now includes risk (PaymentSetupRisk), consistent with PaymentSetupsResponse which already had it.
TamaraRiskAssessment is a new, standalone class with four optional fields; it does not extend PaymentMethodBase, which is appropriate since it is a nested object rather than a top-level payment method.
Tamara.initialization defaults to DISABLED, consistent with every other payment method that carries an initialization field.
MerchantAccount.lastPaymentAmount changed from Long to Double; the javadoc honestly notes the API currently stores it as an integer, which is a useful caveat for callers.
The integration test (PaymentSetupsTestIT) is updated to use PaymentSetupPaymentType.REGULAR, so it will compile and run correctly against the API.
Test coverage is comprehensive: every enum value is written and read, defaults are verified, round-trips go through all three DTOs, and spec examples are exercised with literal wire keys.
The diff is partial (truncated), so the full PaymentSetupsPaymentMethodsSerializationTest and some payment-method files are not fully visible, but what is shown is consistent and correct.

⚠️ 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}

Adds round trip and spec example tests for every payment method without one, documents that the API stores last_payment_amount as an integer, and drops the initialization doc sentence the spec does not support.

agent-wall-e · 2026-10-27T11:23:44Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:417>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T11:23:45Z

🔬 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
`exceeds_bounded_scope` — `417>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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}

+            final String wireKey,
+            final Supplier<? extends PaymentMethodBase> factory,
+            final Function<PaymentMethods, ? extends PaymentMethodBase> getter,
+            final BiConsumer<PaymentMethods.PaymentMethodsBuilder, PaymentMethodBase> setter) {


agent-wall-e · 2026-10-27T12:42:14Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:417>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T12:42:15Z

🔬 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
`exceeds_bounded_scope` — `417>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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}

MerchantAccount.lastPaymentAmount is a Double, the type the specification gives last_payment_amount, as in the other SDKs. card_present and its classes are restored as on master: the API still supports them.

agent-wall-e · 2026-10-27T14:02:41Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:412>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 20

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T14:02:42Z

🔬 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
`exceeds_bounded_scope` — `412>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-27T15:35:20Z

🟡 Risk Classification: MINOR

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

Classification reasons

exceeds_bounded_scope:415>250

Operational gates

✅ jira_ticket (INT-1738)
✅ independent_review

Files analysed: 23

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

agent-wall-e · 2026-10-27T15:35:21Z

🔬 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
`exceeds_bounded_scope` — `415>250`	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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 · 2026-10-27T15:36:01Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
3.3% Duplication on New Code

See analysis details on SonarQube Cloud

rodrigojara-cko requested a review from a team October 26, 2026 14:21

feat(setups): add serialization tests for the setup payment methods

fd711b6

Adds round trip and spec example tests for every payment method without one, documents that the API stores last_payment_amount as an integer, and drops the initialization doc sentence the spec does not support.

github-advanced-security Bot found potential problems Oct 27, 2026

View reviewed changes

test(setups): add multibanco serialization tests

03d1e1f

rodrigojara-cko added 2 commits October 27, 2026 14:28

fix(setups): type last_payment_amount as a number; keep card_present

be4cfe6

MerchantAccount.lastPaymentAmount is a Double, the type the specification gives last_payment_amount, as in the other SDKs. card_present and its classes are restored as on master: the API still supports them.

docs(setups): note that an update replaces the payment methods

72cc569

docs(setups): note the ideal, knet and bancontact fields the API needs

7b6844a

Navigation Menu

Repository navigation

feat(setups): add the setup payment type, confirm risk and tamara fields - #700

feat(setups): add the setup payment type, confirm risk and tamara fields#700
rodrigojara-cko wants to merge 6 commits into
masterfrom
feat/INT-1738-payment-setup-gaps

rodrigojara-cko commented Oct 26, 2026 •

edited

Loading

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

Uh oh!

agent-wall-e Bot commented Oct 26, 2026 •

edited

Loading

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

sonarqubecloud Bot commented Oct 27, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Conversation

rodrigojara-cko commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 26, 2026

Uh oh!

agent-wall-e Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🟢 Advisory review: Looks good to me

What I checked

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

🟡 Risk Classification: MINOR

Classification reasons

Operational gates

Uh oh!

agent-wall-e Bot commented Oct 27, 2026

Uh oh!

sonarqubecloud Bot commented Oct 27, 2026

Quality Gate passed

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

rodrigojara-cko commented Oct 26, 2026 •

edited

Loading

agent-wall-e Bot commented Oct 26, 2026 •

edited

Loading