PAYMENT_TOKEN_INVALID
PAYMENT_TOKEN_INVALID
The paymentToken on a CARD_ON_FILE payment cannot be used. The token is not a well-formed Gett card token, does not correspond to a usable card for the customer named on the order, or was issued in a different environment.
Summary
| Field | Value |
|---|---|
| HTTP status | 400 |
errorCategory | payment |
retryable | false |
When This Fires
POST /v1/marketfront/orders/place—payment.typeisCARD_ON_FILEand the suppliedpayment.paymentTokencannot be resolved to a card this order may charge.
A single code covers every cause. This is deliberate: reporting why a token was refused would let a caller probe tokens to learn which ones name real stored cards, so a malformed token, an unrecognized one, and one belonging to somebody else are all answered identically.
Recommended Action
- Confirm you are sending the token exactly as returned by
addPartnerPaymentMethod— the full string, unmodified and untruncated. - Confirm the token was vaulted for the same
customer.partnerUserIdyou are placing the order for. A card vaulted for one of your customers cannot pay for another's order. - If the card was vaulted a long time ago, vault it again and use the new token.
This is not retryable with the same payload.
Environments
Tokens are environment-specific. A token issued in sandbox cannot be used in production, and vice versa — the two environments do not share stored cards. The environment is visible in the token itself: pm_test_… is sandbox, pm_live_… is production. When a token from the other environment is presented, the detail message says so explicitly.
At go-live, re-vault every card against production. Sandbox-vaulted cards are permanently unusable there.
Example
Code