Checkout preparations
Approve before checkout
Ask the user to approve before a short-lived card tokenization request starts.
POST
Ask the user to approve the merchant and amount before your browser clicks Pay. The user picks a card and keeps the approval page open. Your browser then starts one fresh card request while the approval is ready. Approval does not mean the merchant received payment.
Use
Start Pay immediately after the preparation becomes
Retry with
controller.prepare() with the checkout SDK on Playwright or CDP. Call this API directly only when your integration handles request interception. Create the preparation before the first card request; a preparation cannot resume an earlier request that timed out.
string
required
The connected user whose added card pays.
string
required
The merchant name shown to the user. Up to 120 printable characters.
integer
required
The displayed amount in the smallest currency unit. For example,
100 with usd displays $1.00; the card token does not enforce the merchant’s eventual charge.string
required
The ISO 4217 currency code, such as
usd.string
required
square, braintree, worldpay, bambora or mercado_pago.string
required
Use
token.string
required
A stable key for this checkout attempt, from 16 to 128 characters. An identical request returns the existing preparation; a changed merchant, amount, card or other approved value is refused.
string
required
The exact HTTPS merchant origin, such as
https://merchant.example. Use http://localhost only for local checkout.string
required
Use the processor’s environment from the table below.
string
Preselect one of the user’s added cards.
Bambora and Mercado Pago use the same endpoint for test and live requests.
shared does not select test mode. Configure the merchant’s processor account for testing; Agentcard cannot determine that account’s mode from the request URL or a key prefix. The response’s sandbox field describes the connected app’s Agentcard mode separately.
Braintree configuration queries do not consume an approval. Braintree saved-card operations, compound mutations and its REST fallback cannot use a preparation. Worldpay, Bambora and Mercado Pago preparations require fresh card details; saved-card and recurring requests cannot use the approval.
The request and responses below come from a local API test with sample user and card records. The test made no processor request. Replace the user and card identifiers with your connected user’s values.
Send the request
string
awaiting_approval waits for the user. ready allows one fresh request until ready_expires_at. bound links to authorization_id; cancelled and expired cannot be used.string
Deliver the link when the preparation is created. The user must keep the same page open after approving.
ready. Readiness lasts at most 30 seconds. A changed checkout, navigation, cancellation or early request prevents the SDK from using the approval. Check the merchant’s outcome before creating a new checkout attachment; the SDK never retries the payment automatically.
Correct the environment
An unsupported processor and environment combination returns HTTP400. For example, Worldpay with environment: "shared" returned this response from the local API test:
environment: "sandbox" for the Worldpay sandbox: