The checkout call the mobile SDK makes. A native app renders the card form itself, so this returns the values the SDK needs to collect and confirm a card — not the rendered payment UI that POST /api/v1/checkout returns for a browser.

You do not normally call this yourself: the SDK does, when the shopper presses Pay. It is documented so you can see exactly what leaves the device and what comes back.

No merchant credentials are required. The widget_token in the body authorises the call and names the merchant, order, amount, currency and shopper — so an app never holds your API key to take a payment.

Amount, currency and the shopper's email cannot be sent. All three are read from the widget token, so an app cannot name its own price or its own shopper and there is no mismatch to reject. Unknown fields — customer_email included — return 422 rather than being ignored.

Pay-by-bank note: It is a one-off approval at the shopper's bank: nothing is stored and no stored card is charged, so pairing it with save_card or saved_payment_method_id is rejected rather than partly honoured.

Token consumption: A rejection never costs the shopper their token. Every check this endpoint makes runs before the single-use widget token is spent, so a 400, 404 or 503 means no token was consumed and no payment was created.