A sale is not a payment until it is verified
Agent commerce often starts with natural language. A buyer agent asks for something, a merchant agent proposes an item, and both sides appear to agree. That is not enough for accountable payment.
ADI treats the sale as payable only when the conversational result has been turned into structured AP2 evidence and that evidence survives platform checks.
The validation chain
From agent offer to governed authorization
Each stage narrows the trust gap before the prepaid virtual card can be used.
flowchart TD
offer["Merchant agent offer"] --> intent["AP2 Intent Mandate"]
intent --> cart["AP2 Cart Mandate"]
cart --> payment["AP2 Payment Mandate"]
payment --> merchant["Merchant organization check"]
merchant --> catalog["Trusted SKU and product check"]
catalog --> policy["Buyer agent policy and wallet limit"]
policy --> card["Prepaid virtual card authorization"]
card --> receipt["Receipt, wallet ledger, and audit trail"]
merchant -->|fails| decline["Decline"]
catalog -->|fails| decline
policy -->|fails| decline Why the product list exists
The ADI product list gives the platform a deterministic object to validate against. It is not there because merchants need yet another product management screen. It is there because a trust layer needs a merchant-approved source for what may be sold through governed agent flows.
When the AP2 cart arrives, ADI can check the claimed merchant, SKU, active state, quantity, and amount against a known record instead of trusting whatever the agent wrote into the cart.
Why this is different from a normal checkout
In a normal checkout, the user sees the shop UI and the shop owns the payment flow.
In agent commerce, the buyer may never see the shop UI, so the trust layer must verify the commercial object independently.
The merchant agent can still be integrated into the shop, but ADI needs a second source of evidence before allowing agent-controlled payment.
Receipts and audit logs must reference the verified mandate path, not only the final card transaction.
The strict payment rule
For ADI, the buyer agent should continue using only its assigned virtual issuing card. Direct use of the customer's bank account or corporate credit card by the agent must remain blocked.
If auto-reload is enabled, the customer's funding source can refill the wallet under policy. That still does not give the agent direct access to the underlying funding source. The agent spends from the prepaid wallet-backed card only.
What must be visible afterwards
The buyer should see which agent acted and which mandate authorized the spend.
The merchant should see the incoming transaction and the catalog object that was sold.
The admin should see wallet, payment, trust, notification, and audit events.
The platform should be able to reconstruct the transaction from intent through receipt.