The problem

You need to confirm your agent's payments, to know, reliably and durably, that a payment actually settled, so you can record revenue, release a result, or reconcile your books. The question is not whether a payment failed, but how you positively confirm one that succeeded, and which signal to trust as proof. Without a clear confirmation method, you are left unsure whether to act on a payment, which is uncomfortable when money and downstream actions depend on it.

This is the payment-confirmation problem, framed constructively: not troubleshooting a confirmation that did not arrive, but knowing the right way to confirm in the first place. The answer is a small set of methods, a durable webhook, a direct lookup, and an on-chain check, each suited to a different need, with one of them serving as your backbone. The symptom is wanting reliable confirmation; the fix is to use the right method for each situation and treat the durable one as the source of truth.

What confirmed means

Before the methods, it helps to define what confirmed means for an agent payment. A payment is confirmed when it has settled, the USDC has moved on chain from payer to payee, and you have a trustworthy record of that settlement. There are really two parts: the settlement itself, which happens on chain, and your awareness of it, which is the record you can act on. Confirmation is having both: the payment settled, and you know it durably.

This distinction matters because the two can come apart, a payment can settle while your record of it lags or is missing, which is the not-confirming failure. Good confirmation closes that gap: it ensures that for every settled payment you have a verified, durable record, so settled and known stay aligned. So confirming a payment is not just checking the chain once; it is having a reliable mechanism that turns every settlement into a confirmation you hold. The methods below are how you build that.

The three confirmation methods

There are three methods to confirm an agent payment, each with a role. The first is the payment webhook: payment.received when a payment settles to an agent and payment.sent when an agent pays, verified with webhooks.verify. This is push-based and durable, the platform tells you about every settled payment, so it is the backbone for confirmation at scale.

The second is a direct lookup: transactions.get with a payment's id returns that specific payment's status, which is ideal for confirming one particular payment on demand. The third is the block explorer: finding the transaction on chain, on Base, gives an independent confirmation that does not rely on the platform at all. Together these span the needs: the webhook for ongoing, at-scale confirmation; the lookup for a specific payment; the explorer for an independent check. Knowing which to use when is most of confirming payments well.

The fix

The fix is to make the webhook your source of truth and use the other two for checks. Set up the payment.received and payment.sent webhook, verify each delivery, dedupe by event id, and treat the verified events as your durable confirmation record, this is what you build revenue tracking and downstream actions on. For confirming a specific payment, say a particular high-value one, call transactions.get with its id. For an independent check or to reconcile, use the block explorer.

This layered approach gives reliable confirmation without over-relying on any one method. The webhook ensures you hear about every settled payment durably; the lookup lets you check one when you need certainty about it; the explorer lets you verify independently. The fix to the confirmation problem is therefore not a single call but this set of methods used appropriately, with the durable webhook as the foundation. Building the transaction record on the webhook stream is covered in how-to-track-ai-agent-transactions, and setting the webhook up correctly in ai-agent-payment-webhook.

Inline versus durable

It is worth distinguishing two kinds of confirmation that both have a place: inline and durable. Inline confirmation happens within the request: when a caller pays a gated route, the server adapter verifies the payment before running your handler, so by the time your code runs, that call is confirmed paid in real time. This is what lets a paid endpoint serve only after payment, and it is confirmation for that one call at that moment.

Durable confirmation is the persisted record you can act on later: the verified webhook event, stored, that says this payment settled. You need both. Inline verification gates the immediate action, serve the call only if paid; durable confirmation gives you the lasting record for accounting, reconciliation, and any downstream process that runs after the request. Conflating them leads to gaps, relying only on inline means you have no durable record, while relying only on the webhook means you might serve before confirming. Use inline to gate the moment and the webhook to record it durably, and confirmation is complete on both timescales.

When to trust each

A practical guide to which method to trust: for ongoing operation, trust the verified webhook stream, it is your reliable, at-scale confirmation, and you build on it. For a question about one specific payment, did this exact payment settle, trust transactions.get by id, which gives a direct, current answer. When you want assurance independent of the platform, or are reconciling against the chain, trust the block explorer, which shows the on-chain truth.

The mistake to avoid is using the wrong method for the need: polling transactions.get in a loop instead of using the webhook, or expecting a stale webhook to confirm something old instead of looking it up. Match the method to the situation, webhook for the stream, lookup for the specific, explorer for the independent, and verify everything you trust. Used this way, the three methods give confident confirmation at every scale, from a single payment to a whole stream, which is exactly what the confirmation problem asks for.

Designing around confirmation timing

A practical part of confirming payments is designing for when each kind of confirmation arrives. Inline verification is immediate, by the time your gated handler runs, the call is confirmed, so for serving a paid call you do not wait for anything else. The durable webhook event arrives shortly after settlement, asynchronously, so any process that depends on the durable record, accounting, releasing a separate deliverable, reacting to revenue, should be driven by the webhook rather than assumed to be instant.

So structure your system to match: act immediately on inline-confirmed calls, and trigger anything that needs the durable record off the webhook when it lands. Do not block a user-facing flow waiting for the webhook if inline verification already confirmed the call, and do not finalize accounting off the inline check alone when the durable event is what you reconcile against. Matching each action to the confirmation it truly requires keeps the system both responsive and correct, which is the goal of confirming payments rather than just checking them once.

Related reading

To confirm agent payments well, build the record on the webhook stream per how-to-track-ai-agent-transactions, and set the webhook up correctly per ai-agent-payment-webhook. Together they give you durable, verified confirmation as the backbone, with direct lookups and the explorer for checks. Pricing is on the pricing page.