Published by Dogpay ·
Agent payment controls
What Authorizations, Spending Limits, and Transaction Records Does an AI Agent Need Before Making Payments?
The Short Answer
An AI Agent that can execute tasks does not automatically have unlimited payment authority.
When an Agent acts on behalf of a user to initiate a payment, three layers of control are required:
Identity & task authorization — who is acting, and what they are allowed to do
Payment controls — amount, payee, and conditions
Transaction records — result confirmation, failure handling, and reconciliation
Missing any one of these layers can lead to financial risk or compliance issues. This article explains the control requirements that merchants and developers need to understand before integrating.
A Hypothetical Merchant Scenario
Scenario: A user tells their Agent, "Book me a flight from Shenzhen to Singapore, budget under 3,000 CNY."
1. Task Authorization
The user approves the task within the Agent application, setting the objective ("book a flight") and the spending cap (3,000 CNY). The Agent receives a time-limited authorization credential.
2. Agent Execution
The Agent searches for flights, compares prices, and selects an option that meets the criteria.
3. Payment Request
The Agent sends a payment request to the merchant (the airline), carrying:
The user's authorization credential (proving "I am authorized to pay on their behalf")
The transaction amount (within the 3,000 CNY limit)
An idempotency key (to prevent duplicate charges)
4. Payment Control Checks
The merchant or payment platform verifies:
Is the amount within the 3,000 CNY cap? ✅
Is the payee a trusted merchant? ✅
Does this require user re-confirmation? (Assume amounts over 500 CNY need confirmation) → Prompt the user
5. User Confirmation
The user approves with a single tap on their phone.
6. Payment Completed
The Agent receives a payment success callback and confirms the order to the user.
7. Record Retention
The transaction is recorded in the user's billing history, and the merchant receives a reconciliation file.
The Three Layers of Control in Detail
Layer 1: Identity & Task Authorization
Core question: Who is the Agent? Who does it represent? What can it do?
Element | Description |
|---|---|
Agent identity | A verifiable identifier (e.g., OAuth client_id, DID) |
User authorization | The user explicitly approves the Agent to act on their behalf, similar to OAuth scopes |
Task scope | Authorization should be limited to a specific task ("book a flight," not "spend freely") |
Time-bounded | Authorization should have an expiry and become invalid once the task is complete |
In industry practice, OAuth 2.0 + PKCE handles user authorization, and JWTs carry Agent identity and permission claims. Emerging protocols like Poppy are working to standardize Agent discovery and permission frameworks.
Layer 2: Payment Controls
Core question: How much can be spent? On what? Under what conditions is re-confirmation required?
Control dimension | Typical implementation |
|---|---|
Per-transaction limit | Require user re-confirmation above a threshold |
Cumulative limit | Daily, weekly, or monthly spending caps |
Payee whitelist | Only allow payments to verified merchants |
Category restriction | Limit spending to specific categories (e.g., "flights only") |
Time window | Authorization valid only during a specific period |
Key design principles:
Default deny: Any action not explicitly authorized is rejected
Progressive trust: New users start with low limits, gradually increased based on usage history
Real-time risk control: Anomalous transactions trigger additional verification
Layer 3: Transaction Records
Core question: How are payment results confirmed? How are failures handled? How is reconciliation done?
Requirement | Implementation |
|---|---|
Idempotency | The same request submitted multiple times produces only one transaction |
Callback notifications | Payment success or failure is reported to the Agent in real time |
Failure retry | A clear retry strategy prevents duplicate charges |
Transaction query | Both the Agent and the user can look up transaction history |
Reconciliation files | Merchants can download reconciliation data to cross-check with internal systems |
Audit trail | A complete record of authorization, payment, and revocation events |
Integration Readiness Checklist
Before integrating, merchants and Agent developers should prepare:
Agent identity scheme: How will the Agent be identified? (OAuth client, DID, custom ID)
Authorization flow: How does the user approve the Agent to make payments?
Spending limits: How are per-transaction and cumulative limits set? Who can adjust them?
Callback endpoint: Where should payment result notifications be sent?
Reconciliation method: How will transactions be reconciled with the payment platform?
Dispute process: How can the authorization trail be traced when a user raises a dispute?
The Protocol Landscape: Poppy, AP2, and Visa TAP
Several protocols are attempting to standardize how Agents interact with merchants:
Poppy (Personal Agent Protocol)
A draft framework released by Sierra and Meta in October 2026. Official definition:
"Personal Agent Protocol, or Poppy, is a draft framework for personal agents to interact with businesses. It connects agent discovery, customer permissions and business interfaces."
Key distinctions:
Poppy defines the Agent discovery and permission framework
Payments are described as an "extension area" — Poppy itself is not a settlement network
Merchants still need a payment gateway to process actual fund flows
Further reading: Dogpay News — Poppy Protocol Explainer
AP2 (Agent Protocol)
An Agent-to-Agent communication protocol focused on task coordination. It does not handle payments directly.
Visa Trusted Agent Protocol
A card network approach to Agent onboarding, leveraging existing card payment infrastructure.
How they relate: Poppy and AP2 define the identity and permission layer; Visa TAP connects to existing payment rails. Merchants may need to support multiple protocols or unify them through an intermediary layer.
Dogpay's Agent Payment Capabilities
Dogpay positions itself as a Web3 payment and business finance infrastructure for individuals, merchants, enterprises, and AI Agents. The following capabilities are relevant to Agent payment controls:
Team & spending controls: The Approval Center supports multi-user and team-based permission delegation with multi-tier card spending limits. Combined with the Budget API — which supports creating, updating, freezing, and querying budgets — merchants can implement granular spending controls.
Transaction records & callbacks: A comprehensive Webhook system covers order transactions, card transactions, VA transactions, and crypto wallet transactions with real-time callback notifications. The Card Account Transaction List and Crypto Transaction List APIs provide transaction query and reconciliation capabilities.
Modular API integration: Through three API suites — CaaS (Card as a Service), BaaS (Bank as a Service), and PaaS/WaaS (Payment as a Service / Wallet as a Service) — merchants can compose card, account, and acquiring capabilities as needed. The integration process follows four stages: Sandbox → Pilot → Launch → Scale.
Compliance foundation: Dogpay holds a Canada FINTRAC MSB license, US FinCEN MSB registration, a Hong Kong TCSP license, Visa Third-Party Agent status, and PCI-DSS Level 1 certification. It supports USDT, USDC, BTC, ETH, SOL, and DOGE across multiple chains, with real-time conversion and disbursement in 38 fiat currencies.
For technical details, see the Dogpay API Documentation.
FAQ
Q1: Is Agent identity verification the same as payment authorization?
No. Agent identity verification (proving "who I am") and payment authorization (proving "I can make this payment") are two separate steps. An Agent may have passed identity verification, but each payment still needs to check the user's authorization scope, spending limits, and merchant rules.
Q2: Which payments require user re-confirmation?
This depends on the agreement between the merchant and the user. Common rules include:
Amounts exceeding a per-transaction threshold (e.g., 500 CNY)
First-time payments to a new payee
Each execution of a recurring subscription charge
A "confirm every transaction" mode that the user has explicitly enabled
Q3: How do you prevent retries from causing duplicate payments?
Use an idempotency key. Each payment request carries a unique identifier, and the payment platform guarantees that requests with the same identifier produce only one transaction. Even if a network timeout triggers a retry, no duplicate charge occurs.
Q4: How do you limit an Agent's spending?
A combination of controls:
Per-transaction limit: Maximum amount per payment
Cumulative limit: Daily, weekly, or monthly spending cap
Payee whitelist: Only allow payments to specified merchants
Category tags: Restrict spending to specific categories (e.g., "transport only")
Time window: Authorization valid only during a specific period
Q5: What information do I need before integrating?
See the "Integration Readiness Checklist" above. The essentials are: an Agent identity scheme, an authorization flow, a spending limit strategy, and a callback endpoint. We recommend starting with a conversation with the payment platform's product team to confirm the scope of technical support.