The seller examples expose a paid HTTP resource. An unpaid request receives a payment challenge; the matching buyer handles that challenge, obtains payment authorization, and submits a paid request. Follow the linked instructions for the example’s routes, prices, and expected output.

The Node.js MPP buyer linked above calls its payment-aware fetch function explicitly, leaving the global fetch function unchanged. Python uses asynchronous HTTP clients; Go and Rust provide command-line buyer programs. Each walkthrough includes its own setup rather than a shared command for every language.

The starting payment examples use InFlow Sandbox. Their sellers run locally, but configuration, approvals, and payment processing contact InFlow. These are not offline payment simulations.

• Read the selected example’s README before running it. Install dependencies from the documented working directory and check the runtime version required by that checkout.
• Use a Sandbox Seller account’s API key for the seller. A buyer can use a Developer or Seller account. Follow Accounts and environments to obtain the correct credentials.
• Keep buyer and seller in separate terminals with their respective credentials. Using separate accounts makes the payment between them easier to follow.
• Prepare the selected payment source and keep the Sandbox dashboard available for approval when required. An API key does not supply funds. Follow the payment method’s test setup, not a mainnet funding procedure.
• For an MPP seller, configure its private challenge-signing secret and retain it across restarts. Keep the signing secret separate from the InFlow API key.

Configuration loading differs between examples. The Node.js examples above load a .env file; the Go, Python, and Rust walkthroughs use exported environment variables. Follow the selected instructions rather than assuming the SDK reads a particular file.

A payment-aware buyer can submit a payment to its configured target. Check the URL and price before running it. To inspect an unpaid challenge, use the seller walkthrough’s inspection command instead. If a purchase ends with an uncertain result, follow Status and recovery before running it again.

Choose these examples when their extra behavior matches your application. They have different prerequisites; they are not additional steps required for every payment integration.

Other Node.js frameworks

Hono examples cover MPP and x402. For x402, there are also Fastify and Next.js examples. Use the framework example that matches your server rather than copying Express middleware into another framework.

Authentication before payment

The Node.js AEP and MPP Express example authenticates an agent before requesting payment. Its README includes the separate local AEP Platform setup. This example combines authentication with MPP, not MPP with x402. To offer either payment protocol on one route, follow Accept both protocols.

External-wallet buyers

The Node.js repository includes Ethereum-compatible wallet and Solana wallet buyers using the upstream x402 libraries. They sign with wallet keys rather than an InFlow buyer API key. Follow their test-network and funding instructions, and keep private keys out of source control. See External wallets for how these buyers relate to an InFlow seller.

Stripe and Visa CARD

The Go MPP seller, Python examples, and Rust examples explain selecting Stripe or CARD. Node.js provides a dedicated CARD seller.

Stripe needs a compatible buyer that supplies a Shared Payment Token. CARD uses a different credential; the InFlow CARD buyer needs its linked Visa card and allowance setup. Use Stripe payments or Visa CARD for those prerequisites. An unpaid challenge alone does not verify a completed card payment.

Subscriptions

The Node.js MPP Express seller and Go MPP seller include subscription routes. Read Subscriptions for buyer authorization, subsequent access, and language-specific support. A one-time charge example is not a subscription implementation.

Trusted agent verification

The Go TAP example, Python TAP example, and Rust TAP example verify agent-signed requests independently of payment. They do not require an InFlow API key. A successful request needs a signature verifiable through the configured trusted key source; an unsigned request is rejected. See Trusted agent verification before combining this with customer authentication or payments.

Read an existing payment’s status

The Rust status-reading instructions include a payment-status program. It reads the original transaction using the buyer’s Sandbox credentials without creating another purchase. Use it to inspect status and any returned buyer action, not as proof that the purchased content was delivered.

Replace the demonstration resource with your product while preserving the setup and payment flow. Keep client initialization, credential handling, payment checks, receipts, and error handling together; copying only the final handler leaves out essential steps.

• Install the published SDK packages for your own application. Repository examples can use local packages and development dependencies. Follow the Go, Node.js, Python, or Rust guide rather than copying the example’s dependency configuration unchanged.
• Keep your application’s authentication and access checks. Paying for a resource and signing in to the service are separate operations.
• Set the buyer’s allowed destinations, payment options, and spending limits. Use Choose payment options and Policies rather than treating a demonstration buyer’s selection as your application’s policy.
• Connect payment records to the purchased product and handle interrupted delivery. Follow Deliver paid results to avoid repeating an order or another irreversible action when a request is retried.

Run the relevant failure and recovery checks after adapting the example. Automated tests with scripted payment responses check code behavior, not deployed settlement. Likewise, decoding a seller’s receipt does not independently establish that funds moved.