Skip to content

fix(setups): align PaymentSetupsConfirmResponse with PaymentSetup schema#616

Merged
armando-rodriguez-cko merged 1 commit into
masterfrom
fix/payment-setups-confirm-response-models
Jul 16, 2026
Merged

fix(setups): align PaymentSetupsConfirmResponse with PaymentSetup schema#616
armando-rodriguez-cko merged 1 commit into
masterfrom
fix/payment-setups-confirm-response-models

Conversation

@armando-rodriguez-cko

Copy link
Copy Markdown
Contributor

Problem

A merchant reported that in PaymentSetupsConfirmResponse, the referenced models (such as Customer) came from the payments.postpayments package instead of the setups.entities package — as they should, and as they already are in PaymentSetupsResponse. Because the two Customer shapes differ (e.g. customer.email is a nested object { address, verified } in setups but a plain string in postpayments), this broke merchant onboarding.

Root cause

The confirm endpoint POST /payments/setups/{id}/confirm/{payment_method_name} returns the PaymentSetup schema — identical to the create/get responses. But PaymentSetupsConfirmResponse was modeled as a payment (postpayments) response, with fields like actionId, approved, status, processedOn, threeDSecure, risk, balances, subscription, processing, eci, schemeId, retry, source that do not exist in the PaymentSetup schema.

Changes

  • Rewrote PaymentSetupsConfirmResponse to mirror PaymentSetupsResponse using the setups.entities models. Covers all 19 PaymentSetup properties, verified against the current swagger spec.
  • Removed PaymentSetupSource — an orphaned class not present in the PaymentSetup schema, previously referenced only by the incorrectly-modeled confirm response.
  • Fixed the integration test (PaymentSetupsTestIT) which referenced the removed getActionId() / getProcessedOn().
  • Added PaymentSetupsConfirmResponseSerializationTest proving customer.email deserializes as the nested setups object (would fail with the postpayments Customer).

Verification

  • ./gradlew compileJava compileTestJava — passes.
  • New serialization test and PaymentSetupsClientImplTest — pass.
  • Schema re-checked against freshly-synced swagger (checkout_swagger_json, ingested today): confirm 200 → PaymentSetup, 19 properties, all mapped.

The confirm endpoint (POST /payments/setups/{id}/confirm/{payment_method_name})
returns the PaymentSetup schema, the same as the create/get responses. The
PaymentSetupsConfirmResponse class was instead modeled as a payment (postpayments)
response, referencing models such as Customer from payments.postpayments whose
shapes differ from the setups.entities models. This broke merchant onboarding,
since e.g. customer.email is a nested object in setups but a plain string in
postpayments.

Rewrite PaymentSetupsConfirmResponse to mirror PaymentSetupsResponse using the
setups.entities models, remove the orphaned PaymentSetupSource class, fix the
integration test, and add a serialization test covering the setups Customer shape.
@armando-rodriguez-cko
armando-rodriguez-cko requested a review from a team July 16, 2026 11:12
@armando-rodriguez-cko
armando-rodriguez-cko merged commit e66c5f0 into master Jul 16, 2026
4 checks passed
@armando-rodriguez-cko
armando-rodriguez-cko deleted the fix/payment-setups-confirm-response-models branch July 16, 2026 15:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants