The agent paid. What did it receive?

Imagine an agent buying a market-data report from an API. It pays the quoted price, sends the request, and waits. The provider generates the report, but the connection drops before the agent receives the response.

The buyer reports that it paid and got nothing. The provider reports that it produced the result.

Both accounts could be accurate.

The payment system may resolve whether a payment was authorized, captured, or settled. The provider may know what it generated. The buyer may know what arrived. Reviewing the purchase requires bringing those observations together without treating one as a substitute for another.

For agentic commerce, that remains true whether the purchase uses a card, an account balance, or an HTTP-native payment flow.

A purchase has several outcomes

For a paid API, separate the commercial question into parts:

This is a way to structure a review, not a universal transaction standard. A synchronous data request and a long-running research job will have different evidence and acceptance criteria.

For the market-data example, the buyer’s criteria might specify the instrument, date range, output format, and freshness requirement. Receiving a file does not establish that the file satisfies those terms. A correct content digest does not establish that the market data is accurate.

Agree on the relevant outcome before deciding what a receipt should contain.

Payment evidence stays tied to the payment system

Authorization, capture, settlement, and refund are distinct states. Use the upstream artifact that supports the state you report. Preserve its identifiers and relevant context so the reviewer can evaluate it under the provider’s rules.

A reference to a payment is not verification of that payment. A signed wrapper around a provider response is a statement by the wrapper’s signer about the material it observed. The wrapper does not acquire the provider’s authority or establish a stronger state than the original evidence supports.

Arrival order also needs care. Stripe’s webhook guidance says event delivery is not guaranteed to follow generation order and that duplicate deliveries can occur. A commerce timeline should not silently interpret the latest-arriving webhook as the latest business state.

Retain native event identifiers, distinguish event time from observation time, and use the provider’s documented state semantics. Resolve uncertainty through the provider where necessary. Signed records preserve the account of that process; they do not settle money.

A result digest is useful when its meaning is clear

Suppose the provider signs a record containing a digest of the generated report. The buyer later supplies a file matching that digest.

If the digest is correctly computed and checked, the reviewer can establish that the supplied file matches the bound representation. This is useful for assessing whether both parties are discussing the same artifact.

If the buyer supplies no file, the provider’s digest does not establish receipt. If the file exists but its quality is disputed, a match does not resolve the quality dispute. If the API compresses, normalizes, or reformats the output, the binding must identify which representation was hashed and how it was produced.

These details belong in the verification design. “Content verified” is too vague when it hides whether the check covered bytes, a documented canonical representation, or only the presence of a digest field.

Also separate connection-level signals from application receipt. A successful write to a socket is different from an acknowledgment that the buyer application received a complete usable result. Preserve the signal you have and describe it accurately.

Retries complicate both charging and delivery

After the connection drops, the agent may retry the purchase. Did it repeat the same intended operation, request another report, or create a second payment?

That depends on the integration. Stripe’s idempotency documentation describes how an idempotency key lets a client retry a request without repeating the operation within the documented conditions. Those conditions belong to Stripe’s API. Other payment and fulfillment systems need their own retry contracts.

Preserve a reference for the intended purchase and separate references for attempts. Connect payment and fulfillment records using the identifiers appropriate to each system. Do not assume that idempotent payment also makes report generation or delivery idempotent.

Evidence cannot repair a duplicate charge. It can help the operator determine what each attempt reported and which provider state needs reconciliation.

Make disagreement visible

For the interrupted report request, an evidence case might support these findings:

Those findings still leave a fulfillment question open. They are more useful than a single “purchase verified” badge because they show where additional evidence is needed.

If the buyer supplies a conflicting observation, preserve it. A reviewer may need to compare the attempts, the representations, or the terms. The purpose of the case is to make the disagreement inspectable, not manufacture agreement between two signatures.

Build for the person who reconciles the exception

For a paid API provider, the first evidence workflow should serve the operator who handles failed purchases and billing questions. That person needs enough information to distinguish payment failure, generation failure, interrupted delivery, duplicate attempts, and a dispute about the result itself.

PEAC Protocol can preserve bounded, signed interaction statements alongside native commerce artifacts. Originary helps issue, verify, and package selected records for handoff. External payment evidence still needs its own evaluation, and the underlying data or service may need a separate acceptance check.

A useful pilot does not need every payment rail. It needs one paid endpoint, a specific exception, and a recipient who can use the evidence to decide what to investigate or reconcile.

Start with the interrupted-delivery case. If your export can show what was paid for, what the provider reported producing, and where receipt remains unknown, it has already improved on a success label that hides all three.

Sources

• Stripe webhook guidance
• Stripe idempotent requests
• PEAC commerce evidence pattern