The buyer requests the service, selects an accepted payment option, and authorizes payment.

The seller sets the price and accepted options, checks the payment through its integration, and supplies the purchased result.

InFlow processes supported payments and applies spending controls when the buyer uses an InFlow account.

In x402, a facilitator is the service the seller calls to verify and settle a payment. InFlow fills that role. Settlement is the payment-processing step that transfers or charges the funds, depending on the selected payment option.

Suppose your application wants to purchase a report from a paid endpoint:

1. Request the report. The buyer calls the seller’s endpoint.
2. Receive the payment requirements. The seller returns 402 Payment Required, including the price and accepted payment options. This is the normal response to an unpaid request.
3. Prepare the payment. The buyer selects a supported option and obtains the payment information needed for the request. InFlow-managed spending may require approval.
4. Send the paid request. The buyer calls the endpoint again, carrying an MPP credential or x402 payment payload.
5. Receive the result. The seller’s integration checks and processes the payment. A successful purchase returns the report along with the protocol’s payment-result information.

The payment credential or payload carries the information the seller needs to process this payment. Preparing it alone does not complete the purchase; the buyer still needs to send the paid request and receive the result.

MPP and x402 describe how applications exchange payment information. The selected payment option determines how the purchase is paid.

An MPP inflow charge using the balance rail and an x402 balance payment both use an InFlow balance. They express the purchase through different protocols.

Supporting the same protocol does not guarantee compatibility with every payment option. The buyer must support an option the seller actually offers. See Choose payment options for how to select a compatible option.

InFlow checks the applicable spending rules for an InFlow-managed payment. An applicable approval policy can permit spending without a new manual approval. Otherwise, the request can require owner review or be declined by policy. See Policies for configuring these rules.

Approval permits spending; it does not mean the payment or delivery has finished. See Approvals and allowances for how to control this spending.

Buyers using external wallets follow their wallet’s authorization process instead. Accepting payments through InFlow does not require every buyer to use an InFlow account.

Track the payment and the purchased result separately:

• Payment prepared: the buyer has the credential or payload needed to proceed.
• Payment successful: payment processing reports success.
• Result received: the buyer receives the purchased report, download, or other response.

A timeout does not tell you whether payment succeeded. Keep the original payment identifiers and check the outcome before starting another payment. Follow Status and recovery when the outcome is uncertain.

If payment succeeded but the report was not delivered, investigate delivery separately rather than treating the payment as declined. Sellers should follow Deliver paid results to handle that application-side work.

Set up your account and API key using Accounts and environments, then follow the quickstart for your application.