Options for Cards in Agentic Commerce (Sorry for typos.. )

My friend Simon Taylor wrote an excellent post on the 4 Models of Agentic Payments last week. Discussion in the industry is great, and while I respect Simon’s views, we are not entirely aligned. My focus today is on the card options. 

As I discussed in Agentic Wallets and Federated Data, the models of agentic commerce are in a very high state of flux. While early leaders like OpenAI’s Operator and Perplexity demonstrate the power of what is possible, Google, Amazon and others are in a much better position to use their deep consumer insights and direct connections (from phone and search to Alexa). The initial retailer reaction to Agentic is not positive, with one saying, “We are not looking to enable another Google to disintermediate us in product search; we have our own plans to use AI to improve consumer experience”.  What is certain? AI will profoundly impact how goods are sold and how consumers interact with retailers and specialists (see Hype and Reality of Agentic Commerce). 

Cards are the trust infrastructure for the internet today. While the model of agentic commerce is in flux, cards will be able to adapt. Let me list the known issues related to how agents operate in cards (in rough order of priority). 

1. What is an agent? A wallet? A merchant of record? A new type of intermediary? Rule sets take 2+ years to change. The easiest way to treat an agent is a wallet, but in V/MA rules (ex Staged Digital Wallet), Issuers can permission wallets. This means each Issuer can permission a given Agent. 
2. Merchants own the fraud risk in eCom (100% in US and 50% EU –  opt out of liability shift). Most eCommerce fraud controls are device-based, tying device history and risk to a payment token/ instrument. Agents do not have a device. The effort to distinguish good bots from bad bots will be a heavy lift without industry standards and governance. 
3. Visa CTF, Mastercard MDES and payment passkeys depend on device binding to tokens. 
4. Consumer Authentication is required for card authorization. Who does this? In the EU, step-up is the norm (and SCA requirement); with Apple DPANs, it is Apple that performs; within SRC, it is the network (which depends on device binding). 
5. Agent authorization. How does the consumer authenticate with an agent and authorize/authorize the activity? In my view, Simon’s virtual card UC is applicable here. The quickest near-term approach may be to qualify agents as “wallets” with defined standards and then seek Issuer permission for token issuance (to the agent wallet). Under current rules, the Issuer may step up for wallet or CTF/MDES transactions.

These activities have solutions, but how they operate within existing rule sets is complex. This is my decision tree.

I see 4 primary card options (green boxes) based upon who owns the risk

1. Agent owns risk – Agent is Merchant of Record. I just don’t see this happening unless it is Google, Apple or Amazon as the Agent
2. Merchant owns risk – existing eCommerce model. This is how agents work today, simulating a consumer on website. There are problems with transaction authorization because of device based fraud controls (even when the merchant owns the risk). Note that merchants prefer to use a COF for known consumer payment. Thus it is incumbant on agent to provide consumer ID and Auth (or passkey),  While mechants own the risk in eCom (US or opt out in ROW), I see a high probability of Issuer Step Up  (SCA requirement). 
3. Bank owns risk – 3DS/SRC liability shift (non US). Within the US, only Apple has the ability to pull this off as their DPANs provide for liability shift. Note that the 3DS experience will be similar to #2 above, but with lower authorization rates. Consumer experience will be a step up for EACH TRANSACTION within a given cohort of approved purchases. 
4. Consumer owns risk – Create a virtual card with restrictions and limit ability for consumer to dispute. This would be very hard to pull off. 

Cards can accommodate any of the above, with the Blue Boxes representing clusters of rules/considerations.

1. Device Binding. Device graphs in support of CTF/MDES and Payment Passkeys (see blog)
2. Tokenization. Applies to agent held cards in a “wallet” and the treatment of existing tokens with agent as intermediary. 
3. Rule Sets – 3DS, CTF/MDES, SRC, 
4. Agent Certification – For tokens, staged wallet, 
5. Issuer permissioning and provisioning to an Agent Wallet
6. Wallet Rules – ex Stage Digital Wallet vs Back to Back transaction
7. Consumer Authentication (by Agent and by Issuer) and Agent Authorization
8. Acceptance Frameworks and Authorization – MA TAF, Visa DAF

There are a hundred ways this could work out; my top two models today (this may change). 

1. Agent to existing wallets. A process similar to what I outlined in Google SPA, or with the final consumer payment delayed until the last phase (ie ApplePay). This would also placate US issuers as they attempt to build their own PAZE wallet and authentication service. Authentication and Authorization are key to reducing fraud. While Agents can’t perform the device binding, the mobile platform can be the final step.  The downside here is that Card Networks become much more dependent on mobile platforms for agentic commerce. 
2. Agent “lite” Wallet + Virtual Card/Escrow. Consumer permissions Agent for a Limited amount. Agent runs auth to create an “escrow” account. This Escrow account has virtual card issued; this VC is used for merchant transaction auth. Merchants can perform an authorization on the transaction, with goods held in a “basket” until final confirmation.  When transaction is finalized (with or without consumer in the loop), funds are moved back to back, taken from funding instruments into an escrow account and then to merchant.  This approach resolves many issues
   1. No Issuer staged wallet permissions.
   2. Provides path toward “specialized” Agent “device” registration
   3. Minimal ruleset changes
   4. Fits within 3DS rules and allows for Issuer Stepup
   5. No merchant or processor changes

Final thought. Stablecoins and smart contracts seem well placed to play a role in agentic commerce. But given merchant resistance to any new aggregator (err or “Operator”) I don’t see them jumping on acceptance. Stablecoin acceptance is a heavy lift by itself. Perhaps it will work in other markets. Today the core challenge is Authentication and Authorization (ie Trust Services). Card networks are the only scale solution.