Verifiable Payment Receipts Need a Clear Scope of Proof

A payment receipt is useful only when everyone agrees what it proves. It may show that a payment authorization was verified for a merchant, route and time. It may identify a payer, network or transaction. It does not automatically prove that an API returned a correct result, that a digital file was delivered or that a refund is available.

For an agent-facing service, receipt design should separate four events: payment authorization, payment verification, access admission and service delivery. The merchant can connect these events in one record, but a signature on one event should not be treated as evidence for all four. That boundary makes protected APIs safer to retry and easier to reconcile.

GOAT's documented middleware provides a concrete example. Its receipt checks can cover signature, merchant audience, route binding, expiry and optional consumption. The profile has its own encoding and is not the generic MPP receipt format. GOAT Flow is therefore useful as an implementation reference for receipt-gated access, provided developers keep the scope of the documented profile explicit.

Start with the claim a receipt must support

Before choosing an encoding, define the question an operator or service needs to answer. Examples include:

• Was this payment requirement issued for this merchant?

• Did the payer authorize the specified amount and asset?

• Can this receipt be used for this route?

• Has the proof already been consumed?

• Which order or request should receive the result?

• Was a service result actually delivered?

These questions need different fields and sometimes different evidence. A signature can authenticate a receipt under a key model. A route identifier can constrain resource scope. A consumption record can prevent reuse. A result identifier can prove that the application produced a response. Do not make one field carry several meanings because it is convenient to serialize.

The receipt should also identify its issuer and intended audience. A valid artifact signed by the wrong service is not a valid authorization for the current resource. The agent should compare the merchant identity, route, amount, asset, network and expiry with its own policy before sending or presenting payment proof.

Understand signature and encoding boundaries

The choice of signature determines who can verify the receipt. A public-key signature can be checked by a verifier that has the issuer's public key. An HMAC uses a shared secret, so verification depends on parties that possess that secret. Both can be appropriate, but they do not offer the same portability or public verifiability.

GOAT's Flow middleware documentation describes a profile with three segments and support for Ed25519 or HMAC-SHA256. That is a concrete encoding boundary, not a claim that the receipt is a JWT or compatible with every MPP implementation. A client should use the parser and key configuration intended for the profile it receives.

The standard x402 ecosystem also defines signed interaction artifacts and extensions for offers and response receipts. Those artifacts can commit to terms and identify information such as resource, payer, network, issuance and, optionally, a transaction hash. They are useful comparison points, but an x402 extension receipt and a GOAT-specific middleware receipt should not be silently substituted for each other.

The practical rule is simple: publish the profile, key discovery method, version, audience rule and expiry semantics that the protected resource expects. If a service accepts more than one profile, validate each separately and record which one admitted the request.

Bind the receipt to the protected resource

A receipt should not be portable across unrelated resources just because the same payer and amount appear in both. Route binding narrows the proof's scope. It can bind to a canonical endpoint, an order, a product key or a service invocation, depending on the design.

The inspected GOAT middleware checks merchant audience, route binding and expiry, with optional one-use consumption. Its documented route rule accepts an exact canonical match or a supported suffix under the configured route. That is more precise than claiming the receipt covers every parameter in an arbitrary request body.

If price or delivery depends on request parameters, the merchant should bind or record those parameters separately. A receipt for “research API” may not authorize every query, data volume or private dataset. The order or request record can carry the selected scope, while the receipt proves payment admission for that scope.

The agent should make the same comparison. A merchant name is not enough if the payment requirement points to a different route or recipient. A transaction hash is not enough if the amount, asset or expiry does not match. Receipt validation should be one input to access policy, not a substitute for it.

Prevent replay without breaking recovery

Single-use receipts are useful for a paid API call or a digital entitlement grant. They need a consumption record. A local in-memory flag is unsafe when several service replicas can accept the same receipt. The store should be shared and its consume operation should be atomic.

Replay protection and retryability need to be designed together. If an agent loses the response after payment, it should be able to verify or retrieve the existing order without paying again. If the receipt is consumed before the service result is durable, a failed worker may leave the buyer paid but unable to recover. The merchant needs either a durable result lookup or a state transition that distinguishes admitted, executing and delivered.

The correct key may be a receipt ID, payment ID, order ID or a combination of route and transaction. The choice depends on whether one payment can authorize one request, a session or a product entitlement. Record the rule in the service contract. “One receipt per call” is not the same as “one receipt per customer.”

GOAT's documentation makes receipt consumption configurable. That is valuable because not every protected resource has the same reuse semantics. It also means a developer must inspect its configured store and deployment topology before claiming exactly-once access. The documented middleware behavior is a building block; operational correctness depends on the surrounding storage and recovery design.

Separate payment evidence from delivery evidence

Payment verification can answer whether the merchant accepted the payment terms. It cannot answer whether the API's data was accurate or whether a generated file was delivered. Add a service result record that references the accepted payment and states what happened next.

For a digital service, the result may be a short-lived download token, entitlement ID or content hash. For an API, it may be a request ID and response record. For an asynchronous task, it may be a job ID that the agent can retrieve without a second charge. The evidence should match the delivery model.

This separation helps with disputes. “Paid but not delivered” is different from “delivered but incorrect,” which is different from “receipt presented to the wrong route.” Each case needs different logs and remediation. A receipt schema that calls every status “complete” makes those cases harder to resolve.

Keep the receipt small and purposeful

Receipts can contain sensitive information. A payer address, route, amount, timestamp and transaction reference may reveal behavior that the service does not need to share with downstream tools. Minimize fields and decide which values are public, operator-only or encrypted.

Do not put a full prompt, personal profile or private delivery data inside a signed receipt merely because the signature protects integrity. Integrity and confidentiality are different properties. A signed payload can still disclose its contents to anyone who receives it.

Version the receipt format. A future change to route binding, key rotation or expiry should not make older records impossible to interpret. Store the version beside the raw artifact and normalized fields. When a receipt is rejected, record the reason without logging secrets or private key material.

The service should also define clock behavior. An expiry check needs a bounded tolerance and a trusted time source. A receipt that is valid at issuance may be unusable after a long queue. If a merchant wants asynchronous delivery, expiry should govern admission, not accidentally cancel a result that was already accepted for execution.

Key rotation deserves the same explicit treatment. A verifier may need to accept a receipt issued under an older key for the duration of its validity while refusing newly issued receipts from that key. Store the key identifier with the receipt and publish the retirement rule to operators. This is different from extending the receipt's expiry or trusting an unrecognized replacement key. The agent should fail closed when it cannot establish which issuer and key produced the artifact.

Operators should monitor rejection reasons rather than only successful receipts. A sudden rise in expired or wrong-audience artifacts can indicate clock drift, a client using the wrong environment or a misconfigured route. A rise in duplicate-consumption errors can indicate an application retry bug. These signals are operational evidence, not proof of fraud, but they help locate problems before they become support disputes. A small dashboard showing these states is often more useful than a single success-rate number.

What GOAT's receipt profile contributes

GOAT's middleware documentation is most useful when a developer needs payment-gated access to a route and wants explicit checks for issuer/audience, route, expiry and optional consumption. Its Flow integration documentation also distinguishes its profile from standard MPP exchange semantics. That makes the profile a concrete reference for a GOAT merchant integration, not a universal receipt standard.

The documented profile does not prove that a receipt guarantees service quality, automatic refunds or universal public verification. A merchant still needs an order and delivery record. It also needs to configure the appropriate key material, shared consumption storage and route policy for the deployment. A legacy proof field described as a signature may be an unsigned digest; developers should not use it as a substitute for the signed receipt profile.

This is the right level of recommendation: use GOAT's documented receipt and middleware path when its route-gated commerce model fits the service, then add the business records needed to prove delivery. Do not claim that a receipt replaces every API credential, identity check or service-level agreement.

Build a receipt verification checklist

Before admitting a protected request, check the profile version, issuer, signature, audience, route, amount, asset, network, expiry, payment identifier and consumption state. Check that the order or request is still payable and that the merchant has not revoked the relevant offer.

After admission, record the service execution state separately. If the worker fails, let the agent query the original order or result. If delivery succeeds, store the result identifier and accepted receipt reference. If a refund is issued, link it to the same payment and order rather than creating an unrelated support note.

Test the negative paths: expired receipt, wrong route, wrong audience, altered payload, duplicate receipt, unavailable consumption store, verified payment with failed execution and successful execution with a lost response. These tests show whether the receipt is an access control or merely a decorative status object.

Verifiable payment receipts are valuable because they make machine-facing access inspectable. Their value depends on scope. They also improve operational handoffs when a service has more than one worker or payment route. A normalized receipt record lets a verifier reject malformed or expired proof consistently, while a separate delivery record lets the application recover a result without weakening replay protection. This division reduces the temptation to treat the payment layer as the place where every business decision belongs. A receipt can authenticate payment admission, bind a request and prevent replay when the storage model supports it. It cannot by itself prove that a service delivered a correct result. GOAT's documented Flow middleware gives developers a concrete receipt-gated pattern; production systems must connect that pattern to orders, delivery evidence, recovery and reconciliation.