The card payload for Pay an order. Which authentication path
the customer takes depends on the card and on the optional authOption field.
Endpoint
Authenticate with your public key. See Authentication.
Payload (before encryption)
Card object
Card details go inside the encrypted payload — they are never sent in plain
JSON. Encrypt on your server, not in the browser, so card data stays off your frontend
and out of your logs.
3-D Secure (the default)
The usual path: the customer is redirected to their bank to authenticate.
The response carries a redirectUrl — send the customer there.
pending-authenticaion means the customer has not paid yet. Poll
Get order status until isFinalStatus is true.
Saving a card at charge time
Add saveCard to the card object. The card is only saved if the charge succeeds.
If the customer only decides to save the card after seeing the payment succeed, use
Save a card instead.
Skipping authentication
Some cards support charging without a step-up. Set authOption to NOAUTH.
NOAUTH is a request, not a guarantee — the issuer can still require authentication, in which
case you get a redirectUrl back as normal. Always handle both outcomes. Skipping
authentication also shifts chargeback liability towards you.
Charging a saved card
Send only savedCardId. The id comes from the savedCards array in the
create-order response.
For recurring or off-session billing, where there is no customer present to complete a
step-up, use Tokenized charge with your secret
key instead.
Common errors
Testing
Test card numbers for each authentication path are issued with your sandbox credentials. See
Sandbox testing.