OpenAI launched ChatGPT Walle yesterday and it appears to be a new “wallet model” build on card network agentic VAS (V, MA, AMEX). Agents pay with a network token instead of the card number, and the consumer authorizes each purchase within the OpenAI app. It is live for pro accounts inside dots today (US). Dots is OpenAI’s answer to Muse (Meta’s Muse: The Agent Becomes the Control Point). Launched September 29, Dots are a new class of autonomous agents built into ChatGPT. Unlike a normal ChatGPT conversation, a dot has its own cloud computer, persistent context, and access to the applications you authorize. Wallet is how a dot pays.
This is OpenAI’s second go round in checkout (see Explaining the Death of OpenAI’s Instant Checkout). in round 1, OpenAI tried to take the top of the funnel and the checkout, and merchants said no. ChatGPT Wallet is the opposite bet. The merchant stays merchant of record. The card keeps its rewards and dispute rights. The issuer makes the authorization decision. The token goes into the merchant’s existing checkout form. OpenAI has stopped trying to replace the payments plumbing and is now building on the networks’ plumbing.
There is much we DO NOT KNOW about the payment architecture. What we do know is within the published announcement, the ChatGPT Wallet Terms and the ChatGPT Wallet Privacy Notice. Together they say enough to sketch the design and to frame the questions that matter.
Executive Summary
- For investors: this is the first direct traction for network agentic value added services across all three networks, and the first real competitor to the Stripe Link model.
- ChatGPT Wallet is a new wallet model. The consumer enters the funding PAN (FPAN) into a cloud wallet, approves a specific purchase, and the network then generates a credential for that agent action.
- It is built on network VAS (Visa Intelligent Commerce, Mastercard Agent Pay, Amex ACE), not on a processor’s wallet. OpenAI gets the equivalent of Stripe’s Shared Payment Tokens and Link without depending on Stripe.
- It is better than AP2 (today). The consumer authorizes each transaction, and the network issues the credential that pays. The platform does not sign the payment on its own authority. AP2 is not built on cards, but cryptography without governance. Its hard to assign risk in this model.
- Issuers keep control. They approve every tokenization of their cards and can switch off their BINs at the agentic token stage if Meta’s fraud rises.
- US merchants keep the fraud risk. New tokens and broken device graphs complicate their fraud systems, so device data from the consumer’s approval must reach merchants, and probably issuers.
- A biometric check is not cryptographic proof of consent. I have four open questions: transaction binding, token type, token requestor, and what evidence reaches the issuer.
What We Know
- Card enrollment. A payment service provider collects the card number, expiration date, security code and billing information through a secure card form. OpenAI receives “a tokenized payment credential and limited card details, such as network, issuer, card type, last four digits, expiration date, billing country or postal code, and eligibility/status signals.” OpenAI “does not receive the full credit card number or security code” (Privacy Notice).
- Credential custody. “Our service provider retains underlying card data under its contract and applicable card-network and legal requirements” (Privacy Notice). OpenAI and its providers manage the tokenized credentials. The provider is not named.
- Transaction approval. The consumer reviews the merchant, items, total, card, and whether the purchase creates a recurring charge or hold, then approves with Face ID, a fingerprint or another check. The Terms limit the approval to “the merchant, items or services, amount, card, recipient, delivery details, and other terms shown to you.” A material change requires a new approval.
- Credential generation. After approval, “the payment network provides a payment token… with a card number, security code, and expiration date” (announcement). The Terms are broader: OpenAI “may ask a payment service provider, card network, or issuer to create or provide a tokenized, virtual, or other payment credential linked to your card.”
- Authentication evidence. OpenAI records “the purchase action you approved or rejected, the authentication result, time and device used,” and collects “passkey or authentication assertions” (Privacy Notice).
OpenAI also named its partners on the acceptance side: fraud providers Forter, Riskified, Sardine and Signifyd, and PSPs Adyen, Checkout.com and Stripe, who are working so their systems “recognize legitimate purchases made by agents.”
My Read of the Architecture
What follows is inference, not disclosure.
| Step | Likely mechanism | Who holds it |
|---|---|---|
| Enroll | FPAN captured in a cloud wallet/vault; OpenAI holds a reference token | Unnamed payment service provider |
| Approve | Device biometric unlocks a passkey (WebAuthn) tied to the ChatGPT app; the assertion goes to a cloud service | OpenAI |
| Generate | Agentic network token requested after a valid approval | Visa, Mastercard or Amex token service |
| Pay | The dot enters token number, expiry and security code in the merchant’s checkout with perhaps some 3DS information flowing to merchant in a give to get model | Merchant and its PSP |
| Authorize | Issuer decides | Issuer |
The card credentials are not likely to be stored on the device. The Terms say that “if a biometric check is performed locally by your device, OpenAI does not receive the underlying fingerprint or face scan,” which fits a passkey: the biometric unlocks a key on the device, and only a signed assertion leaves it.
A Different Wallet Model
| DPAN | Staged wallet (PayPal) | ChatGPT Wallet | |
|---|---|---|---|
| Where the credential lives | Device token, provisioned once at enrollment | Wallet holds the card; pays with its own credential | FPAN in a cloud vault; credential generated per approved action |
| Transactions per purchase | One | Two | One |
| Merchant of record | Merchant | Wallet on the funding leg | Merchant |
| Rewards and dispute rights | Card’s | Diluted across two legs | Card’s |
| Issuer sees | Device token and cryptogram | Wallet as merchant | Agentic token (evidence unclear) |
DPANs keep a device bound token next to the consumer in secure hardware storage. Staged wallets keep the card and put the wallet in the middle of the transaction. ChatGPT Wallet keeps the FPAN in the cloud, asks the consumer to sign a specific request, and has the network mint a payment credential for that agent action. I covered token mechanics in Tokens and Binding 101. The new piece is that the token is generated when the purchase is approved, not when the card is enrolled.
Issuers stay in control. Issuers control every tokenization of their cards. If fraud on agentic purchases rises, an issuer can switch off its BINs at the agentic token stage without affecting the card anywhere else (DOJ Probe: Network Tokenization).
Merchants Keep the Risk
In the US, this model leaves merchants responsible for fraud, as on any card not present transaction. The dot fills in a checkout form with a card number, expiry and security code. That creates work for merchant fraud systems. Two signals they rely on break:
- New card tokens. The agentic token has no history at the merchant. It does not match the card on file, past orders or the consumer’s account. Every purchase can look like a first purchase with a new card.
- Device graph associations. The dot runs on its own cloud computer. The merchant sees OpenAI’s browser and IP address, not the consumer’s phone or laptop. The device graph that links a consumer to their devices sees a data center.
The merchant is a relying party with no visibility into the consumer’s authorization. It has none of the AP2 mechanics to validate consumer intent cryptographically. My guess was that some device information must flow to merchants in this model, and the Privacy Notice supports it: “We may also provide device, security, and fraud information to merchants to help them assess the legitimacy of transactions.” That explains why OpenAI named Forter, Riskified, Sardine and Signifyd at launch. They need to learn to read that data.
If merchants get device data, issuers likely will too. The Privacy Notice says OpenAI discloses information to issuers and networks to “authorize or process a transaction, prevent fraud.” The obvious rails are 3DS and its device data container (DDC), already used to pass mobile device information for mobile authentication. That would give the issuer the consumer’s device behind the approval but “deviceID” would not be immuable IMEI, Apple doesn’t let apps have that ID, but rather a proxy that can evolve (IDFA) which is not ideal for fraud systems.
Compared With Stripe: Same Result, Different Owner
Stripe built the equivalent service internally w/ Link. Link stores the consumer’s cards, and agents pay with a one time card or a Shared Payment Token (SPT) scoped to “seller identity, max amount, currency, expiry, risk signals” (Timothy Chiodo, UBS, “Stripe Sessions 2026: Recap and Industry Takeaways,” May 2026). Each purchase needs consumer approval unless the consumer uses Link balance. In that post I argued Stripe is the only company that can make agentic payments work today, because it is the wallet, the card program and often the acquirer, and it can optionally underwrites the risk.
ChatGPT Wallet produces the equivalent with network value added services, independent of Stripe. OpenAI co-developed ACP with Stripe a year ago. In this launch Stripe is one of three PSPs helping merchants recognize the traffic, not the LINK wallet.
| Stripe Link (virtual card or SPT) | ChatGPT Wallet | |
|---|---|---|
| Who stores the card | Stripe | Unnamed provider |
| Payment credential | One time virtual card, or SPT | Network agentic token |
| Scope | Seller, max amount, currency, expiry | Unknown; network tokens can carry merchant, amount and time limits |
| Where it works | Any card merchant (virtual card); Stripe-connected flows (SPT) | Any merchant that takes the card brand |
| Merchant of record | Link on the funding leg (virtual card) | Merchant |
| Who governs | Stripe | Networks and issuers |
The virtual card flow has known issues and costs. Goldman called the Muse implementation “highly reliant on two-step transactions where Stripe charges the consumer’s card and then reissues a virtual card,” which “calls into question who is liable for fraud/chargebacks.” Goldman expects “V/MA’s agentic token platform to help streamline the payment flows, approval rates, fraud risk” (Goldman Sachs, Sep 2026). Mastercard said one time virtual card numbers “may serve as a bridge but are not its preferred long-term architecture” (UBS, Oct 2026).
OpenAI chose the long-term architecture from the start. The trade is that it now depends on issuer adoption, which Stripe’s VC model avoids.
Better Than AP2
In Google Rolls Out AP2 and Carts and Mandates I argued that AP2 lets the platform build, hold and sign the mandate. In the human-not-present flow the consumer signs an intent up front, and the agent completes the purchase later with no per-transaction approval. The platform grades its own homework (EMVCo Enters the Intent Wars).
ChatGPT Wallet does two things AP2 does not. The consumer approves each transaction. The credential that pays is generated by the network under the issuer’s tokenization rules, not by OpenAI. OpenAI still presents the approval screen and keeps the record, so it is not a neutral party. But it cannot pay without a credential that the network issues and the issuer can refuse.
That will change. OpenAI says users will eventually “pre-approve those purchases” within spending limits, categories or time periods. When approval moves from the transaction to a policy, the question becomes who holds the policy. Amex’s answer, in Intent Intelligence, is the issuer.
Biometric Authentication Is Not Proof of Consent
OpenAI says “each approval creates a clear record of the purchase the user authorized.” A record is a log in OpenAI’s systems. It is not proof that a third party can verify.
Face ID proves that the enrolled face unlocked the device, but the signature of this event is very “weak” software based credential interfacing with a cloud credential. A passkey assertion proves control of the authenticator by signing a challenge. If the challenge is a random nonce, the signature says nothing about the merchant, amount or currency. The standard for binding them exists: W3C Secure Payment Confirmation, a WebAuthn extension that puts the payee, amount and currency into the signed data. FIDO notes it can meet the PSD2 dynamic linking requirement (FIDO Alliance, “Using FIDO for the EUDI Wallet,” Apr 2023). I covered Google’s version in Google Secure Payment Authentication (SPA).
My Four Questions
1. Is the approval cryptographically bound to the transaction? A passkey assertion proves control of an authenticator. It does not prove that the consumer approved a particular merchant, amount and currency. OpenAI needs transaction binding, through the signed challenge or the token request, to provide that assurance.
2. What type of network token is generated? The announcement describes a credential with a card number, security code and expiration date. That is a card not present credential for existing checkout forms, not an EMV contactless token. It does not say whether the credential is single use, merchant restricted or limited by amount or time. UBS describes agentic network tokens in general as “a single use network token with domain restrictions related to consumer intent” (UBS, Oct 2026), but OpenAI has not said that is what Wallet uses. The Terms allow “a tokenized, virtual, or other payment credential,” so a virtual card fallback is not ruled out.
3. Who is the token requestor? OpenAI, the unnamed payment service provider, or another network-integrated partner. The token requestor holds the network relationship, sets the domain controls and answers to issuers. That role decides who owns the wallet. My guess is that the processing partners are token requestors (Stripe, Adyen, …. etc.).
4. What authentication evidence reaches the issuer? OpenAI records the approval. The announcement does not say whether the issuer receives standardized evidence of it, through 3DS or the token request, or whether that evidence stays with OpenAI and its partners. Visa says its model ladders up to “intent capture and ultimately the biometric signature” (Ryan McInerney, Visa Q4 FY2026 earnings call, Oct 27, 2026). Mastercard’s Verifiable Intent captures “a time window, merchant category code, dollar amount” (UBS, Oct 2026). Goldman warns that current protocols “are primarily designed to provide documentation/audit trail, as opposed to supplying banks with transaction level data” (Goldman Sachs, Sep 2026). Issuers will price agentic risk on what they can see.
What It Means for Investors
This is the first direct traction for network agentic value added services, and it spans all three networks. Visa, Mastercard and Amex have each launched agentic programs: Visa Intelligent Commerce, Mastercard Agent Pay, Amex ACE. Until now the volume came through partners, pilots and lab transactions.
First real competitor to the Stripe Link model. Today Stripe carries most agentic payments through Link: Stripe holds the card, issues the credential and governs the risk. ChatGPT Wallet shows a large agent platform can get the same result from the networks directly. If it works, other agent platforms have a template that doesn’t run through Stripe, and the networks earn token and value added service fees on every purchase.
What to Watch
- Issuer coverage. Which issuers allow agentic provisioning, and whether Visa and Mastercard issuers lag Amex, which is both issuer and network.
- Decline rates. OpenAI already warns that “risk systems may still flag legitimate purchases.” The fraud and PSP partners exist to fix that.
- Device data. What device and approval data reaches merchants, and whether issuers receive it through 3DS.
- Disclosure. A technical note from OpenAI or the networks on token type, token requestor and transaction binding would answer most of my questions.
- Delegated mode. Whether pre-approved purchases are governed by OpenAI, the network or the issuer.
- Stripe’s response. Link balance and SPTs against a wallet that doesn’t need them.
Verdict
ChatGPT Wallet is the right architecture. The consumer approves each purchase, the network issues the credential, the issuer can say no, and the merchant keeps the customer. That is a better design than a staged wallet and a better trust model than AP2. It also shows OpenAI learned from Instant Checkout: it now works with the payments system rather than trying to replace it. For the networks, it is the first proof that their agentic services can win a major agent platform without Stripe in the middle.
What is missing is proof of consent. Until the approval is bound to the transaction and that evidence reaches the merchant and the issuer, the security check protects OpenAI’s record more than anyone’s risk decision.