Skip to main content
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.