Confirm that the requested purchase is valid before collecting payment. Your application owns the product rules and access permissions; the payment integration checks the payment.

• Check that the buyer can access the requested product or account. Apply your existing authentication and authorization rules where access requires them.
• Validate the input, quantity, availability, and price. Reject a request your application cannot fulfill before asking the buyer to pay.
• Check the paid request against the purchase the buyer approved. A payment for one report must not authorize a different report merely because both have the same price.

For example, payment does not authorize a buyer to request another customer’s private report. Check that permission before payment and again when the buyer retrieves a saved result. See Prices and offers for matching payment terms to request-dependent purchases.

Your handler is the application code that generates the report, returns the download, or performs the purchased operation. For the one-time payments in these guides, both integrations check the payment headers before running the protected handler. They differ in when payment completes.

The x402 middleware uses this ordering for exact payments as well. See Understand verification and settlement for how the middleware checks payment, holds the generated response, and releases it after settlement succeeds.

Withholding an HTTP response does not undo application work. If the handler sends an email or ships an order, discarding its response after failed settlement cannot reverse those operations.

This timing describes the examples in these guides, not every payment method or framework adapter. Check your selected integration before adding irreversible work. A payment receipt confirms a payment outcome; it does not prove that the buyer received the product.

Decide what delivery means for your product and how the buyer can recover it. Use your existing report storage, download permissions, or order system when those already serve this purpose.

Generated reports

Retain the completed report or enough information to reproduce the purchased result when recovery is needed. For a report based on changing data, keep the relevant snapshot or saved output. Running the query later may produce a different report.

For example, a buyer pays for a company report, but the connection closes before the response arrives. Recovery should return that purchase’s report, not create a new purchase. Generating the report successfully is separate from confirming that its payment succeeded.

Digital downloads

Associate download access with the confirmed purchase. Check that the caller is entitled to that download before returning the file or issuing another download link. Knowing a purchase identifier alone must not grant access to someone else’s product.

Orders and lasting access

Finalize an order, shipment, or lasting access grant only after confirmed payment. Choose an integration that exposes the successful payment result before that work becomes final.

With the x402 middleware shown here, the ordinary result handler runs before settlement. Do not place irreversible fulfillment there merely because verification passed. Use an explicit payment flow or an adapter-supported settlement hook whose timing you have verified. The SDKs do not share a universal after-settlement callback.

These are application responsibilities, not a requirement to build a new order-management system for every paid endpoint. The simple report examples demonstrate payment and response delivery; they do not implement durable recovery or fulfillment tracking.

Determine whether payment succeeded before deciding how to retry. A timeout or disconnected client does not establish that payment failed. Keep the existing payment reference and purchase details available for recovery.

Use the trusted server-side payment result or the applicable payment-status lookup, not a buyer’s unsupported claim that payment succeeded. Associate that result with the correct purchase and its expected payment terms. A receipt copied from another purchase is not permission to retrieve this result.

Give the buyer a clear recovery path: retrieve the saved result, check the existing purchase, or contact support with its reference. Protect that path with the access checks appropriate to the original purchase. Keep private results out of shared caches, and preserve the selected protocol’s receipt or payment-response headers.

If delivery cannot be completed, apply your product’s support or refund policy. A failed handler does not itself guarantee a refund. See Status and recovery for the buyer’s side of checking an unresolved attempt.

Preventing the same payment from being processed twice does not necessarily prevent your application from delivering the same order twice. A repeated paid request may reach your application again, depending on the integration and payment result.

For a recoverable report or order, reuse the application’s purchase identifier across retries. Record which payment belongs to that purchase and whether the purchased operation has completed. A retry can then return the existing result or status instead of starting the operation again.

Make the decision to start fulfillment safe when two requests arrive together. Checking that an order is unfinished and then starting work can run twice if both requests pass the check. Use your application’s existing mechanism for claiming an order or preventing duplicate jobs.

When both protocols can pay for one order, keep that same application purchase reference. Separate MPP and x402 payment identifiers do not coordinate fulfillment for you. Do not automatically switch protocols while the first payment’s outcome is unresolved.

Define what counts as a new purchase. Two deliberate purchases of the same product are not necessarily duplicates. Match retries to the original purchase rather than deduplicating every request with the same product or amount.

Check payment outcomes and application effects independently. A correct error response is not enough if the handler already shipped an order. Retain your project’s unit and integration tests alongside controlled Sandbox payment tests.

• Submit invalid input or request another customer’s product. Confirm rejection before payment, without returning protected content.
• Test a rejected payment and, separately, a settlement failure after verification. Confirm that neither case grants access or finalizes an order, even if response generation ran.
• Fail result generation after confirmed payment. Confirm that recovery uses the existing purchase and does not request a second payment.
• Interrupt the connection during payment or response delivery. Confirm that an unknown outcome remains unresolved until checked, rather than being treated as a decline.
• Retry a paid request and send simultaneous requests for one order. Confirm one fulfillment and access to the same purchased result. Repeat across protocols if both can pay for that order.
• Try retrieving a saved result as an unauthorized caller. Confirm that knowing its purchase reference or another payment’s receipt does not bypass access checks.
• Confirm that successful delivery preserves the expected receipt or payment-response headers and that shared caches cannot expose private results to another buyer.

Failure-injection tests help exercise conditions that are difficult to reproduce reliably with real payments. They complement an end-to-end Sandbox purchase; they do not replace it. Run paid tests only with approval for the account, amount, and environment.