Open your application repository in a coding agent that can read web pages and inspect and edit local files. Copy this prompt into its chat:

Read https://app.inflowpay.ai/integration.md
and follow its guided process to integrate
InFlow payments into this repository.

Begin with the introduction. Pause at each stage
and wait for my response before continuing.

You can read the integration guide first. The guide starts with an interview, so you do not need to choose packages or design the integration before starting.

InFlow provides SDKs for Go, Node.js and TypeScript, Python, and Rust. The agent checks your application’s language, framework, and required payment features before recommending an SDK.

1. Confirm your goal. Decide whether your application should accept payments, make payments, or do both. The guide recommends both MPP and x402 for broader compatibility, while letting you choose either protocol alone.
2. Review your application. The agent inspects existing routes, checkout, prices, and delivery logic for a Seller integration, or outgoing requests and spending controls for a Buyer integration. It proposes specific operations to include and asks you to confirm them.
3. Approve the plan. Review the proposed changes, unresolved decisions, and verification tasks in INFLOW-INTEGRATION-PLAN.md. The plan explains how payments will work alongside existing authentication, permissions, and checkout.
4. Build and verify. Work proceeds one approved task at a time. Each handoff explains what changed, which checks ran, what remains unresolved, and the next action.

The agent uses the integration plan template to record your answers and findings from the assessment onward. You review the implementation plan before application code changes begin.

Type go to approve the next step named by the agent, or give corrections first. During assessment, the agent updates the plan rather than changing application code or installing packages.

Payment tests need your agreement on the environment, destination, operation, and spending limit. Approving implementation is not permission to spend. Commits, pull requests, deployment, and publication also require your authorization.

Use Accounts and environments for account and Sandbox setup. Supply credentials through your application’s secure configuration; keep API keys and wallet secrets out of chat, the plan, and source code.

The plan includes your project’s tests, coverage requirements, and static analysis, plus authorized checks against a running application. These verify different things; a successful payment demonstration does not replace your project’s tests.

• For a Seller, check that unpaid requests cannot obtain the protected result and a successful payment delivers it. Test each selected protocol.
• For a Buyer, exercise the application’s own payment code against a controlled seller. A CLI demonstration alone does not test that code.

Ask the agent to distinguish local tests from checks against the deployed application. If a check cannot run, it stays pending in the plan with an explanation and a next action.

The guide instructs the agent to save decisions, findings, and pending work before each handoff. In another session, ask the agent to read INFLOW-INTEGRATION-PLAN.md and check the current repository before continuing.

Re-run the same prompt to add another protocol, another paid operation, or Buyer support to a Seller application. The agent reassesses the code and plans the changes you approve. If the earlier plan is unavailable, it starts a fresh assessment.

This guide focuses on payments. If you also want product discovery through ODP or enrollment through AEP, the Directory’s coding-agent workflow coordinates those separate guides. You can select all three integrations or a subset.

Prefer to work through the code yourself? Use the payment quickstarts below. For a broader guided integration, start with the Directory workflow.