List the payment protocols and methods your application will offer or accept. Launch the options you have tested; supporting MPP does not require offering every MPP method, or adding x402.

Complete the relevant checks in Test your integration before moving to production. Cover successful purchases, declined payments, approval where applicable, interrupted requests, and delivery of the paid result. Record the application and SDK versions used so you can identify what was tested.

For a seller integration, check the protected routes and their advertised offers. For a buyer integration, check payment selection, spending limits, and recovery. If your application does both, review both sets of behavior.

Sign in to the intended production InFlow account and create its API key. Seller integrations need a Seller account’s key. Buyers use credentials for the account authorizing the purchase; a Seller account can also act as a buyer. Follow Accounts and environments for account selection and key setup.

Prepare only the payment methods you selected. Sandbox credentials and test funds do not establish production readiness.

• For InFlow balances, fund the buyer’s production account in the selected currency. Review the buyer’s approval and allowance settings before the purchase.
• For linked cards, prepare the buyer’s live card and the seller’s required receiving setup. Follow the linked-card procedure rather than treating a saved card as an MPP Stripe credential.
• For MPP Stripe, confirm the intended connected merchant account, Payments Enabled, and the MPP Stripe Profile. Use a buyer capable of supplying a live Stripe Shared Payment Token.
• For Visa CARD, complete its seller setup and the buyer’s linked Visa card and verified allowance. The MPP Stripe Profile belongs to the separate Stripe method.
• For an external wallet, check the wallet’s support for the chosen offer and fund the intended production network and asset. Test-network tokens cannot pay a mainnet offer.

Review the settings your application actually passes to its SDK. Changing the InFlow environment does not automatically change a processor, external wallet, blockchain, or target service to production.

Store keys and signing secrets in private deployment configuration, not browser code, source control, or logs. Environment-variable names depend on your application; setting a variable only helps if the application reads it. Use the configuration examples for Go, Node.js, Python, or Rust.

For a seller deployment, make an unpaid request through the public URL, not just directly to the application server. Supply any required service authentication, but do not authorize a payment yet. A protected resource should advertise its payment options before returning the paid result.

• Confirm the expected 402 challenge and only the payment options you intend to offer. Check the price, currency, network, and recipient or merchant information supplied by the selected method.
• Check that the proxy preserves payment headers and accepts their size. If buyers use a browser, check cross-origin access from that browser too.
• Confirm that the final URL is the intended endpoint. A redirect must not cause credentials to be forwarded to an unrelated destination.

Follow the inspection steps in Accept MPP or Accept x402. If one route offers both, also check combined response-header size. Receiving a challenge establishes that the offer is reachable, not that payment and delivery work.

For a buyer-only integration, inspect the chosen seller’s offer from the deployed buyer application. Confirm that its payment-selection rules accept the intended purchase before authorizing it.

This step spends real money. Obtain the payer’s approval for the endpoint, payment method, recipient, and amount before running it. Choose a small valid purchase that meets the selected method’s minimum; do not assume every method accepts a one-cent test.

Use a buyer compatible with the method you are testing. The InFlow CLI can exercise supported InFlow payment paths; it is not a substitute for every external wallet. For example, MPP Stripe requires a buyer that supplies a Shared Payment Token.

• Submit the agreed purchase and complete any required owner approval or card verification. Keep the original payment reference.
• Confirm that payment completed, not merely that verification succeeded or an approval was granted.
• Check the intended seller’s transaction or processor record for the amount, currency, and payment reference. For MPP Stripe, check the connected merchant’s Stripe account.
• Confirm that the buyer received the correct report, download, or order result, together with the payment receipt where the integration provides one.

If the outcome is uncertain, follow the original transaction using Status and recovery. Do not start a second purchase to determine whether the first succeeded. Payment and delivery are separate checks; use Deliver paid results if payment completed but the result was lost.

A successful purchase verifies the method and route you exercised, not every advertised option. Repeat a deliberately authorized purchase for other launch paths that still need live verification.

After the production checks pass, make the tested integration available to users. Keep enough information to investigate a purchase: the application version, time, payment reference, reported status, and delivery outcome. Keep credentials and personal payment data out of logs.

• Watch for failed payments, unresolved purchases, and missing paid results. Investigate the failed step before asking a buyer to retry.
• Keep Sandbox available for changes to prices, routes, payment selection, approvals, and recovery behavior. Repeat the relevant tests before deploying those changes.
• If a release fails, stop new purchases when necessary while retaining the information needed to resolve existing ones. Rolling back application code does not reverse completed payments.

ODP discovery, AEP enrollment, and Directory publication are optional additions to a payment integration. Add them when you want agents to discover your products or establish authenticated access; they are not prerequisites for accepting payments.