Skip to main content
Follow one checkout from your agent to the merchant, and see the one point where a token becomes your real card number.

​
The pieces

​
A checkout, step by step

1

The agent reads its token catalog

With its API key, the agent asks the backend which tokens it may use. It gets mock tokens plus the card brand and last four digits.
2

The agent opens a proxy session

It connects to the proxy over a WebSocket with the same key. The proxy starts a browser for this session.
3

The agent shops

It opens the product page, adds to cart and goes to checkout. For name and address fields it sends tokens, and the proxy types the real values on a site you have authorized as a destination.
4

The agent fills the card number with a token

The proxy reads the order total from the page and asks the backend to check the key’s scope, your merchant rules, whether the site is an authorized destination, your limits and your approval threshold. If the purchase needs your approval, the checkout waits for you.
5

The backend records the transaction and allows the fill

Recording first keeps your limits accurate even if something fails later.
6

The proxy types the real card number

It fetches the number from the vault, holds it in memory while it types it into the merchant’s field, and stores it nowhere. Until the session closes, it keeps the number’s spellings in memory, only to scrub them from what the agent is later shown. The Agent Vault backend never receives it.
7

The agent submits and reports the outcome

The agent clicks pay. The proxy tries to record the session’s events and outcome for the Activity page. Recording is best effort and never holds up the agent, so an event that fails to save is missing rather than retried.
The same path as a sequence diagram: The card number appears in cleartext only at steps 12 and 13: in the proxy’s memory, then on the merchant’s page. The proxy uses it for that one fill, and keeps its spellings in memory until the session closes only to scrub agent-facing output. The agent and the backend never receive it.

​
What is checked at the moment of a fill

Every fill goes through the same decision. A refusal at one of these checks returns an error code the agent can act on, and nothing is typed. A failure after typing has started is different: with fill_rejected, a page that goes away mid-fill, or typing that fails partway, some or all of the value may already be on the page, and a card transaction can stay counted. Each code’s entry in Error codes says how to recover. Two consequences for anyone writing fill steps:
  • The transaction is recorded before the number is revealed. A failure after that point can leave a recorded spend with no charge. Error codes say which failures do.
  • The card number authorizes exactly one security code fill. The next page action uses it up, so fill the security code immediately after the number. See The card fill order.

​
Where each secret lives

Details: Card storage, CVV policy and TOTP handling.

​
What the agent can see and where its traffic goes

  • Reading the page. After the first token fill, screenshots go black and the page snapshot is refused for the rest of the session. Have the agent look at the page before it fills anything. Full table: Agent context.
  • Network address. By default the SDK tunnels the browser’s traffic out through your machine, because many sites block datacenter addresses. See Egress and tunnelling.
Next: Choose an integration to pick how your agent connects.