Card Rails and PCI Compliance

An order intent lets an agent pay with a user’s saved card, within a limit that the user approved. This page explains the rails that an order intent pays on, and how to stay PCI compliant.

​

Card Rails

A rail is the way an order intent gives a payment credential to a merchant. One order intent can have several rails, and the agent gets a new credential for each payment. The card network rails give the strongest protection, because the network enforces the limit: A card gets a network rail when it is enrolled in Visa Intelligent Commerce or Mastercard Agent Pay. See the eligible cards in the Agent Cards Quickstart. The Stripe shared payment token works only at sellers that accept it. The encrypted card is the fallback for every other card.

​

How to Stay PCI Compliant

Collect cards only with the Crossmint card form. A card that a user types into your own form, or into a chat message, goes through your systems. Then pay in one of two ways.

​

With Agent Checkouts

Agent Checkouts is the Crossmint API that buys on merchant websites for your user. When the checkout asks for payment, your app sends only the orderIntentId. The checkout gets the credential and enters it at the merchant inside Crossmint’s PCI-compliant systems. So the checkout can use any rail, including the encrypted card, and your app, your agent, and the model never get card data. Every saved card works, and you do not enable anything. Agent Checkouts does not accept card details in the task, in messages, in buyer profiles, or in form answers.

​

How Agent Checkouts Picks the Rail

Agent Checkouts first uses the agentic token rail of the card’s network: Visa Intelligent Commerce for a Visa card, and Mastercard Agent Pay for a Mastercard card. When that rail is not available, Agent Checkouts uses the encrypted card. The model and the buyer do not choose the rail. When Agent Checkouts uses the encrypted card, the card stays inside the Crossmint vault: the checkout enters it in the merchant’s card fields, and Crossmint keeps the purchase within the order intent’s amount. You do not need encrypted card access for this. The encrypted card needs the card’s security code (CVC). Crossmint keeps the CVC for a limited time after the user saves the card. After that time, the user must type it again. See Ask for the CVC Again.

​

With Your Own Checkout

With your own automation, such as your own browser agent or a merchant API, your code gets a credential from the order intent for each payment and enters it at the merchant. See Get a Card Number for the requests. Your PCI scope depends on the rail:

• A network rail (rail: "agentic-token", with provider vic or agentpay). Your code gets a one-time card number for the amount that you request, and the card network enforces the amount and the merchant. Visa considers network tokens and single-use card numbers out of PCI DSS scope.
• A Stripe shared payment token (rail: "spt"). Your code gets a token for one seller that accepts it, not card data.
• The encrypted card (rail: "encrypted-card"). Your code gets the real card number, encrypted to your RSA public key, so your setup must be PCI compliant. In production, your project also needs encrypted card access. The card network does not enforce the limit, so your code must keep each purchase within the amount that it got and the order intent’s merchant. To set up the encrypted card for your own automation, contact us.

Choose a network rail when it is active, and the encrypted card only when no network rail can be used. Let your code, not the model, enter the credential in the merchant’s card fields. Give the model only the orderIntentId, and do not log or store the credential. Your qualified security assessor (QSA) confirms your final PCI scope.

​

See Also