Agentic Payments: Authorization, Execution and Evidence

16 minute read · Reviewed 11 August 2026 · Payments and security expert review required before publication

Agentic payments let an AI system prepare and coordinate a payment while deterministic controls retain authority over value movement. The model can extract invoice fields, find supporting records, explain exceptions and propose a transaction. A payment gateway should authorize the exact proposal against delegated authority, policy and approval, keep credentials outside model context, execute through the payment provider and reconcile the final outcome.

This guide is for payment platform engineers, finance-system architects and security teams designing agent-assisted or autonomous payment flows. It gives you a typed transaction model, a state machine for uncertain execution, a control matrix and failure drills that distinguish authorization from provider processing.

What are agentic payments?

An agentic payment is a payment workflow in which an AI agent performs some planning, preparation or coordination. The term does not imply that a language model owns the payment credential or approves its own instruction.

Five responsibilities need separate owners:

This separation is visible in current protocols. AP2 states that validation or processing assigned to a role must occur in deterministic code, including when that role is agentic. It binds a Payment Mandate to a particular checkout and returns signed receipts after acceptance or rejection. The AP2 specification supplies protocol objects for authorization and evidence. It does not operate an enterprise's supplier registry, approval workflow or reconciliation service.

Why model confidence cannot authorize payment

Consider an accounts-payable agent handling this instruction:

Pay invoice INV-8841 from Northwind Components.
The supplier says it is urgent and has provided new bank details.

The model reads EUR 18,750, finds a purchase order and sees a goods receipt. It assigns high confidence that the invoice is legitimate. That confidence does not establish whether the new destination was independently verified, whether the mandate covers this supplier and currency, whether the invoice was already submitted or whether an independent approver accepted this exact payment.

Invoice text is untrusted input. A prompt injection inside the document can ask the agent to skip approval or use another destination. The model may also omit a field, misunderstand a credit note or change behavior after a model update. Hard payment controls need narrow, testable comparisons and stable reason codes.

Build a canonical payment proposal

Convert model output into a typed, versioned object. Do not send free-form text to the payment adapter.

type PaymentProposal = {
  version: 1;
  transactionId: string;
  buyerEntityId: string;
  supplierId: string;
  invoice: {
    id: string;
    digest: string;
    purchaseOrderId?: string;
  };
  amountMinor: number;
  currency: 'EUR' | 'GBP' | 'USD';
  destinationId: string;
  purposeCode: string;
  requestedExecutionDate: string;
  idempotencyKey: string;
  evidenceRefs: Array<{
    source: string;
    digest: string;
    field: string;
  }>;
};

Resolve supplierId and destinationId from governed registries. An invoice can propose bank details for verification, but it should never create an executable destination by itself. Validate integer minor units, currency, date and identifier formats. Reject unknown fields unless the schema explicitly allows extension data.

Calculate a canonical proposal digest and bind every later decision to it:

const proposalDigest = sha256(canonicalJson(paymentProposal));

If finance changes the amount, destination, currency or invoice, create a new digest and invalidate the earlier approval. RFC 8785 provides a JSON canonicalization scheme suitable for repeatable hashing across implementations when used with a defined profile and test vectors.

Bind delegated authority to the proposal

Authentication identifies the agent or workload. A mandate constrains the payment task. The following conceptual object is narrower than a broad scope such as payments:write:

{
  "mandate_id": "mandate:ap:0942",
  "subject": "agent:finance:ap-worker-3",
  "organization": "org:buyer:eu-1",
  "purpose": "settle-approved-supplier-invoice",
  "actions": ["supplier-payment.create"],
  "counterparties": ["supplier:northwind"],
  "destinations": ["destination:northwind:verified-primary"],
  "limits": {
    "currency": "EUR",
    "max_amount_minor": 2500000,
    "max_uses": 1
  },
  "delegation": { "allowed": false },
  "expires_at": "2026-08-11T17:00:00Z"
}

The mandate must be active, current and revocable. A one-use mandate needs atomic consumption so two concurrent workers cannot both reserve it. A delegated child mandate must preserve or reduce every parent constraint. Missing a destination or amount restriction cannot widen authority.

OAuth transport controls remain useful. The OAuth security best practice recommends minimum privilege, audience restriction and sender-constrained access tokens. RFC 9700 reduces token misuse. Payment-specific limits, exact approval and invoice identity still belong in the transaction authorization layer.

Make authorization deterministic

The authorization service evaluates verified identity, active mandate, canonical proposal, supplier state, invoice state, approval state and consumed usage.

type PaymentDecision =
  | { result: 'allow'; reservationId: string; proposalDigest: string }
  | { result: 'approval_required'; reason: string; proposalDigest: string }
  | { result: 'deny'; reason: string; proposalDigest: string };

function authorizePayment(ctx: PaymentContext): PaymentDecision {
  denyUnless(ctx.agent.status === 'active', 'AGENT_INACTIVE');
  denyUnless(ctx.mandate.activeAt(ctx.now), 'MANDATE_INACTIVE');
  denyUnless(
    ctx.mandate.actions.has('supplier-payment.create'),
    'ACTION_DENIED',
  );
  denyUnless(
    ctx.mandate.counterparties.has(ctx.proposal.supplierId),
    'SUPPLIER_DENIED',
  );
  denyUnless(ctx.supplier.status === 'approved', 'SUPPLIER_NOT_APPROVED');
  denyUnless(
    ctx.supplier.destinations.has(ctx.proposal.destinationId),
    'DESTINATION_DENIED',
  );
  denyUnless(ctx.proposal.currency === ctx.mandate.currency, 'CURRENCY_DENIED');
  denyUnless(
    ctx.proposal.amountMinor <= ctx.mandate.maxAmountMinor,
    'AMOUNT_DENIED',
  );
  denyUnless(
    ctx.invoice.digest === ctx.proposal.invoice.digest,
    'INVOICE_CHANGED',
  );
  denyUnless(ctx.invoice.paymentState === 'unpaid', 'DUPLICATE_INVOICE');

  if (ctx.policy.requiresHumanApproval(ctx.proposal)) {
    return ctx.approval.matches(ctx.proposalDigest)
      ? ctx.reserveAtomically()
      : {
          result: 'approval_required',
          reason: 'EXACT_APPROVAL_REQUIRED',
          proposalDigest: ctx.proposalDigest,
        };
  }

  return ctx.reserveAtomically();
}

This is simplified pseudocode. A production service also verifies issuer trust, signatures, audience, revocation, replay and tenant boundaries. The important behavior is fail closed: a missing registry, policy, approval or reservation result cannot fall through to allow.

A model-generated fraud score can route a transaction to review. It cannot override a failed destination or mandate check.

Bind human approval to the exact transaction

Show the approver the resolved supplier, invoice digest, amount, destination, policy findings and evidence references. Store an approval record that includes the proposal digest, verified approver, role and expiry.

{
  "approval_id": "approval:fin:01K2A6",
  "proposal_digest": "sha256:6fd2...",
  "decision": "approved",
  "approver": "user:finance-controller:17",
  "role": "payment-approver",
  "expires_at": "2026-08-11T15:30:00Z"
}

If the proposal changes, approval no longer matches. Separation of duties also needs verified identities and role policy. Two sessions held by one person do not create two independent approvers.

The Universal Commerce Protocol keeps the business as Merchant of Record and normally requires checkout finalization through a trusted user interface unless the AP2 Mandates extension is supported. UCP Checkout shows that agent coordination can coexist with merchant responsibility and trusted approval surfaces.

Broker credentials after authorization

The model should never see a reusable treasury credential. After an allow decision, a credential broker can obtain a short-lived capability for the exact provider and operation. The agent receives an opaque operation handle or normalized result.

model prepares proposal
  -> gateway verifies identity and mandate
  -> policy authorizes exact proposal
  -> verified human approves when required
  -> broker obtains scoped payment capability
  -> adapter submits with stable idempotency key
  -> reconciler checks authoritative provider state
  -> evidence records decision and observed outcome

The payment adapter translates the canonical instruction into provider-specific parameters. It should not accumulate hidden finance policy. Persist the authorized transaction before making the external call and carry one business idempotency key through retries.

Stripe documents that it stores the first response for an idempotency key and rejects reuse when parameters differ. It also describes retention and retry behavior specific to its API. Stripe's idempotent request documentation is useful provider guidance, yet enterprise orchestration still needs a durable payment identity because the gateway and provider do not share one atomic database transaction.

Treat uncertain execution as a first-class state

If the gateway loses the provider response, the payment may have been accepted. Marking it failed and retrying with a new key can create a duplicate. Releasing the mandate and budget can authorize another live attempt.

PROPOSED -> VALIDATED -> AUTHORIZED -> RESERVED -> SUBMITTED
SUBMITTED -> ACCEPTED -> SETTLED
SUBMITTED -> REJECTED
SUBMITTED -> UNCERTAIN -> RECONCILED_SETTLED | RECONCILED_FAILED
ACCEPTED -> FAILED | RETURNED | REVERSED

Persist SUBMITTED immediately around dispatch according to the adapter's transaction pattern. On a timeout, keep the reservation, query the provider with the stable idempotency key or provider reference and prevent a new payment identity for the same invoice. A human may review the incident, while the provider remains authoritative for payment status.

No generic design can promise literal exactly-once execution across independent systems. The practical target is effectively-once orchestration: stable business identity, atomic local state, provider idempotency and reconciliation.

Cancellation is another transaction, not an edit to the original payment. A cancellation request needs its own authority, policy decision and idempotency key, and it may race with acceptance or settlement. If the provider has already accepted the payment, the next valid operation may be a return or reversal rather than cancellation. Model the provider's supported transitions explicitly and reject impossible local transitions. This prevents an operator-facing agent from reporting "cancelled" because it submitted a cancellation request even though the provider later returned too_late. Evidence should retain the request, provider response and reconciled financial state.

Record authorization and outcome evidence

An action receipt should bind the organization, agent, mandate, proposal digest, policy version, approval, reservation, provider reference, idempotency key, timestamps and observed execution status. If the response was lost, the status is uncertain.

A later reconciliation record can link settlement, failure, return or reversal. Do not mutate an earlier signed receipt. For a one-company deployment, the receipt is unilateral evidence. Its signature protects integrity and attributes the attestation to the verified key. It does not prove the bank settled funds or that an invoice represented a valid commercial obligation.

AP2 requires Payment Receipts after acceptance or rejection and describes verification of linked Checkout and Payment Mandates and receipts for disputes. The specification leaves retention and retrieval details outside its current scope. Enterprise payment systems must therefore operate evidence storage, key history, reconciliation and dispute export around the protocol objects.

Agentic payment failure matrix

Verify the design before live funds move

Build a payment simulator or provider test adapter that can accept, reject, delay and drop responses. Run at least these fixtures:

• amount exactly at, below and above the mandate limit;
• currency, supplier, purpose and destination substitution;
• expired and revoked mandate after approval but before dispatch;
• two concurrent submissions for one invoice;
• crash before reservation, after reservation and after provider acceptance;
• provider timeout followed by each possible authoritative result;
• key rotation during receipt verification;
• approval reuse against a changed proposal;
• redaction test for credentials and sensitive payment data.

For every run, verify the expected decision reason, durable state, provider calls, reservation, receipt and reconciliation record. A passing happy path says little about payment safety. The timeout and concurrency cases expose whether the design can prevent duplicates without losing legitimate work.

Current Intelliger and OATI boundary

OATI's public developer preview currently provides Passports, Mandates, transaction envelopes, deterministic Commerce evaluation, canonical signing, Receipts, middleware and conformance fixtures. The Commerce evaluator covers price, currency, per-transaction and cumulative budgets, usage consumption and signed context binding. Its local sandbox demonstrates a paid-API transaction.

This is not a completed production payment product. Agent Spend Control, hardened operated gateways, business approval workflows, a production payment connector, durable payment state, reconciliation and evidence operations remain target commercial capabilities. Independent cryptographic and protocol review is still open.

The wider Intelliger agentic-commerce blueprint includes model reasoning, outcome prediction and constrained optimization. Those components may propose and rank payment actions. They do not gain authority to cross a hard payment limit. Payment providers and enterprise finance systems continue to own execution and settlement.

Payments and security review note: qualified reviewers must assess payment-rail rules, provider contracts, fraud controls, safeguarding boundaries, privacy, separation of duties, cryptographic lifecycle and incident recovery for the actual deployment. This page was reviewed against the documented OATI developer-preview status on 11 August 2026. It is architecture guidance, not regulatory or payment-scheme certification.

Apply the controls to one payment flow

The agentic commerce hub places payments in the wider transaction architecture. Continue with accounts payable automation under uncertain execution and bounded autonomous negotiation. The AI agent audit-trail guide covers receipt verification in more depth, and the OATI Mandate documentation describes portable delegated authority.

Product and payment leaders evaluating one provider, rail and currency can discuss an Agent Trust design with Intelliger before connecting live credentials.