AI Agent Payment Authorization with Exact Approval
Authorize an AI agent payment by binding delegated authority and human approval to the canonical amount, currency, supplier, destination and invoice.
AI agent payment authorization should bind the agent's authority and any human approval to the exact payment request. The protected digest must include buyer entity, supplier, invoice, amount, currency, destination, purpose, provider context and idempotency key. A material change requires a new decision.
The full agentic payments design covers authority, execution and evidence. This implementation stays with one narrower problem: proving that the payment sent is the payment a person approved.
Canonicalize the proposal
type ExactPayment = {
transactionId: string;
buyerEntityId: string;
supplierId: string;
invoiceDigest: string;
amountMinor: number;
currency: string;
destinationId: string;
purposeCode: string;
providerProfile: string;
idempotencyKey: string;
};
Resolve identifiers from governed systems, validate integer minor units and reject unexpected fields. Canonicalize with a documented profile before hashing. RFC 8785 supplies one JSON canonicalization scheme.
Evaluate authority before approval
The policy checks active agent status, mandate action, supplier and destination allowlists, amount and currency limits, invoice state, segregation of duties, expiry and remaining usage. A model fraud score may increase review. It cannot turn a failed hard rule into allow.
request digest A -> policy says approval_required -> approver accepts A
request digest B -> execution adapter compares B with A -> deny
Test changes to amount, currency, destination, invoice digest, buyer entity and execution date. Test a copied approval across tenants and a revoked approver role.
Keep approval and outcome separate
Approval permits an attempt. Provider acceptance and settlement are later states. If the adapter times out, preserve the original approval and idempotency key while reconciling the provider result. Do not issue a second approval for what may be the same payment.
Design the approval experience
Show the approver the fields that policy treats as material. Present verified supplier and destination records beside the invoice source, not only a model-written summary. Mark a new destination, missing purchase order or threshold exception directly. The UI should make a safe decision possible without asking the reviewer to inspect raw JSON.
Record the identity assurance used for approval and prevent the payment-preparing agent from controlling the approver session. Segregation of duties should be an enforced identity rule, not an instruction in the prompt.
Approval expiry should reflect the volatility of underlying facts. A supplier destination or exchange rate can change while an old approval remains technically valid. Revalidate current state immediately before dispatch and require a new approval when a protected fact changed.
When a reviewer rejects a payment, preserve the rejected request digest and reason. A subsequent edited proposal should have a new digest and an explicit link to the earlier one, which makes repeated threshold probing visible.
AP2's specification uses signed mandates to bind parts of agentic commerce and payment flows. An enterprise must still connect those objects to its own authority, supplier, approval and accounting records.
Use how to bind human approval for UI and time-of-check details, and payment idempotency for concurrency. The Intelliger agentic commerce platform describes the live product context.
This design requires independent payments, fraud, security and legal review. OATI remains a developer preview and does not certify the correctness of a customer's approval matrix or payment integration.
Payment-approval questions
Is an invoice approval the same as payment approval?
Not always. Invoice approval may confirm goods, account coding and amount. Payment approval may also depend on buyer entity, execution date, rail and current destination. If the first approval is reused, prove that its protected object includes every material payment field and remains valid. Otherwise request a payment-specific decision.
How is segregation of duties enforced?
Use verified identities and role rules outside the model. Prevent the person or service that changed supplier destination from approving the first payment to it where policy requires independence. Record represented and acting identities. Do not rely on an agent prompt to choose a different approver.
Can policy auto-approve low values?
Yes, under a documented grant and cumulative controls. Check counterparty, destination, invoice state, currency, amount, use and period budgets. Reserve usage atomically. A low individual amount can still be risky when split across many transactions or sent to a new destination.
What should the approver authenticate?
Use an assurance level appropriate to value and risk, and record the authentication context. Bind the session to the approval request and prevent cross-tenant reuse. A signature or strong session proves the approver action under its trust assumptions; the UI must still show the exact protected facts.
Can approval survive a provider change?
Only if provider identity and routing are outside the protected meaning by explicit policy. Provider profile can affect fees, destination resolution and safeguarding. For material payments, include it or an approved provider class in the digest and reapprove when the change alters risk.
How is an approval sampled later?
Start from the provider transaction, reconstruct the canonical submitted request and compare its digest with approval and policy records. Verify approver role at decision time and inspect later supplier or destination changes. Sampling only the approval database misses bypassed payments.
Include a cancellation rule. An approver may withdraw consent after approval but before dispatch, or finance may discover a supplier issue while a request is queued. Model approval as a lifecycle record with revocation or supersession, not an immutable green light that remains executable until expiry. The final adapter check should resolve the current approval state and bind it to the same digest. Test withdrawal during a worker retry and confirm the payment adapter receives no new submission.
Store what the reviewer saw, not only the signed digest. The presentation record should identify the labels, source references and warnings shown at decision time without copying unnecessary payment data. During an investigation, this lets the team distinguish a cryptographically correct approval of a misleading screen from a later request substitution.
Review localization and number formatting. A decimal separator, currency symbol or truncated destination label can change what a person believes they approved even when the canonical object is correct. Test the real reviewer locale and assistive technology before relying on the screen for material payments.