You might ask an AI agent to "book a hotel that fits my business trip," but handing over your full card number at the end is a different matter entirely. Simply hiding the number can already be done with existing network tokens—but with AI, you also need to convey "on whose behalf, at which merchant, and up to what amount" it's allowed to pay. The partnership Visa announced with OpenAI on June 10, 2026, plans to connect OpenAI's agentic experiences to Visa's tokenization and authorization infrastructure to handle exactly this kind of conditional payment authority. If we think of an Agentic Token not as an alias for a card but as a restricted form of proxy authority, it becomes clearer where we should be checking the safety of AI-driven payments.
Not a copy of the card, but conditional proxy authority
The 16-digit number on a credit or debit card is called the Primary Account Number (PAN). A standard network token replaces the PAN with a different number, and the payment network internally maps it back to the original account. This lets merchants and apps process payments without storing the PAN itself, making it harder to reuse a leaked value elsewhere.
Tokenization itself predates AI. Mobile wallets, for instance, can issue a different token for each device even when the same card is registered. According to Visa's developer documentation, usage can also be restricted to a specific device or merchant, with limits on the number of uses, transaction caps, and expiration dates. In short, it's an alternative credential: the PAN is swapped for another representation, and the payment network manages its scope of use and validity.
An Agentic Token adapts this network token concept specifically for AI-driven purchases on a user's behalf. Visa's design binds agent credentials to a specific agent and purchase context, checking them against authenticated user instructions.
| What's being distinguished | Primary role | Example restrictions |
|---|---|---|
| PAN | The original number identifying the card account | Determines card account status and issuing bank |
| Network token | Hides the PAN from merchants and devices | Device, merchant, expiration, transaction limits |
| Agentic token | Credential the AI uses to make purchases on your behalf | Agent, merchant, amount, authenticated instructions |
A hotel key card is a useful analogy. A guest doesn't receive a master key to the entire building—only a key that opens their designated room, and only for the duration of their stay. Likewise, an Agentic Token doesn't give an AI unrestricted access to an account; it gives the AI the ability to issue payment requests within a defined scope. That said, a key card doesn't run a credit check with the issuer every time it's used, nor does it log the guest's purchase instructions. The analogy only captures the idea of narrowly scoped authority—the actual approval and fraud detection within the financial network operate separately.
Six steps connecting registration to approval
In the publicly described flow of Visa Intelligent Commerce (VIC), issuing a token isn't the end of the process. Consider asking a travel AI to book a hotel—here's how the process would unfold:
- Register the agent and the card. The AI provider joins VIC, and the user adds their Visa card to their account on the agent's platform. After additional cardholder verification, an agent-specific token is issued, and a passkey is set up to authenticate future instructions.
- Authenticate the purchase instruction. The agent presents candidate hotels and asks the user for approval to book. The user authenticates a Payment Instruction—including the merchant and amount—using their passkey.
- Obtain the payment credential. When the agent is ready to process payment, it requests a credential from VIC. VIC checks whether the request matches the authenticated instruction and sets network-level controls corresponding to the target merchant and amount.
- Present it to the merchant. The agent passes the obtained credential to the merchant's guest checkout or API. Early implementations may include entering the value into an existing web form.
- Approve it over the payment network. When the authorization request reaches VisaNet from the merchant, it's checked against the controls to confirm it came from the intended merchant at the correct amount. Standard real-time authorization and fraud monitoring still apply—meaning the AI holding the token doesn't decide on its own whether the payment goes through.
- Log the result. The agent reports the success or failure of the purchase back to VIC. Visa states that the user's instructions and the transaction outcome can be used for dispute resolution and fraud prevention.
In this flow, what the user hands to the AI isn't "use this card freely." It's an instruction that includes the hotel, amount, and whether approval is required—and the output is that only transactions matching those conditions get routed into the approval pathway. The fact that the network itself can reject requests that deviate from the instruction is what distinguishes this from designs that rely solely on a confirmation button in a chat window.
Matching the conditions is a necessary condition for approval, not a guarantee of a successful payment. Whether the card can be used, or whether fraud is suspected, is still determined through the issuer's and Visa's existing approval pathways. Conversely, a request that doesn't match the instruction won't go through even if the account has sufficient balance or credit. This dual layer of judgment keeps the AI's proxy authority separate from the credit assessment of the card account itself.
Separating identity, consent, and credentials
If malicious software steals a valid token, checking only "is this number genuine" won't be enough to determine whether it's a legitimate proxy purchase. AI payments require at least three distinct proofs: the agent's identity, the user's instruction, and the payment credential. Each answers a different question.
Visa's Trusted Agent Protocol uses signed information to verify whether the software visiting a merchant is an approved agent, and whether its purpose is browsing or purchasing. This lets merchants distinguish it from ordinary bots or attackers, and decide whether to allow only product browsing or to let it proceed to payment. This is the layer that confirms "who showed up."
A Payment Instruction authenticated via passkey fixes "what the user asked for." For example, authority to search for a hotel that fits a company's travel policy is not the same as an instruction to book a specific presented room at a specified price. Scope may be broad during the search phase, but it narrows to merchant, amount, and approval conditions at the moment of payment. VIC's design also includes APIs for updating or revoking instructions afterward.
What the Agentic Token handles is "what can be used to pay." VIC checks credential requests against the authenticated instruction, and re-verifies authorization requests coming from the merchant as well. Rather than bundling the signature, the instruction, and the token into a single secret, they're linked as separate verification checkpoints. Since not all merchants may adopt the Trusted Agent Protocol, agent identification won't necessarily be enforced with the same rigor everywhere.
The division of labor connecting ChatGPT and VisaNet
Visa's announcement describes integrating payment functionality "into OpenAI experiences." This doesn't mean VisaNet's authorization processing moves inside the chat window itself. Rather, it's a division of labor: agentic experiences like ChatGPT receive the user's request, Visa handles credential issuance, matching against instructions, network authorization, and fraud monitoring, and the merchant—as the seller—processes the order and fulfillment.
This also needs to be distinguished from OpenAI's own Agentic Commerce Protocol (ACP). OpenAI's current documentation describes ACP as a connective layer that links merchants' structured catalogs and inventory to ChatGPT, enabling products to be presented within a conversation. VIC and the Agentic Token, on the other hand, handle payment credentials tied to a card account and the conditions of their use within the payment network. The language for discovering products and the authority for moving money are two separate things.
Take buying shoes as an example: ACP is the pathway through which the AI understands color, size, stock, and the retailer. Once the user selects a pair, VIC prepares a credential matching that retailer and amount, and authorization is obtained through the merchant's payment pathway. When both are connected, the process can flow from conversation to purchase—but the mere fact that a product appears via ACP doesn't imply payment authorization, and possessing an Agentic Token doesn't guarantee inventory availability or shipping.
Not "leak-proof," but "unusable if it deviates"
An Agentic Token reduces PAN exposure and narrows authority. Even so, problems remain: the AI might select the wrong product, get steered toward a fraudulent merchant, or be influenced by instructions embedded in external content. If a user authenticates an overly broad purchase instruction, a transaction could technically stay within the conditions while still falling outside what the user actually expected. Responsibility for returns, shipping, and chargebacks also isn't settled simply by issuing a token.
Consider a corporate agent that automatically restocks office supplies. Setting only a monthly budget is too crude a control. You'd need to combine merchant category, product type, per-transaction limits, and conditions that trigger a need for approval—while keeping a record of instruction changes and actual purchase outcomes. Operational design should also include how to halt authority, how to revoke a token, and what channel a staff member has to raise an objection.
A stop mechanism isn't just an emergency-only decoration. Visa's token management APIs assume full lifecycle management—not just activating and suspending a token, but also resuming or deleting it. For a business, this means removing stale authority whenever staff change roles, procurement policy changes, or a contract with an agent provider ends. Even with finely detailed payment conditions, if no one is responsible for the revocation process, the safety margin will keep expanding over time.
There are also caveats about availability. The Visa Developer Center describes VIC as being in development and rollout, and notes explicitly that the published procedures represent potential functionality that may not be available in every market. Visa and OpenAI's joint announcement likewise hasn't finalized which OpenAI products, regions, or general-availability dates are covered. The announcement of the partnership alone doesn't support the conclusion that "ChatGPT can already autonomously make Visa payments."
When evaluating AI payments, the point to check isn't merely whether the card number was hidden—it's whose agent is being recognized, which instruction the person themselves authenticated, where deviations in merchant or amount get rejected, and who can audit the results afterward. If these are implemented separately, and authority can be updated or revoked, then the Agentic Token can decouple convenient automated purchasing from the act of handing over an entire account.