fix(paysafe): don't send a card accountId on wallet settle - #2067
Open
shuklatushar226 wants to merge 2 commits into
Open
fix(paysafe): don't send a card accountId on wallet settle#2067shuklatushar226 wants to merge 2 commits into
shuklatushar226 wants to merge 2 commits into
Conversation
A connector-tokenized wallet settle reaches the account-resolution match in `PaysafePaymentsRequest` as `PaymentMethod::Card`, because the gRPC `token` payment method maps to Card — the wallet identity survives only in `payment_method_type`. It therefore fell into the Card arm and resolved `card.<CURRENCY>.three_ds` / `no_three_ds`, while the Tokenize leg had minted the payment handle on the `apple_pay` / `google_pay` account. Paysafe rejects the mismatch with: 5068 - "Value does not correspond with the accountId in payment handle" Reproduced on sandbox with a Google Pay payment at `authentication_type: three_ds`: the handle was minted on account 1002671400 (status PAYABLE, tokenType GOOGLE_PAY) while the settle sent `card.USD.three_ds` = 1003047440. Confirmed against Paysafe directly — minting a handle on 1002671400 and settling with accountId 1003047440 returns the identical fieldError. This restores the rule already documented above the match: wallet settles send NO accountId, because the payment handle carries its own account binding. The wallet CIT arm is untouched — a vaulted CONVERTED handle has no binding, so it still resolves an explicit account. Verified directly against Paysafe that a Google Pay handle settles successfully with no accountId in the /payments body (USD, authCode 149723, COMPLETED). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auto-applied by CI: - cargo +nightly fmt --all - make -C sdk generate (if applicable) - make docs (if applicable) This commit was automatically generated by GitHub Actions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
A connector-tokenized wallet settle reaches the account-resolution match in
PaysafePaymentsRequestasPaymentMethod::Card— the gRPCtokenpayment method maps to Card, so the wallet identity survives only inpayment_method_type.It therefore fell into the Card arm and resolved
card.<CURRENCY>.three_ds/no_three_ds, while the Tokenize leg had minted the payment handle on theapple_pay/google_payaccount. Paysafe rejects the mismatch:This restores the rule already documented directly above that match — wallet settles send NO accountId, because the payment handle carries its own account binding. The wallet CIT arm is deliberately untouched: a vaulted CONVERTED handle has no binding, so it still resolves an explicit account.
Reproduction
Sandbox Google Pay payment with
authentication_type: three_ds(pay_fz979retzyGT3PRkk2GW):status: PAYABLE,tokenType: GOOGLE_PAYPOST /paymenthub/v1/paymentscarriedaccountIdresolved fromcard.USD.three_ds= 10030474405068, paymentFAILEDConfirmed independently against the Paysafe API with Hyperswitch excluded: minting a handle on
1002671400and settling withaccountId: 1003047440returns the identicalfieldError.Verification
cargo check -p connector-integrationpasses.accountIdin the/paymentsbody — USD 1.00,authCode 149723,status: COMPLETEDon account1002671400. EUR was likewise charged earlier on1003044460(authCode 727050).No automated test added — the behaviour is only observable in the outgoing Paysafe body for a tokenized wallet settle, which the current unit-test harness for this connector doesn't cover.
🤖 Generated with Claude Code