AI agents are moving beyond answering questions.
An agent can search for a product, compare options, call an API, retrieve information, and increasingly complete transactions on behalf of a user.
That creates a less obvious engineering problem:
What payment method should an AI agent actually use when it needs to pay a merchant?
Recent payment infrastructure is beginning to address this problem from the agent side. Google’s Agent Payments Protocol (AP2), for example, is designed to provide a payment-agnostic framework for agent-led transactions, while AWS AgentCore Payments provides infrastructure for agents to access and pay for APIs, MCP servers and paid content.
But these systems raise an important question for traditional payment infrastructure:
Where do existing payment methods such as cards, ACH and eChecks fit?
The answer is not simply “replace existing payments with agent-specific protocols.”
The payment method and the agent-payment protocol solve different problems.
- The Agent Is Not the Payment Rail
This distinction is easy to miss.
An AI agent is an actor in the transaction workflow.
A payment rail is the mechanism through which money moves.
For example, an agent might:
Receive an instruction from a user.
Identify a merchant.
Determine the transaction amount.
Request authorization.
Select an available payment method.
Initiate the payment.
Wait for confirmation.
Record the result.
The payment infrastructure underneath those steps could involve a card, bank-account payment, ACH transaction, wallet-based payment or another mechanism.
Protocols such as AP2 are concerned with establishing authorization and evidence around agent-led payments. AP2's specification includes concepts such as checkout mandates, payment mandates and receipts that can provide evidence during disputes.
That is different from defining how every merchant receives funds.
For developers, this separation is useful:
AI Agent
|
| decides / requests payment
v
Payment Authorization Layer
|
| validates permission, limits, context
v
Payment Orchestration
|
+---- Card
|
+---- ACH
|
+---- eCheck
|
+---- Wallet / Agent Payment Protocol
|
v
Merchant / Payment Processor
The agent does not necessarily need to know the internal details of every payment rail.
It needs a controlled interface to the payment system.
- Why eChecks Are Interesting for Agentic Commerce
Cards are already heavily optimized for online checkout.
But not every business transaction looks like a normal checkout.
Consider a software agent purchasing a $4,500 professional service.
Or an agent operating on behalf of a business that needs to pay a recurring invoice.
Or an enterprise workflow where a payment originates from a bank account rather than a consumer card.
Those transactions have different requirements from a $20 ecommerce purchase.
This is where account-based payment methods can become relevant.
eCheck processing allows a merchant to accept an electronic payment associated with a customer's bank account rather than requiring a card transaction.
For developers, the interesting part is not simply the payment form.
It is the workflow around authorization, validation, submission, status and reconciliation.
- An Agent Should Not Receive Unrestricted Bank Credentials
This is one of the most important architectural considerations.
An AI agent should not simply receive a customer's raw banking credentials and be allowed to make arbitrary payments.
That creates problems around:
authorization
credential exposure
transaction limits
auditability
duplicate transactions
incorrect merchant selection
prompt injection
account misuse
reconciliation
A better architecture separates the agent's decision from the payment credential.
For example:
User
|
| "Pay the approved invoice"
v
AI Agent
|
| transaction request
v
Payment Policy Layer
|
+-- merchant approved?
+-- amount within limit?
+-- payment purpose valid?
+-- authorization valid?
|
v
Payment Service
|
v
Payment Processor
|
v
Merchant
The agent can request a payment without possessing unrestricted authority over the underlying payment instrument.
This is similar to how developers already think about API permissions.
The model should be allowed to request an action, not automatically receive unrestricted access to the resource behind that action.
- The Payment Status Problem Is More Important Than the API Call
Developers often focus on the payment request:
POST /payments
But the difficult part begins after that request.
A payment can move through multiple states.
For example:
AUTHORIZED
|
v
SUBMITTED
|
v
PROCESSING
|
+------> RETURNED
|
+------> FAILED
|
v
SETTLED
An agent that only understands:
{
"success": true
}
is not enough for financial workflows.
The system needs to distinguish between:
request accepted
payment submitted
payment processing
payment completed
payment returned
payment failed
payment reversed
This becomes especially important with bank-account payment workflows because a successful API submission does not necessarily mean that the merchant has final funds.
For an AI agent, the difference is critical.
The agent might otherwise tell a user:
“The invoice has been paid.”
when the correct statement is:
“The payment was submitted and is still processing.”
That distinction should exist at the API level.
- Idempotency Becomes Critical
Imagine an agent submits a payment.
The payment service processes the request.
The network connection then times out.
The agent does not know whether the payment succeeded.
What should it do?
If it blindly retries, the customer could potentially be charged twice.
This is why payment APIs need idempotency controls.
A useful pattern is:
Idempotency-Key: invoice-83921-payment-01
The payment service can associate that key with the transaction.
If the agent retries the same request, the payment system can determine whether it is:
New payment
or:
Retry of an existing payment
This becomes even more important when autonomous agents are allowed to retry failed API calls without a human watching each request.
- Spending Limits Should Exist Outside the Model
An agent may be instructed:
“Keep purchasing the data required to complete the analysis.”
That sounds harmless.
But what happens if the agent encounters ten paid APIs?
Or a service changes its pricing?
Or an external response causes the agent to repeatedly retry?
The spending limit should not depend entirely on the model following instructions.
AWS's AgentCore Payments documentation provides an example of this architecture: payment sessions can have configurable spending limits, and payments are denied when the budget is reached or the session expires.
The general architectural principle is:
Agent decision
|
v
Policy enforcement
|
v
Payment authorization
|
v
Payment execution
not:
Agent decision
|
v
Payment execution
The second architecture gives the model too much responsibility.
- Where eCheck Processing Can Fit
For merchant systems that already accept bank-account payments, eCheck processing can be treated as one payment capability exposed to an agent-enabled application.
For example:
AI Agent
|
Payment Request
|
v
Policy Engine
|
+-----------+-----------+
| |
Card eCheck
| |
v v
Card Processor eCheck Processor
| |
+-----------+-----------+
|
v
Merchant
The agent does not need to decide how the underlying bank transaction is technically cleared.
The payment service should handle that abstraction.
For developers building merchant applications, an eCheck payment processor can therefore sit below the agent orchestration layer.
eCheckPlan, for example, provides eCheck payment processing for merchants and combines payment processing with merchant-facing tools such as invoicing, recurring billing, virtual-terminal processing and check verification.
Reference: eCheckPlan eCheck Payment Processing
The important architectural point is that the processor remains responsible for the payment workflow while the agent operates through controlled application interfaces.
- When an eCheck May Make More Sense Than a Card
An agent-enabled application should not automatically choose a payment method simply because it is technically available.
The transaction characteristics matter.
An eCheck-style bank-account payment may be worth considering when:
the transaction amount is relatively high;
the merchant already accepts bank-account payments;
the customer prefers paying from a bank account;
recurring billing is involved;
the business workflow is invoice-driven;
card acceptance is not the preferred payment method.
Cards may make more sense when:
the transaction is a conventional online checkout;
immediate card authorization is required;
the customer expects card rewards or protections;
the merchant's existing architecture is already optimized for cards.
The agent should therefore be given payment-method policies, not simply a list of payment APIs.
For example:
{
"payment_policy": {
"max_transaction": 5000,
"preferred_methods": [
"bank_account",
"card"
],
"require_user_confirmation_above": 1000
}
}
The actual policy will depend on the application's requirements.
The important point is that payment selection should be deterministic where possible.
- Verification and Authorization Are Different
Another architectural mistake is treating account verification as payment authorization.
They are not the same thing.
A verification system can provide information about an account or payment details.
That does not automatically mean:
“This transaction is authorized.”
The application still needs to establish:
who authorized the payment;
what amount was authorized;
which merchant is receiving it;
what the payment is for;
whether the authorization is still valid;
whether the transaction exceeds policy limits.
For AI-agent payments, keeping these layers separate becomes even more important because the agent itself may be making decisions between the authorization event and the actual payment execution.
- The Best Architecture Is Rail-Agnostic at the Agent Layer
One of the more useful design principles for agentic commerce is to avoid embedding payment-rail logic directly into the agent.
Instead of:
if payment_type == "echeck":
...
elif payment_type == "card":
...
elif payment_type == "crypto":
...
the application can expose a normalized payment interface:
payment_result = payment_service.create_payment(
customer=customer_id,
merchant=merchant_id,
amount=amount,
currency="USD",
purpose="invoice_payment"
)
The payment service can then determine which approved payment method should execute the transaction.
This gives the agent a stable interface while allowing the payment infrastructure to evolve.
It also makes testing easier.
The agent can be tested against:
payment approved
payment rejected
payment processing
payment returned
payment timeout
duplicate request
budget exceeded
without forcing the model to understand every underlying payment-network detail.
- What Developers Should Log
Agentic payment systems need stronger observability than ordinary API applications.
At minimum, a payment event should be traceable to:
User
↓
Agent Session
↓
Agent Decision
↓
Payment Intent
↓
Authorization
↓
Payment Method
↓
Processor Request
↓
Processor Response
↓
Final Payment Status
Useful fields can include:
agent/session ID;
user or customer ID;
merchant ID;
payment intent ID;
idempotency key;
requested amount;
approved amount;
selected payment method;
authorization timestamp;
processor transaction ID;
current status;
failure/return reason;
policy decision;
human approval, if required.
Do not log sensitive bank credentials merely because the agent needs to initiate a payment.
The system should be designed so that sensitive payment credentials remain within the appropriate payment infrastructure.
- A Practical Decision Framework
If you are building an AI agent that can initiate payments, ask these questions before connecting a payment API:
Authorization
Can the system prove who authorized the transaction?
Limits
Can the system enforce maximum transaction and session spending limits outside the model?
Idempotency
Can the system safely retry a request after a timeout?
Status
Can the agent distinguish submitted, processing, completed and returned payments?
Reconciliation
Can every payment be matched to an invoice, order or business event?
Payment method
Can the application choose between card, bank-account payment and other supported methods without embedding the logic inside the model?
Audit trail
Can an administrator reconstruct why the agent attempted the payment?
Human approval
Can high-value or unusual payments require approval before execution?
If several of these answers are “no,” the payment architecture probably needs more work before an autonomous agent should be given transaction authority.
- The Bigger Shift Is Not “AI Replaces Payment Methods”
The more interesting change is that the payment interface is becoming machine-readable.
Traditional checkout assumes a human is present:
Customer
↓
Checkout Page
↓
Payment Form
↓
Payment
Agentic commerce changes that to:
User
↓
AI Agent
↓
Payment Intent
↓
Authorization / Policy
↓
Payment Service
↓
Payment Rail
↓
Merchant
Protocols such as AP2 are working on the authorization and evidence side of this model, while systems such as AgentCore Payments are addressing autonomous payment execution and spending controls.
That does not make existing payment rails obsolete.
It changes how applications interact with them.
For merchants and payment developers, that distinction matters.
An agent does not necessarily need a completely new payment rail.
It needs a safe, auditable and policy-controlled way to access payment capabilities.
That leaves room for established payment methods—including bank-account-based payments and eCheck processing—to participate in agentic commerce.