The problem

Your agent made a payment, or you think it did, but you cannot confirm it. The expected confirmation has not arrived: no webhook event registered, the agent's task is waiting on a signal that did not come, or you simply cannot tell whether the money moved. The payment may well have settled on chain, but your system has no confirmation of it, so you are stuck in uncertainty about a transaction that may already be complete.

This is the not-confirming problem, and it is important to recognize that it is usually a confirmation-path issue, not a payment failure. The payment and your awareness of it are separate things: a payment can settle while your confirmation never registers, because the webhook did not arrive, was not verified, or was dropped. The symptom is uncertainty rather than a clear failure, and the fix is to repair and rely on the confirmation path so you know, durably, what actually happened.

Why it happens

Confirmation of an agent payment is event-driven, and the gap usually opens somewhere in that event flow. The most common cause is the webhook: your endpoint may be unreachable, your code may be failing to verify the signature and therefore dropping valid events, or the event may fall outside the replay window and be rejected. In any of these, the payment settled but the confirming event never registered on your side, so you see no confirmation.

A second cause is a transient settlement error. During the chain-adapter rollout, the settle step can return a 503 that is not a final failure but a temporary unavailability, which can leave a payment's status ambiguous if you treat the 503 as definitive. A third is simply looking in the wrong place, expecting a synchronous result when confirmation is meant to come asynchronously via webhook. In all cases, the payment itself may be fine; what is broken is how you learn about it, which is what the fix addresses.

The fix

The fix is to rely on the payment webhook as your durable confirmation, set up correctly. Listen for the payment.received or payment.sent event, which fires when a payment settles, and verify each delivery with webhooks.verify against your signing secret before trusting it. Treat the verified event as the source of truth for confirmation: when it arrives and verifies, the payment is confirmed; your system records it and the agent's task can proceed.

This makes confirmation reliable because the webhook pushes settled events to you durably, rather than you guessing from a synchronous call that may not reflect final state. Get the webhook path right, reachable endpoint, correct verification, respect for the replay window, and the not-confirming problem largely disappears, because every settled payment produces a confirmation you actually receive. For the broader practice of building a transaction record from these events, see how-to-track-ai-agent-transactions.

Confirm a specific payment

When you need to confirm one particular payment rather than rely on the stream, look it up directly. Call transactions.get with the payment's id to retrieve its current status, which tells you whether that specific payment settled. You can also find the transaction on the block explorer for the chain, Base, to see it confirmed on chain independently of any webhook.

This direct lookup is the right tool for spot checks and for reconciling a payment you suspect you missed. If a confirmation did not arrive but transactions.get or the explorer shows the payment settled, you know it was a confirmation-path issue, not a payment failure, and you can record it and move on. Use the webhook stream as the backbone for confirmation at scale, and transactions.get plus the explorer for checking or reconciling individual payments. Note there is no single list-all-transactions endpoint, so build the broad record from the event stream and use the lookup for specifics.

The transient 503 case

The transient 503 deserves its own handling, because it is easy to misread. During the chain-adapter rollout, the settle step can return a 503 that means settlement is temporarily unavailable, not that the payment failed. If you treat a single 503 as a final failure, you may conclude a payment failed when it did not, or retry blindly in a way that double-pays.

The right response is to not treat a 503 as definitive. Re-check the payment's actual status via the webhook or transactions.get before concluding anything, and for the transient case use a bounded, careful retry rather than an immediate blind one. This is the only failure kind where a retry is appropriate, and even then only after confirming the payment did not already settle. Handling the 503 correctly, re-check rather than assume, prevents the most confusing version of the not-confirming problem, where the payment is fine but a misread transient error makes it look broken. The full failure taxonomy is in how-to-handle-failed-agent-payments.

Fix webhook delivery

If confirmations are not arriving at all, repair webhook delivery specifically. Confirm your endpoint is publicly reachable and responding, since an unreachable endpoint means no events land. Verify the signature correctly with webhooks.verify, because verification that is implemented wrong will reject valid events and you will drop confirmations you actually received. Respect the replay window, events outside roughly 300 seconds are rejected, so process promptly and do not rely on very delayed handling.

To test the path end to end, send a test event and confirm it arrives and verifies. If you have missed events during an outage, reconcile by looking up the affected payments with transactions.get rather than assuming they failed. A correctly wired, verified, promptly-handled webhook endpoint is the foundation of reliable confirmation, so fixing delivery here resolves the root of most not-confirming cases. Once the path is solid, confirmations arrive as they should, and the uncertainty that defined the problem is gone.

A quick diagnostic order

When a confirmation does not arrive, work through a short order rather than guessing. First, ask whether the payment actually settled: look it up with transactions.get or on the block explorer. If it settled, the problem is your confirmation path, not the payment, so move to the webhook checks. If it did not settle, the problem is the payment, and you turn to the failure taxonomy instead.

Second, if it settled but you got no event, check webhook delivery: is the endpoint reachable, is the signature verifying, was the event within the replay window. Third, if you saw a 503 from settle, do not conclude failure; re-check status, since it may be the transient case. Following this order, settled or not, then delivery, then transient errors, keeps you from the two common mistakes: assuming a settled payment failed because no event arrived, and assuming a transient 503 is final. A minute of structured diagnosis usually pinpoints whether you are looking at a confirmation-path issue or a genuine payment problem, which then tells you which fix above to apply.

Related reading

If your agent's payments are not confirming, the adjacent material helps. The full failure taxonomy and how to respond per kind is in how-to-handle-failed-agent-payments, and building a durable transaction record from webhook events is in how-to-track-ai-agent-transactions. Together they take you from uncertainty to reliable confirmation. Pricing is on the pricing page.