Card not present. Person not present.

An agent can have access to a payment method and still lack permission to make a purchase. This matters to the merchant accepting the order, the credit card company processing the payment, and the person expected to pay the bill.

The payment industry built the infrastructure for card-not-present commerce. Now it faces another challenge: card not present, person not present.

Your agent has the card. It clicks buy. You're asleep. Who can prove that you approved this purchase?

The missing person changes the problem.

Payments already handles subscriptions and scheduled charges. What's different with agentic commerce is that it’s software interpreting your instructions, choosing what and when to buy something.

You tell an agent to buy two concert tickets for no more than $300, including fees. It finds seats for $290. At checkout, the total becomes $382. It buys them anyway.

The card is valid. The agent is legitimate. But, the purchase is outside your permission.

This is an identity and authorization problem. The merchant needs evidence of who gave the instruction and what that person actually approved. The credit card issuer needs that context, too.

Proving the agent had access to your card isn’t enough.

The protocols need a record worth trusting.

The industry is building the connections. UCP supports commerce and checkout flows. Visa's Trusted Agent Protocol helps merchants recognize agents and receive authorization information. AP2 and Verifiable Intent address signed evidence of what the buyer permitted.

The next question is concrete: who's going to produce a signed record that everyone in the transaction is willing to rely on?

The AI saying in a chat conversation that "Ian approved this" isn't enough. Neither is the merchant recording "customer consented" in its database. The approval needs to come from the owner, through a process the receiving parties trust.

Proof connects the record to the owner.

Proof supplies the identity and signing infrastructure. The owner supplies the permission.

Our transaction signing binds a verified person's identity to the exact terms they approve. Our Delegate Authority capability lets that person authorize a named agent within a defined scope, signed with a key bound to their credential.

For the ticket purchase, the record should say:

"I'm Ian. I authorize this agent to use this payment method to buy two tickets to this show for no more than $300, including fees. This permission expires tonight."

The owner reviews and signs those terms. Proof's identity credential gives recipients a basis for verifying who signed. The signature gives them evidence of what that owner approved. Participants agree on which issuers, verification controls, and records they will accept.

That's how the record becomes a shared basis for action. Nobody has to take the AI's word for what the owner wanted.

Think of it as a signed agreement expressed in data, with terms software can check. Its legal effect depends on the transaction and applicable requirements, but its practical job is familiar: preserve who agreed to what.

It's a receipt for permission, created before the purchase.

Permission needs to arrive with the payment.

That record should travel with the payment request, or remain securely linked and available for verification. It gives each participant something concrete to check:

• The agent has explicit limits. A $382 order needs new permission.
• The merchant can verify the approval and reject an order outside its terms.
• The payment credential provider checks that the owner can use the designated card and that the agent is authorized to access it.
• The credit card issuer can consider evidence connecting the owner, the delegation, and the purchase when deciding whether to authorize payment.

The signature makes changes to the approved terms detectable. Checking the actual order against those terms catches an agent exceeding its authority. Both checks have to happen; attaching a record nobody verifies accomplishes nothing.

This is where Proof fits: producing verifiable evidence of the owner granting authority, so payment participants can perform their checks and retain the evidence. It complements the bank's authentication, risk controls, and payment decision.

Card not present required a way to accept payment at a distance. Person not present requires a way to verify permission at a distance.

The agent can click buy. The owner's permission needs to arrive with it.