Three Identities Behind Every AI Payment: Customer, Device, and Agent

AI payments create an identity problem that many existing payment systems were never designed to represent.

In a traditional flow, the architecture often revolves around one question:

Is the customer authenticated?

With autonomous agents, that is no longer enough.

A customer may authorize something now, an AI agent may execute it later, and the customer's device may not even be online when the payment actually reaches the merchant.

That means the backend has to distinguish multiple principals and signals instead of treating everything as one authenticated session.

The Problem

An AI-initiated payment can involve three distinct identity concerns:

• Customer identity — whose authority is being exercised?
• Device/app assurance — under what execution context was that authority created?
• Agent identity — which autonomous system is exercising the delegated authority?

These are related, but they are not interchangeable.

A trustworthy device does not prove that the customer intended a specific payment.

An authenticated customer does not mean an autonomous agent should receive unlimited payment authority.

And an authenticated agent does not prove that the transaction it selected is actually allowed.

A useful mental model is:

Customer
   |
   | grants constrained authority
   v
Mandate
   |
   | delegated to
   v
Agent
   |
   | executes within constraints
   v
Payment

The authorization relationship matters as much as authentication itself.

Where It Gets Difficult

1. Customer Presence and Customer Authority Are Different

A customer might tell an assistant:

Book a flight to Delhi tomorrow morning if it costs less than ₹7,000.

The customer may leave the application immediately afterward.

Thirty minutes later, the agent finds a ₹6,450 flight and attempts the purchase.

The backend cannot depend on the customer still being present in the UI.

Instead, it needs structured evidence of what was previously authorized.

For example:

customer: C102
agent: travel-agent-A
destination: DEL
departure: before 12:00
maximum amount: ₹7,000
expires: tonight

That mandate is much safer than giving the agent a broadly reusable customer token.

2. Device Assurance Is Context, Not Identity

Mobile platforms can provide evidence about the application or device environment involved in a sensitive authorization event.

That evidence is useful for risk decisions, but it should remain separate from customer identity.

The architecture should think in terms of:

device/app assurance at authorization time

rather than:

trusted device forever

Apps can be reinstalled, keys can rotate, devices can change, and an agent may execute the approved action later from a cloud environment.

3. The Agent Needs Its Own Identity Boundary

If every autonomous system simply forwards the customer's bearer token, the backend cannot easily distinguish:

• A customer-facing application
• An AI assistant
• A backend tool acting for that assistant
• Another automation process holding the same credential

The agent or workload should therefore be independently identifiable according to the system's trust model.

The backend should be able to establish both:

Customer C authorized this action.

and:

Agent A is exercising that authority.

Those are separate statements.

4. Identity Does Not Solve Payment Reliability

Even when all identities are correct, payments can still fail in ordinary distributed-systems ways.

Suppose:

1. The agent calls the payment API.
2. The processor accepts the payment.
3. The response times out.
4. The agent retries because it does not know whether the first call succeeded.

Without idempotency, that can become a duplicate charge.

A logical payment operation should therefore carry a stable idempotency identity:

payment_intent  = PAY-98231
idempotency_key = PAY-98231

Agentic systems make retry safety more important, but they do not replace the need for payment state machines, reconciliation, and explicit failure handling.

Architectural Direction

A stronger AI-payment design separates identity from delegated authorization.

The backend should be able to answer:

• Who owns the authority?
• Which agent is exercising it?
• What was that agent actually allowed to do?
• Under what app/device assurance was the authority created?
• Which payment instrument may be used?
• Which merchant is allowed?
• What is the amount ceiling?
• Has the authorization expired or been revoked?
• Has this logical payment already been attempted?

The important architectural shift is:

customer → payment

becoming:

customer
   ↓
constrained mandate
   ↓
agent
   ↓
transaction validation
   ↓
payment

That separation makes several controls possible:

• Independent agent revocation
• Narrow payment permissions
• Merchant and amount binding
• Step-up approval for higher-risk transactions
• Agent-specific observability
• Better fraud investigation
• Clearer audit trails
• Safer retry handling

It also creates a cleaner authorization model.

An LLM may interpret:

Find me a morning flight under ₹15,000.

But once that intent becomes:

departure < 12:00
amount <= 15000 INR

the payment boundary should enforce those rules deterministically.

The model interprets intent.

The backend enforces authority.

The Takeaway

AI payments should not be modeled as:

A customer logged in, therefore the agent can pay.

A better architecture asks:

Which principal is acting, whose authority is it exercising, under what conditions was that authority granted, and does this exact transaction remain inside those boundaries?

That means keeping customer identity, device/app assurance, agent identity, constrained authorization, and payment state logically separate.

No single signal makes an AI-initiated payment trustworthy.

The architecture becomes safer when each one answers a different question.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

#AIArchitecture #AgenticCommerce #PaymentSecurity #FinTech