Suppose a buyer has 1 USDC available and purchases a report for 0.01 USDC. When the balance payment settles, InFlow deducts 0.01 USDC from the buyer. The buyer has 0.99 USDC remaining, assuming no other account activity. The seller receives the purchase amount less applicable fees.

The purchase transfers funds between InFlow account balances. Funding the account through a blockchain deposit is a separate operation; each balance purchase does not require another blockchain transfer.

Balances are held separately by currency. A USDC purchase uses USDC, not USD or another currency with a similar value. A linked card is also a separate payment option, not part of the available balance. Choose the payment option that matches how you intend to pay.

Fund the same account and environment that your buyer application uses. Open Sandbox Balances for Sandbox or production Balances for live payments.

• Open Balances and select Deposit.
• Choose the currency you intend to spend, then select one of the deposit networks shown for that currency.
• Check the currency, network, and deposit address on the resulting page. Transfer using that exact currency and network.
• Wait for InFlow to credit the deposit. Return to Balances and check the Available amount before requesting payment.

Use the deposit instructions displayed for your account. An address alone does not identify the correct currency or network. A transfer sent through an unsupported network is not a valid way to fund that balance.

Sandbox and production have separate accounts and balances. Selecting Sandbox in an SDK does not turn a blockchain transfer into test money. Confirm the test funding setup for the selected network before transferring funds.

A deposit that you have submitted is not yet proof of spendable funds. If Available has not increased, check the deposit’s status before starting a purchase or sending another deposit.

The seller must advertise a balance payment option. Your buyer then selects that option from the seller’s payment requirements. The two protocols use different names for payments from an InFlow balance:

These options spend from the same account balance in the selected currency. MPP and x402 do not maintain separate balances. For example, an MPP purchase reduces the USDC available for a subsequent x402 balance purchase.

MPP also uses the inflow method for the instrument rail. Check the rail as well as the method when selecting balance funding. For x402, the balance scheme differs from exact and instrument payments.

If the seller does not offer balance payments, your available funds do not create that option. Follow Choose payment options to select another supported offer or report that no acceptable option is available.

Configure your seller integration with the price, currency, and balance payment option you want to accept. Use your Seller account’s API key in the chosen environment. The Accept MPP and Accept x402 examples both demonstrate a 0.01 USDC balance purchase.

When settlement succeeds, InFlow credits your seller balance in the purchase currency, less applicable fees. For the report example, the proceeds arrive as USDC. Check the transaction record for the purchase amount and fee rather than assuming the seller receives the full advertised amount.

Advertising an offer, obtaining approval, and receiving a payment credential are earlier steps, not evidence that funds have arrived. Use the payment result to confirm settlement. Follow Deliver paid results for handler timing and delivery responsibilities.

A funded account answers whether money is available. Approval answers whether the buyer permits this purchase. Your application needs both conditions to be satisfied.

• An available balance does not bypass approval. The owner may still need to review the request, or a policy may decline it.
• An approval or spending policy does not add funds. A purchase can fail if the required currency has insufficient spendable funds.
• Funds reserved for a policy are separate from the generally available balance. Do not count those funds as available for unrelated purchases.
• An earlier balance check does not guarantee a later payment. Other purchases can spend funds before your payment settles.

See Approvals and allowances for owner decisions and Policies for automatic approval and reserved budgets. Keep payment failures distinct from requests that are still waiting for approval.

Use separate buyer and seller accounts in Sandbox, with a supported funding setup and a controlled purchase. Run these checks alongside your project’s unit and integration tests:

• Make a successful balance payment. Confirm the buyer’s debit, the seller’s credit and applicable fee, and delivery of the purchased result.
• If you support both MPP and x402, test each path. Confirm that both purchases use the intended currency and account balance.
• Test insufficient funds. Confirm that your application reports the failure without silently switching payment methods or starting repeated purchases.
• Decline a request while the buyer has enough funds. Confirm that available money does not override the owner’s decision.
• Interrupt a request and check the existing transaction before attempting another purchase. Confirm that your recovery flow does not duplicate the payment.

When a response is lost, the account balance alone does not identify which purchase succeeded. Keep the transaction reference and use Status and recovery to resolve the original payment.