Skip to main content
Complete Step 1 of the InFlow integration, Payments: take an MPP and an x402 payment on your own endpoint in the sandbox. Step 2 is Enrollment, and Step 3 is Discovery. See Integrate your service. Steps 1 to 5 need no live money and no public server.
A coding agent can do this work with you. See Integrate with a coding agent.

Before you start

This guide uses Node.js. For Python, Go, or Rust, see Protect an endpoint in Python, Go, or Rust.

Step 1: Integrate both protocols

InFlow Payments accepts MPP and x402. Integrate both, so that agents of either protocol can pay you. Both protocols accept the InFlow balance. Payments with MPP and x402 compares them. Share the pricing and fulfillment logic between the two. Each request goes through one charging path only. You can start with one protocol and add the other later.

Step 2: Register a Seller account

Register a Seller account at sandbox.inflowpay.ai. Create an API key in the dashboard. Put the key and its environment in the same .env file. The two must always change together.
.env
Never set a baseUrl. The SDK resolves the correct host from environment alone. A baseUrl sends your traffic to an unexpected host.
For account types and key safety, see Create a Seller account.

Step 3: Protect an endpoint

Follow both tabs. One server protects some endpoints with x402 and other endpoints with MPP. The code reads both values from the environment and stops at startup if one is missing.
server.ts
inflowAccepts reads a price as '$0.01', as '0.10 USDC', or as a bare '0.01' with a currency field. Stablecoin payments have no minimum amount. Card payments in USD have a minimum of USD 0.50, in whole cents.
Only the adapter import changes.
  • x402 on Hono
  • x402 on Fastify. paymentMiddlewareFromConfig changes the Fastify instance in place. It does not return a middleware. Call it as paymentMiddlewareFromConfig(app, routes, [inflow], regs).
  • x402 on Next 16. Next 16 renamed middleware.ts to proxy.ts. Use a root-level proxy.ts with paymentProxyFromConfig.
  • MPP on Express and MPP on Hono.
For schemes, multi-currency charges, and subscriptions, see Protect an endpoint.

Step 4: Confirm the challenge

Start your server. Call the paid endpoint with no payment.
A 200 on a paid endpoint means that the middleware did not run.

Step 5: Pay your own endpoint

The CLI uses production by default. Your server runs in the sandbox, so add --sandbox to the login and to each pay command. See Authenticate.
1

Install the CLI

2

Unlock the vault

Run this command yourself in a terminal. Choose a PIN or a passphrase. Never give that PIN or passphrase to an agent.
3

Log in

Open the verification URL that the CLI prints. Approve the login. Then run inflow auth status to confirm.
4

Inspect, then pay

inspect reports the capabilities of the endpoint. It pays nothing.
Pay with the command for your protocol.
--interval 5 polls every 5 seconds until the payment settles. The default of 0 returns a transaction id at once and does not block.
For buyer examples and more checks, see Test a payment.

Step 6: Go live

Production changes your .env file and nothing else. Register a production Seller account at app.inflowpay.ai. Create a key there. Change both values together.
.env
For MPP, set a production MPP_SECRET_KEY as well. Never reuse the sandbox secret. Deploy the same build that you tested. See Go live.

Step 7: Get listed in the directory

Steps 1 to 6 let an agent pay you, but not find you. Complete Step 2: Enrollment and Step 3: Discovery. Then publish to the directory. The directory has no sandbox and does not accept localhost. Point every ODP purchase action at the endpoint that you protected in step 3. The mpp-aep-seller-express example puts AEP in front of MPP. It uses x-aep-api-key for the AEP credential, which leaves Authorization: Payment free for MPP.

Troubleshooting

For other errors, such as 403 SELLER_ACCOUNT_REQUIRED and RouteConfigurationError, see Errors.
It makes authenticated calls at construction to prime its caches. Check the API key. Check that INFLOW_ENVIRONMENT matches the dashboard that issued the key.
Check the header the buyer sends. x402 uses PAYMENT-SIGNATURE. MPP uses Authorization: Payment.Then check that the buyer speaks the protocol your server implements. An MPP buyer cannot pay an x402 endpoint.
inflowAccepts could not read your price string. Catch this at startup, not per request. Step 3 lists the accepted forms.
Credential validation or broadcast failed. Read the type field of its RFC 9457 problem detail. Use the type to decide between a new challenge and a hard failure.A status of 500 means that the result is not known. Do not create a new payment. Check the payment status first.

Check your work

  • An unpaid call to your endpoint returns 402 with the correct header.
  • An unpriced endpoint still returns 200.
  • inflow inspect <your-url> reports the protocol you advertise.
  • A CLI payment returns your endpoint’s real response body.
  • The payment appears in your dashboard.
  • Your production deploy uses the same build as your sandbox deploy.

Next step

Step 2: Enable agent enrollment

Let agents enroll with your service and get credentials.

Ask in Discord

Tell the team which step failed and which error you got.
Last modified on October 15, 2026