A seller provides the paid service. Your application sets the price and accepted payment options. InFlow processes the payment; your application supplies the purchased result.

A buyer purchases the service. Your application reads the seller’s payment requirements and uses a supported option to pay. InFlow supports account-owner approvals and allowances for controlling spending.

An application can do both. For example, a research service might pay another provider for source data, then charge its customers for a report.

Consider an application requesting a paid report:

1. The service responds with 402 Payment Required and describes the accepted payment options.
2. The buyer selects a supported option and prepares the payment. An InFlow-managed payment may require the account owner’s approval.
3. The buyer sends the payment information with its request. The seller processes the payment before returning the paid result.

Your application remains responsible for generating and delivering the report. Payment approval, payment completion, and successful delivery are separate outcomes.

How payments work explains the payment flow in more detail.

MPP and x402 define how applications exchange payment requirements and payment information over HTTP.

Your service can accept either protocol or both. Supporting both lets buyers use either integration, provided the buyer supports an advertised payment option.

The protocol is only part of that choice. The seller’s configuration and the buyer’s capabilities also determine which payment options are available.

InFlow provides SDKs for Go, Node.js, Python, and Rust, with integrations for accepting and making payments.

Choose the language your application already uses. Each SDK page explains its packages, setup, examples, and supported features. Framework integrations and advanced features differ between SDKs.

Payments let a buyer purchase a service. Two complementary protocols help agents find that service and establish access:

• ODP describes what a service offers, including prices and available actions.
• AEP lets agents enroll with a service and authenticate subsequent requests.

You can integrate payments without adding ODP or AEP. Add discovery or enrollment when your application needs those capabilities.

First, use Accounts and environments to select the appropriate account and configure Sandbox testing.