AP2 Payment Mandates vs Enterprise Agent Authority

Reviewed 11 August 2026 · 14 minute read

AP2 Payment Mandates authorize payment for a particular checkout and can constrain payee, payment instrument, amount, budget and execution date. Enterprise agent authority answers a wider set of questions: which organization owns the agent, why it is acting, which tools and data it may use, whether it may delegate, which internal approvals apply, and what non-payment action evidence must be retained. They are complementary layers, not competing replacements.

This article is for payment architects and agent-platform engineers integrating AP2 into enterprise workflows. The outcome is a composition model that preserves AP2's payment semantics while avoiding the claim that a payment mandate authorizes every action leading to a purchase.

For the broader control pattern, read the agentic payments architecture guide and identity versus authority for agentic systems.

What AP2 payment mandates authorize

AP2 v0.2 defines a Checkout Mandate and a linked Payment Mandate. The Checkout Mandate gives the merchant cryptographic evidence that the shopping agent is authorized to purchase the assembled checkout. The Payment Mandate gives payment roles evidence that the agent is authorized to pay for that checkout. AP2 requires role-specific validation and processing to happen in deterministic code. The official AP2 specification is the authority for these protocol claims.

The closed Payment Mandate includes a transaction identifier bound to the checkout, payee, payment amount, payment instrument and optional execution date. Open mandates can carry constraints including allowed payees, allowed instruments, allowed payment initiation service providers, amount range, recurring budget and execution window. AP2 Payment Mandate documents those fields and constraints.

AP2 also distinguishes human-present and autonomous flows. In the autonomous mode, open mandates express constraints, and the agent binds a closed mandate to a transaction that satisfies them.

This is substantial authority. It is also payment-specific by design.

What enterprise authority adds

Consider a procurement agent that discovers a supplier, reads contract pricing, negotiates delivery, creates a purchase order and then pays.

Payment authorization does not necessarily answer:

• whether the agent may read the confidential catalog
• whether the supplier is approved by procurement
• whether the purchase supports an authorized business purpose
• whether the agent may negotiate contract terms
• whether a child agent may inherit the authority
• whether data may be sent to this counterparty
• whether the inventory reservation or purchase order was authorized
• which internal policy and approver allowed the action
• how to revoke the agent's non-payment access immediately

Those are enterprise transaction controls. They may be enforced through IAM, policy engines, gateways, workflow approvals and an OATI-style mandate. AP2 does not need to duplicate all of them to be useful.

Compare the policy objects directly

AP2's Agent Authorization Framework says the mandate model may apply more generally in the future, while AP2 uses it for payments. It also states that agent-to-agent delegation is outside the current specification. AP2 Agent Authorization supports a precise conclusion: enterprise platforms can compose with AP2 without claiming AP2 already specifies every enterprise control.

Compose the layers around one transaction

enterprise intent and policy
  -> enterprise agent mandate
  -> supplier discovery and checkout creation
  -> merchant-signed checkout
  -> AP2 Checkout Mandate
  -> AP2 Payment Mandate
  -> credential and payment processing
  -> AP2 Checkout and Payment Receipts
  -> enterprise Action Receipt and reconciliation

The enterprise mandate should not copy the AP2 Payment Mandate byte for byte. Bind the objects through stable references and digests.

type EnterprisePaymentContext = {
  enterpriseTransactionId: string;
  agentId: string;
  organisationId: string;
  mandateId: string;
  purpose: 'approved_supplier_invoice' | 'approved_procurement';
  supplierId: string;
  ap2MerchantId: string;
  invoiceId?: string;
  checkoutDigest: `sha256:${string}`;
  ap2PaymentTransactionId: string;
  maximumAmount: { currency: string; valueMinor: bigint };
  policyDigest: `sha256:${string}`;
  approvalId?: string;
};

This is illustrative application code, not an AP2 schema. Keep AP2 wire objects conformant to their versioned vct values.

Bind before approving

An enterprise approval such as "approve office equipment" is too loose. Bind it to the supplier, items, quantity, total, currency, payment destination and checkout digest. If the merchant changes the checkout, create a new authorization decision.

function verifyComposition(
  enterprise: EnterprisePaymentContext,
  ap2: ClosedPaymentMandate,
  checkout: MerchantSignedCheckout,
): ReasonCode[] {
  const reasons: ReasonCode[] = [];
  if (sha256(checkout.jwt) !== enterprise.checkoutDigest)
    reasons.push('ENTERPRISE_CHECKOUT_DIGEST_MISMATCH');
  if (ap2.transaction_id !== hashCheckout(checkout.jwt))
    reasons.push('AP2_CHECKOUT_BINDING_MISMATCH');
  if (ap2.payee.id !== enterprise.ap2MerchantId)
    reasons.push('SUPPLIER_PAYEE_MISMATCH');
  if (!withinLimit(ap2.payment_amount, enterprise.maximumAmount))
    reasons.push('ENTERPRISE_AMOUNT_EXCEEDED');
  return reasons.sort();
}

Real mappings need an authoritative supplier identifier. Comparing a display name is unsafe. Use verified legal-entity, merchant-domain or registry mappings appropriate to the deployment.

Keep payment credentials outside the model

The shopping agent may assemble mandate content, but the trusted surface, credential provider and payment roles perform defined signing and verification work. Do not put raw payment credentials or reusable provider secrets in model context.

An enterprise gateway can pass the AP2 objects to a conformant payment adapter after its own policy allows the operation. The adapter should return opaque references and receipts, not sensitive credential material.

The model can explain a rejection such as amount exceeded or unresolved constraint. Deterministic verifiers decide it.

Receipts overlap without being identical

AP2 requires Checkout and Payment receipts after acceptance or rejection and describes bringing mandates and receipts together for dispute evidence. It leaves retention and retrieval operations outside the current specification.

An enterprise action receipt may need to include internal purpose, policy digest, approval, invoice, purchase-order reference and non-payment tool history. Link it to the AP2 receipt digest and transaction ID rather than claiming it replaces the AP2 receipt.

{
  "enterprise_transaction_id": "oati:tx:purchase-8841",
  "decision": "allow",
  "mandate_id": "oati:mandate:invoice-8841",
  "policy_digest": "sha256:...",
  "checkout_digest": "sha256:...",
  "ap2_payment_transaction_id": "base64url-hash...",
  "ap2_payment_receipt_digest": "sha256:...",
  "provider_reference": "pay_7319",
  "outcome": "pending"
}

This is a conceptual application record, not a verbatim OATI Action Receipt.

Neither receipt proves that an invoice was legitimate or goods arrived. It proves what the issuer recorded and signed. Order and payment systems remain authoritative for changing outcome state.

Revocation and consumption need coordinated state

An open Payment Mandate with a budget needs accumulated usage. An enterprise mandate may have its own cumulative budget, call count or one-time use. Both evaluators must reserve their state atomically enough to prevent concurrent overspend.

There is no cross-system atomic transaction between every enterprise ledger and payment participant. Use stable idempotency, compare-and-set consumption and reconciliation.

RECEIVED -> ENTERPRISE_AUTHORIZED -> AP2_VERIFIED -> SUBMITTED
   -> ACCEPTED | REJECTED | UNKNOWN
   -> SETTLED | FAILED | REVERSED

If submission becomes unknown, do not release both budgets and retry with a new transaction. Query by the original AP2 and provider references first.

Revocation checks are also layered. The enterprise can revoke an agent or mandate before execution even if an AP2 object remains cryptographically valid. Conversely, a valid enterprise mandate cannot rescue an expired or invalid AP2 Payment Mandate.

Failure cases and recovery

AP2 defines unresolved_constraint for a verifier that cannot evaluate a constraint. Do not ignore unknown constraints and continue. A non-agentic fallback or new directly approved mandate is safer.

Reproducible composition test

Create one merchant-signed checkout, one enterprise authority fixture and one AP2 Payment Mandate. Record exact expected digests. Then mutate one field at a time:

1. Increase payment amount by one minor unit above the enterprise ceiling.
2. Replace the payee while keeping the same enterprise supplier reference.
3. Change the checkout JWT after approval.
4. Expire the enterprise mandate but keep AP2 valid.
5. Expire AP2 while keeping the enterprise mandate valid.
6. Submit the same transaction twice concurrently.
7. Remove the AP2 receipt from the evidence package.

The verifier should return deterministic, sorted reason codes and make zero provider calls for rejected fixtures. The concurrent valid fixture should produce one provider operation and a recoverable prior result for the retry.

Current Intelliger and OATI boundary

OATI and AP2 are separate standards. OATI's current developer preview implements general Passport, Mandate, Transaction Envelope, deterministic evaluation and Action Receipt objects, including Commerce price and budget constraints. It does not claim native AP2 v0.2 conformance or a production AP2 payment connector.

Intelliger's current commercial MVP direction is Agent Spend Control through one existing payment provider, rail and currency. Intelliger does not hold funds and does not claim to be a bank, custodian or treasury platform. The provider connector, durable payment ledger, reconciliation and audit-package workflow remain MVP or incomplete production work.

The implemented OATI framework has not completed independent cryptographic and protocol review, the full two-enterprise production acceptance exercise or durable dispute workflows. Those boundaries apply even when the schemas and local conformance suite pass.

Read accounts payable automation without duplicate payments for the state-machine detail and explore the current OATI open-standard pages for implemented developer capabilities.

Implementation checklist

• Treat AP2 as payment authorization, not universal enterprise policy.
• Preserve exact AP2 schemas, versions and verification rules.
• Bind enterprise approval to the merchant-signed checkout digest.
• Map supplier identity to AP2 payee through an authoritative registry.
• Evaluate enterprise and AP2 constraints deterministically.
• Keep payment credentials and reusable secrets outside model context.
• Track enterprise and AP2 budget consumption under concurrency.
• Carry stable transaction and provider references through retries.
• Link AP2 receipts rather than replacing them with internal logs.
• Recheck revocation and expiry at the final execution boundary.
• Reconcile unknown, settled, failed and reversed outcomes separately.
• Test each layer valid while the other is invalid.

Expert review required before publication: an AP2 protocol reviewer, payments architect and security reviewer should verify mandate-version details, checkout binding, selective-disclosure handling, budget consumption and all dispute-evidence language.

Use the agentic payments control architecture to map enterprise decision points before implementing the AP2 adapter.