Start with one purchase your application supports, such as buying a report. Record its endpoint, HTTP method, input, price, and expected result. Repeat the checks for other payment options and materially different purchase flows you expose.

• For a seller integration, test your running endpoint with a compatible buyer. The InFlow CLI can test payment options it supports; other options need a buyer that supports that method.
• For a buyer integration, run your application’s payment code against a known Sandbox seller. A successful CLI purchase does not test your application’s offer selection, approval handling, or response processing.
• If you build both sides, test them together and keep focused tests for each side. This helps distinguish a seller failure from a buyer failure.

Use the matching Sandbox accounts, credentials, and test funds. The seller quickstart and buyer quickstart provide a complete 0.01 USDC example. Other payment methods have their own setup and test amounts; follow the relevant Ways to pay guide.

Confirm the destination, operation, environment, and spending limit before executing a payment test. Use test assets and provider test credentials, not live card details or production funds.

Send a valid request to the paid endpoint without a payment credential. Supply service authentication first if the endpoint requires it. Otherwise, an authentication failure can prevent the request from reaching the payment check.

• Confirm HTTP 402 and readable payment requirements: WWW-Authenticate: Payment for MPP, or PAYMENT-REQUIRED for x402 v2.
• Compare the advertised seller or recipient, amount, currency, and network where applicable with the purchase you configured.
• Confirm that the response withholds the paid result and does not finalize an order, grant paid access, or trigger fulfillment. Creating an unpaid purchase record is a separate application decision.
• Call a free endpoint separately. Confirm its expected response without a payment challenge or a new payment.

Use the inspection commands in Accept MPP or Accept x402 to read the advertised options. A valid 402 confirms that requirements were advertised. It does not prove that payment or delivery works.

If one endpoint supports both protocols, its unpaid response must offer both choices. If you use separate endpoints, check each endpoint’s intended protocol. See Accept both protocols for the two arrangements.

Make one purchase with the selected payment option. If approval is requested, check its seller, amount, and currency before approving. Keep the original program running so it can continue that purchase.

• Check the final HTTP status and actual result. For a report, verify that the content matches the requested report and its inputs, not merely that the server returned HTTP 200.
• Check the protocol’s receipt or payment-response fields and retain the payment reference. A response containing a ready credential is not the purchased result.
• Find the corresponding payment in Sandbox Transactions when InFlow processes it. Compare the account, seller, amount, currency, and final status. Use the relevant provider or blockchain record for payments processed outside InFlow.
• Confirm that your application delivered the purchase once. Payment completion and product delivery are separate checks.

Decoding a receipt alone does not independently confirm settlement. Check the transaction record alongside the response and delivered result. Preserve the references needed to investigate any disagreement.

For an endpoint accepting both MPP and x402, make a separate test purchase with each protocol. Each must be sufficient by itself; the buyer must not need a second payment through the other protocol. Use distinct test purchase references so this is not confused with retrying one order.

Run the same purchase through the code your users will use. A standalone example confirms its own integration, not your application’s configuration or error handling.

• Offer more than one payment option in a controlled test. Confirm that your selection rules choose the intended method, currency, network, and amount. Also test a response with no compatible option.
• For a request with a body, confirm that the paid retry preserves the intended HTTP method, input, and service authentication. Check that credentials stay with their intended destination, including when a server responds with a redirect.
• Exercise a purchase requiring approval and, if configured, one already permitted by an allowance. Confirm that progress messages describe the actual state and do not always demand another approval.
• Check how the application handles a final error response, an unexpected response body, and a missing or unreadable receipt. None of these outcomes should automatically start another purchase.

Retain purchase references before waiting when your application needs recovery after a restart. See the Go, Node.js, Python, or Rust guide for the relevant interfaces. Status and recovery explains which operation to retry after an interruption.

Observe both the payment outcome and the application’s effects. An error response is not enough if the application already delivered an order or granted lasting access.

Use controlled failures for conditions you cannot reliably trigger through a provider’s Sandbox. A simulated settlement response can test your application’s reaction, but it cannot prove that the real provider integration works. Keep a genuine end-to-end Sandbox purchase as a separate check.

Test the handler timing of your selected adapter and payment flow rather than assuming every integration settles at the same point. Deliver paid results explains delivery decisions; Status and recovery covers uncertain outcomes and cancellation.

Repeat the unpaid and paid checks through your test deployment’s public hostname. A request sent directly to the application does not exercise its reverse proxy, gateway, or shared cache.

• Confirm that payment challenges, submitted credentials, and receipt headers reach the intended recipient. Test the request and response directions separately.
• Test the full set of advertised options, especially for a combined MPP/x402 endpoint. Check response-header size if the direct request succeeds but the proxy request fails.
• If a browser calls the endpoint across origins, test from the real application origin. Check preflight requests, allowed request headers, and exposed response headers. Keep InFlow API keys on your server.
• Request a private paid result as another user and without authentication. Confirm that neither the application nor a shared cache discloses the first buyer’s result.

These are test-environment checks, not a request to charge production accounts. Use the same relevant proxy and browser configuration as production while keeping payment configuration in Sandbox.

Keep a short test record with the application and SDK versions, environment, endpoint, selected payment terms, and outcome. Retain purchase and transaction references so another developer can investigate the same run. Exclude API keys, payment credentials, and card data.

• Each supported purchase flow has a successful Sandbox payment and the expected delivered result.
• Invalid requests and failed payments do not grant paid access or finalize fulfillment.
• Interrupted purchases can be investigated without automatically charging again.
• Duplicate handling, cancellation, and the deployed request path have recorded results.
• The project’s unit tests, integration tests, coverage requirements, and static checks pass. Record untested scenarios explicitly rather than marking them successful.

Repeat the relevant checks after changes to SDKs, payment configuration, request handling, or proxies. If your application also uses AEP or ODP, add an end-to-end test through those integrations. They are not prerequisites for a payment-only integration.