Repository navigation
fix(setups): align the payment setup request shape with the spec - #694
rodrigojara-cko wants to merge 4 commits into
Conversation
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 17 wall-e 2026.06.19-02 · policy |
🔬 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.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
🟢 Advisory review: Looks good to meThis 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 aligns the Java payment-setup model with the API spec by restructuring card fields under What I checked
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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 18 wall-e 2026.06.19-02 · policy |
🔬 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.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 19 wall-e 2026.06.19-02 · policy |
🔬 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.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
POST /payments/setups modelled several fields in a shape the API no longer accepts, so the values were dropped without an error. - card: the card data moves under card.details and token is an object. The flat accessors are deprecated and now write inside details, so existing code keeps compiling and starts sending the right keys. - order.sub_merchants: number_of_trades is not an API field; the field is number_of_sales. The numberOfTrades accessors are deprecated and delegate. - card, applepay, googlepay: add schemes and preferred_scheme. - settings: add capture and excluded_payment_methods. - payment_methods: add auto_confirm. Add metadata to the request and both responses. Add the read-only instrument.type. - PaymentMethodStatus: deprecate PENDING and AVAILABLE, which the spec does not list.
The spec types payment_methods.applepay.token and googlepay.token as an
object {id, expires_on}. The SDK modelled token as a string with
expires_on next to it, a shape the API does not accept.
token is now a WalletToken. The flat expiresOn accessors are deprecated and
write inside token.
This is source-breaking for code that reads or writes token as a String.
That code could not have produced a valid request, since the API expects
an object, so nothing that worked stops working. Breaking because the API
demands it, so a minor release, to be called out in the release notes.
…shape The flat card accessors, the wallet expiresOn accessors and numberOfTrades were kept as deprecated methods that wrote into the new shape. The old shape never worked against the API (the data was dropped without an error), so removing them breaks nothing that worked, and a compile error tells a merchant who used them that their data was being lost. It also keeps these classes on plain Lombok accessors. Card, ApplePay, GooglePay and OrderSubMerchant now expose only the spec shape. Breaking because the API demands it, so a minor release. Also add the read-only klarna.iban.
6a543ff to
5d3e64a
Compare
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 19 wall-e 2026.06.19-02 · policy |
🔬 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.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
PaymentSetupAccountHolder, used by card, applepay and googlepay, defines company_name; the model did not carry it.
🟡 Risk Classification: MINORApproval route: AI Review + Human Approval Classification reasons
Operational gates
Files analysed: 20 wall-e 2026.06.19-02 · policy |
🔬 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.
Kinds:
See issue #3 for the proposal to formalise this map as Appendix A of the standards doc. wall-e 2026.06.19-02 · debug |
|
This branch has not been deployed
2 participants
Summary
Several
POST /payments/setupsfields were modelled in a shape the API does not accept, so their values were dropped without an error. This moves the card data undercard.details, sends the Apple Pay and Google Pay token as an object, renamesnumber_of_tradestonumber_of_sales, and adds the fields the model was missing.Changes
entities/paymentMethods/card/Card.java: addstoken(CardToken),details(CardDetails),schemesandpreferredScheme; the flat card fields move intoCardDetails.entities/paymentMethods/card/CardDetails.java,CardToken.java: new.entities/paymentMethods/common/PaymentSetupScheme.java: new enum with the 17 scheme names from the spec.PaymentRoutingSchemewas not reused because it has nochina_union_pay.entities/paymentMethods/common/WalletToken.java: new,{id, expires_on}.entities/paymentMethods/applepay/ApplePay.java,googlepay/GooglePay.java:tokenis now aWalletTokenand the flatexpiresOnmoves inside it. AddschemesandpreferredScheme(payments.PreferredSchema).entities/order/OrderSubMerchant.java:numberOfSales(number_of_sales) replacesnumberOfTrades.entities/settings/Settings.java: addscaptureandexcludedPaymentMethods.entities/paymentMethods/PaymentMethods.java: addsautoConfirm.requests/PaymentSetupsRequest.java,responses/PaymentSetupsResponse.java,responses/PaymentSetupsConfirmResponse.java: addmetadata.entities/paymentMethods/instrument/Instrument.java: adds the read-onlytype.entities/paymentMethods/klarna/Klarna.java: adds the read-onlyiban.entities/paymentMethods/common/CardAccountHolder.java: addscompanyName(company_name), shared by card, Apple Pay and Google Pay.entities/paymentMethods/common/PaymentMethodStatus.java:PENDINGandAVAILABLEare@Deprecated; they are not in the spec enum.PaymentMethodsSerializationTest,PaymentSetupsNewFieldsSerializationTestandLocalDateFieldsRegressionTestcover roundtrip, the literal wire key of every new field (details,token.id,token.expires_on,schemes,preferred_scheme,number_of_sales,capture,excluded_payment_methods,auto_confirm,metadata,type,iban) and the swagger examples.API Reference
POST /payments/setupsPUT /payments/setups/{id}GET /payments/setups/{id}POST /payments/setups/{id}/confirm/{payment_method_name}Breaking changes
Forced by the API, so this is a minor release, to be called out in the changelog:
Card: the flat fields (number,last4,bin,scheme,expiryMonth,expiryYear,name,cvv,stored,expiresOn,allowUpdate) move tocard.details(CardDetails), andtokenis aCardToken {id}.ApplePay/GooglePay:tokenchanges fromStringtoWalletToken {id, expires_on}, andexpiresOnmoves insidetoken.OrderSubMerchant:numberOfTradesbecomesnumberOfSales(number_of_sales).In every case the previous shape was not accepted by the API, so nothing that worked stops working. The old members are removed rather than kept as deprecated aliases: they never produced a request the API accepts, so a compile error is the useful signal for anyone still using them. Python keeps deprecated aliases for the same members because in a dynamic language removing them would not fail and the data would be silently dropped again.
README
No change needed.