InFlow supports the following blockchain payments through MPP and x402. The protocol column identifies how the payment is made; it does not describe the networks you can use to deposit into an InFlow balance.

Use the configuration API for the current options available to your account and environment. A seller must also advertise the option on the resource being purchased; supporting a network does not mean every resource accepts it.

Payments from an InFlow balance use USDC, USDT, or PYUSD without selecting a blockchain for each purchase. Card payments use USD. The individual payment guides explain their setup; this page focuses on network and currency selection.

The currency tells the buyer what to pay, such as USD or USDC. USD and USDC are different currencies, even when their quoted values are similar. An offer for USDC does not authorize a USD card charge.

A blockchain network identifies where an on-chain payment takes place. USDC on Base and USDC on Solana are different payment options. Funds held on one network are not automatically available on the other.

An on-chain asset identifier names the token on that network: a contract address on Base or a mint address on Solana. Match the network and asset together. A familiar symbol such as USDC is not enough to identify the token.

Protocol fields reflect the selected payment method. An x402 on-chain offer uses network and asset. MPP Tempo uses a token address in currency and a chain identifier in methodDetails.chainId. Do not treat every field named currency as a currency symbol.

Use https://api.inflowpay.ai with production credentials and https://sandbox.inflowpay.ai with Sandbox credentials. Sandbox uses test networks and test funds. A production balance or token cannot fund a Sandbox purchase.

MPP Tempo uses the numeric chain identifier, 4217 or 42431, in methodDetails.chainId. The configuration API also provides the corresponding network identifier.

Load token addresses from the same environment as your application. Changing only an offer’s network identifier does not convert it into an offer for another environment. See Accounts and environments for account setup.

Use these faucets to obtain test funds for the selected network. For an InFlow account, use the deposit address shown for that network in your Sandbox dashboard; see Fund an InFlow balance. For an external-wallet test, use that wallet’s test-network address.

At Circle’s faucet, select USDC and the exact test network listed above. The links provide a starting point for testing on each supported blockchain, not a faucet for every supported currency. Test tokens have no monetary value and cannot fund production payments.

Seller configuration describes how your Seller account can receive payments. Buyer support describes the payment kinds InFlow can initiate for an authenticated buyer. Neither response is a price list, a balance check, or approval to spend.

The following read-only requests help inspect your integration. Create an API key in your Sandbox dashboard and load it into INFLOW_API_KEY from your private configuration. Run the commands in a private shell, not browser JavaScript or shared logs. They retrieve configuration without creating a payment.

curl --fail-with-body --silent --show-error \
  -H "X-API-Key: $INFLOW_API_KEY" \
  https://sandbox.inflowpay.ai/v1/mpp/config

curl --fail-with-body --silent --show-error \
  -H "X-API-Key: $INFLOW_API_KEY" \
  https://sandbox.inflowpay.ai/v1/x402/config

curl --fail-with-body --silent --show-error \
  -H "X-API-Key: $INFLOW_API_KEY" \
  https://sandbox.inflowpay.ai/v1/transactions/mpp-supported

curl --fail-with-body --silent --show-error \
  -H "X-API-Key: $INFLOW_API_KEY" \
  https://sandbox.inflowpay.ai/v1/transactions/x402-supported

Read seller configuration

• For MPP, inspect supportedMethods. Each entry identifies its method, supported currencies, intents, and methodDetails. Use the SDK’s seller builder to apply method-specific terms rather than combining every listed currency and intent yourself.
• For x402 on-chain offers, match entries in assets and wallets by network. Asset entries provide assetId, decimals, and transfer metadata. Wallet entries provide the seller’s receiving address.
• For x402 balance and instrument offers, inspect paymentMethods. These entries provide the scheme, network, recipient, and amount precision without requiring a blockchain wallet address.

The following example is an excerpt from the x402 seller configuration for Base Sepolia. It shows selected fields from one asset entry, not the entire response. Your account may include additional assets and networks.

{
  "assets": [
    {
      "assetId": "0x036cbd53842c5426634e7929541ec2318f3dcf7e",
      "currency": "USDC",
      "decimals": 6,
      "network": "eip155:84532"
    }
  ]
}

currency is the currency symbol; network identifies Base Sepolia; assetId is its USDC contract; and decimals gives the amount precision. The seller SDK also needs the receiving address from wallets and the asset’s transfer metadata from the full response.

Read buyer support

MPP’s kinds list groups methods by intent, with currencies under their applicable rails. Methods without an InFlow settlement rail can have an empty rails list; read their method-specific guide for currency and setup requirements. The x402 kinds list reports scheme/network pairs, not a list of every accepted token.

For example, the x402 buyer response can include the following kind in Sandbox. This excerpt contains one entry from the kinds list; it is not the complete response.

{
  "kinds": [
    {
      "network": "eip155:84532",
      "scheme": "exact",
      "x402Version": 2
    }
  ]
}

This entry means InFlow can initiate x402 version 2 exact payments on Base Sepolia. It does not list the token, confirm sufficient funds, or authorize a purchase.

A seller can accept payment methods that InFlow does not initiate for buyers. For example, the seller’s Stripe configuration supports payments from a compatible external buyer. It does not imply Stripe appears in the InFlow buyer support response. See Stripe payments for that flow.

The separate /v1/x402/supported endpoint describes facilitator support: payment kinds the payment-processing service can handle. It does not prove that a particular buyer SDK, external wallet, or account can fund the purchase. Finally, inspect the seller’s actual 402 response to see which options that resource offers.

An amount needs both a currency and a unit. Seller SDKs can accept a decimal price and encode it for the selected protocol. The resulting request may contain integer units rather than that decimal price.

For a token with six decimal places, 0.05 tokens becomes 50000 atomic units. Read the asset’s precision from configuration. Do not assume all tokens use six decimals, or reuse token precision for a different payment path.

InFlow’s x402 balance and instrument configuration uses 18 decimal places. A balance price of 0.05 USDC therefore becomes 50000000000000000 in its x402 offer. That is the payment format’s precision, not the precision of a USDC contract. Card payments still have their own minimum amount and whole-cent requirements.

MPP methods also have different formats. The InFlow method uses decimal currency amounts; Tempo uses token units; Stripe and CARD use USD minor units. Use the SDK builder for the chosen method, and keep large integer amounts as strings or exact integers rather than floating-point numbers.

Prices and offers explains the seller inputs and conversion rules. Choose payment options explains comparing a buyer’s spending limit with the advertised amount.

If no acceptable option remains, compare the seller’s offer with your configuration before changing the purchase. These checks identify different causes:

• Environment: Confirm the API host, account key, network, and token belong to the intended environment.
• Seller setup: Check that seller configuration includes the desired method or asset and the required recipient information. Follow the relevant payment guide to complete missing setup.
• Advertised offer: Confirm that this resource actually offers the desired currency and network. Seller capability does not mean every endpoint offers every option.
• Buyer support: Check the method or scheme, network, token, and required transfer mechanism against the buyer implementation. A supported network alone is insufficient.
• Purchase rules: Check whether your own currency restrictions, maximum price, or recipient rules excluded an otherwise supported offer.

Insufficient funds are a separate problem. A supported offer can fail because the selected balance lacks funds or the selected card cannot complete the purchase. Use the funding and approval guides to resolve those failures; adding a network to an allowlist does not add money.

Select another advertised option only if your purchase rules permit it. Do not rewrite the seller’s network, token, recipient, or amount to force a match. Follow Status and recovery if a payment has already been created and its outcome is uncertain.