An Agent Paid. Now What?

An agent can pay in seconds. Good. Now the slow question: can the business reconcile the whole transaction?

Each system keeps its own fragment. Without one record tying them together, support inherits a scavenger hunt.

The useful unit is the whole paid request. Its record begins with the quote and ends when the money reaches its destination.

What “payment successful” leaves unanswered

Every payment method exposes its own states. Stripe's PaymentIntent lifecycle can require a payment method, an action, processing, or capture before it succeeds or is canceled. Once the PaymentIntent succeeds, the payment flow is complete. The funds may still remain pending before they become available for payout.

The x402 protocol uses a different interaction. A resource server returns payment requirements, verifies the buyer's payment payload, fulfills the request after verification, and settles directly or through a facilitator. The protocol standardizes the paid HTTP exchange. Commercial judgment stays with the seller, who sets the price and defines correct fulfillment. Refund approval and accounting policy stay with the business.

A green payment status is useful. It is also narrow. The teams around the transaction still need answers:

• Which version of which resource did the buyer purchase?
• Which price and terms did the buyer authorize?
• Did the seller execute the requested work exactly once?
• What was delivered, and when?
• What fees, refunds, or adjustments changed the net amount?
• Has the charge settled, become available, and been included in a payout?
• Can support explain the outcome without joining unrelated logs by hand?

Those answers form the commercial record behind the transfer.

Give every paid request a spine

A dependable transaction needs an identity that survives every system it touches. Stable identifiers keep the pieces connected, even when the data lives across several tables or services.

For one paid request, preserve at least:

• the resource identifier and version;
• the quoted amount or pricing rule, currency, accepted method, and expiry;
• the buyer's authorization or payment commitment;
• the request and idempotency identifiers;
• the verification decision and reason;
• the fulfillment status, measured usage, and delivery evidence;
• the final gross charge, fees, refunds, and net amount;
• the payment, settlement, availability, and payout states; and
• links from every correction or reversal back to the original transaction.

One record gives every team a consistent view of the purchase. Product can see whether the resource ran, while finance traces the net amount into a payout. Support and the buyer both get an explanation that points to the same transaction.

The record works only when every view points to the same transaction.

The quote belongs in the record

Every transaction starts with a versioned commercial offer. It binds the resource and its price to the accepted payment method and the conditions for execution.

A fixed-price resource may need only one amount. Metered or outcome-dependent work may require the buyer to authorize a maximum while the seller records usage and calculates the final charge within that limit. Either way, the seller must be able to reproduce the accepted quote. Today's price page cannot prove what the buyer authorized yesterday.

Authorization establishes whether the buyer or agent can make the commitment under the applicable limit or mandate. Verification confirms that the supplied payment proof satisfies the quoted requirement. An incoming endpoint request proves neither.

Risk and policy also belong here. The seller needs explicit rules for:

• unsupported currencies and networks;
• expired quotes and duplicate requests;
• invalid proofs and spending limits;
• suspicious behavior; and
• resources that should not execute automatically.

The rail supplies technical facts. The seller decides whether to proceed.

Payment can succeed while the work fails

Payment and delivery fail independently, often at the least convenient boundary. A payment can be valid while the requested work times out. Work can finish while the response is lost. An agent may retry because it never received an answer, even though the seller already executed the action.

Idempotency keeps a network failure from turning one intended purchase into two charges or two irreversible actions. A stable idempotency key should resolve to the same transaction, allowing the seller to return the existing result or safely continue the workflow. That makes it a commercial control as well as an API safeguard.

The fulfillment record should describe the outcome in product language:

• accepted but not started;
• executing;
• completed with a result;
• partially completed with a measured charge;
• failed before billable work;
• failed after billable work; or
• canceled or compensated.

Choose states that fit the resource. A payment status cannot carry this meaning for you.

For metered work, attach the usage behind the final charge to the same transaction. For a purchased artifact, record its stable delivery reference and version. For an action, record the outcome and enough evidence to distinguish success from a retryable failure. “The endpoint returned 200” is a debugging clue. Delivery evidence makes it a result the seller can support.

Follow the money all the way to payout

Payments literature separates validation, conditionality, and settlement because each changes the transfer's risk. The CPMI-IOSCO principles define final settlement as the point when a transfer becomes unconditional and irrevocable under the relevant system's rules. That point depends on the rail and legal framework, so “authorized,” “captured,” and “settled” must remain distinct labels.

A successful payment can sit in a pending balance before the seller can use it. Stripe's balance documentation distinguishes pending funds from available funds and notes that timing varies by country and payment method. Refunds, disputes, fees, and reserves can also change the balance available for payout.

A payout moves funds from the payment balance to the seller's bank account or another destination. One payout can include many underlying transactions. Stripe's payout reconciliation guide connects a payout to its balance transactions, including charges, refunds, fees, and the payout movement itself.

For a seller, the operating questions are concrete:

• Which completed charges are still pending?
• Which settled amounts are available?
• Which fees or adjustments changed the expected net proceeds?
• Which transactions were included in each payout?
• Which payout failed, and what remains owed?
• Which currency should be held, converted, or paid out?

Speed helps. Finance still has to connect the settlement to the resource that produced it and the payout that carried it.

A transaction keeps moving after “success”

Later events can change the financial outcome of a completed sale. Failed fulfillment may trigger a full or partial refund. A dispute can reverse the payment, and a payout can fail. An accounting correction may reclassify the transaction without changing what the buyer paid.

Append later events to the commercial history instead of overwriting the original transaction. Each event needs:

• its own amount and reason;
• the actor and timestamp; and
• a link to the original transaction.

The consequences can be financial as well as operational. Stripe's dispute documentation explains that a card dispute reverses the payment and can debit the seller's balance for the payment amount and fees. Other rails use different finality and remedy models. Every seller still needs a policy for failed delivery and duplicate execution. Support needs a path to correct the commercial outcome.

An irreversible rail moves the remedy outside the transfer itself. The seller still needs a way to make an unsatisfied purchase right.

Six questions before adding another rail

Before adding another payment method, test whether the operating layer can answer six groups of questions:

1. Offer: Is the resource stable, described, versioned, and priced in a way software can evaluate?
2. Control: Can the seller verify authorization, payment requirements, limits, risk rules, and duplicates before doing paid work?
3. Fulfill: Can the resource execute safely, measure usage, preserve evidence, and recover from retries or partial failure?
4. Record: Can one transaction connect the quote, request, payment, result, fees, and adjustments?
5. Reconcile: Can gross charges become explainable net balances and payouts without manual reconstruction?
6. Resolve: Can support handle refunds, disputes, failed payouts, and product failures while preserving the original record?

One fuzzy answer can produce a technically successful payment that nobody can explain. A lean first implementation works when every capability still has an owner and a state model.

Start with one resource. Then try to break it

Trace one resource from offer to payout. Choose an action with a clear outcome. Write down:

• its price and authorization rule;
• the accepted payment method and fulfillment boundary;
• the failure states and refund policy; and
• the transaction identifiers, settlement destination, and reconciliation path.

Now make it misbehave:

• send the same request twice;
• lose the response after execution;
• let payment succeed while execution fails;
• settle less than expected; and
• ask for a refund.

If the record remains understandable through every case, the operating model is ready for live transactions.

The agent purchase flow explains how discover, request, quote, commit, execute, charge, and settle fit together. Use it to map the operating responsibilities around one flow before choosing more payment rails.

recuut keeps the transaction connected from price to payout. The record still holds when the work fails or the financial outcome changes later.