How AI Agents Actually Initiate a Payment: A Lifecycle Guide

When someone says "an AI agent made a payment," that phrase is doing a lot of work for one sentence — and it holds whether the payment in question is a consumer checkout, a vendor invoice, an FX conversion, or a treasury transfer between accounts. In practice, it's shorthand for at least five separate steps, handled by different systems and often different vendors. For anyone evaluating a vendor, comparing protocols, or scoping an internal build, knowing those steps individually is what turns "is this safe?" into something more useful: a specific question about a specific stage.

That's the goal of this post: break the lifecycle down into its real parts, and give you a way to use that breakdown when you're the one deciding whether a given setup is ready to trust with real spend.

The Five Stages of an Agentic Transaction

1. Intent

It starts with a mandate. Rather than approving a single, specific charge, a person or business authorizes an agent around an intent — "book a flight to New York under $800 this week," "reorder this SKU whenever inventory drops below 200 units," or "settle intercompany balances with our EU subsidiary every Friday, up to $2M." The boundary gets set once, upfront, instead of approved transaction by transaction, whether the agent sits in front of a shopping cart or a treasury workstation.

2. Proposal

The agent turns that intent into something specific. For a consumer commerce agent, that might be which flight, which vendor, at what price. The same stage is just as real, and often more consequential, outside of commerce entirely: a treasury agent turning a mandate to settle intercompany balances into an actual payment route, amount, counterparty, and receiving financial institution; a payables agent turning "pay approved vendor invoices under $25,000" into a specific remittance with the FX or stablecoin conversion rate, receiving bank, and the remittance or addendum information a counterparty needs to apply the payment correctly.

Getting from a mandate to that level of detail isn't one step — it's a workflow the agent runs every time: collecting the information required (invoice or purchase-order data, account and routing details, the applicable rate), reconciling it against what's already on file or already committed elsewhere, applying the automation rules the mandate allows, correcting whatever doesn't reconcile, and deciding among the valid options, until every field the eventual transaction message needs — route, amount, counterparties, rate, financial institutions, remittance or addendum data — is determined and confirmed. In protocols like Google's AP2, the output of that process shows up literally as a signed "Cart Mandate" sitting alongside the original "Intent Mandate." Outside of commerce there's rarely a cart, but the underlying discipline is the same: nothing moves to authorization until the proposal is complete.

3. Authorization and Control

Before anything is charged, the proposal has to clear a check: is this agent allowed to do this, for this amount, with this counterparty, right now? Card networks have rolled out early attempts at this — tokenized card credentials bound to a specific agent, merchant, and consent policy, with an agent's identity and standing verified before a transaction proceeds. These efforts are still rolling out and, so far, tied mainly to card rails, one of several reasons this stage remains the least standardized part of the lifecycle, and the one worth the most scrutiny in any deployment today, commerce-related or not.

4. Execution and Settlement

Once authorized, the instruction executes through whatever rail applies — a card network, an instant payment rail, ACH, wire, or a stablecoin settlement rail. Newer protocols like AP2 are deliberately settlement-agnostic, so the same authorized instruction can clear over more than one type of rail depending on speed, cost, or fit — the same flexibility a treasury team already expects when it chooses how to move money between institutions.

5. Reconciliation

The transaction gets recorded with enough detail to trace it back to the agent, the mandate that authorized it, and the intent it fulfilled. Card networks are already storing token data alongside the originating mandate specifically to support dispute and chargeback resolution later, and the same principle holds for a treasury or payables agent: without a record that ties the payment back to its authorization basis, everything upstream is much harder to prove after the fact.

What to Ask at Each Stage

This is the part worth bringing into an actual vendor conversation or internal design review. For each stage, there's one question that tells you whether it's genuinely built out or just assumed:

• Intent: Who defines the boundaries of the mandate, and how granular can they be? A mandate that's too broad defeats the purpose; one that's too narrow forces constant re-approval.
• Proposal: Can we see the specific proposal the agent generated before it's acted on, or only after? Visibility here is what lets a team catch a bad decision before it costs money, not after.
• Authorization: Is there a mechanism to prove the agent was allowed to do this, or does the system just trust that it was? This is the stage most worth scrutinizing, because it's the newest and least standardized part of the stack.
• Settlement: Which rails does this actually support, and does that match what our business needs? Card-only, bank-only, and multi-rail systems have very different implications for cost and speed.
• Reconciliation: If a transaction gets disputed six months from now, can we reconstruct exactly why the agent made that decision? If the answer is "not easily," that's a gap worth closing before volume scales up.

Where the Real Gaps Usually Are Today

Stages 1, 2, and 4 are largely solved problems already. Intent capture and proposal generation are a product and commerce question for consumer-facing agents, and a treasury, ERP, or workflow question for corporate ones — either way, they build on tooling that already exists. Settlement runs on payment rail infrastructure that's been maturing for decades, regardless of who or what initiated the instruction.

Authorization and reconciliation — stages 3 and 5 — are newer and far less standardized, which is exactly where most of the current infrastructure investment, and most of the risk in an early deployment, is concentrated. Clarc is infrastructure purpose-built for that gap: the pre-transaction authorization check and the resulting audit record, independent of whichever commerce protocol or settlement rail — or whether there's a commerce protocol involved at all — the transaction happens to use. Regardless of which vendor or approach you're evaluating, stages 3 and 5 are the ones worth the closest look.

The Takeaway

An agentic payment is five distinct handoffs, not one event: intent, proposal, authorization, settlement, and reconciliation. Each stage is a place where trust either gets built in or doesn't, and each one is typically owned by a different system or party. That holds whether the payment is a consumer checkout or a corporate treasury transfer — the stages don't change, only who's running them does. The next time you're evaluating a vendor, comparing protocols, or scoping an internal build, use these five stages as the framework, and ask the specific question at each one, rather than asking whether the whole system can be trusted in one go.

Talk to our team about closing the authorization and reconciliation gap in your agentic payment stack, or read more on what agentic payments are.