# Integrate agentic commerce into your Service

This guide coordinates the Payments, AEP, and ODP integration guides for a coding
agent working with a developer. Follow the selected guides in this same session,
one stage at a time. The developer can choose all three or a subset.

## Responsibilities and working rules

This is a routing guide, not another application assessment. Each individual
guide owns its interview, repository investigation, SDK selection, protocol
decisions, implementation plan, review, and verification. Do not duplicate those
activities here or combine the three implementation plans into one large queue.

- Follow the repository's instructions and preserve unrelated work.
- Reading a guide or replying `go` does not authorize an entire integration.
  A continuation applies only to the next stated step. Unresolved choices need
  explicit answers.
- Obtain separate authorization for state-changing checks, enrollment, payments,
  deployment, publication, commits, and pull requests. For payments, confirm the
  environment, destination, operation, and spending limits.
- Never put credentials, private keys, tokens, or personal data in a plan or chat.
- Save routing progress before every handoff, including suggestions to pause.
  The developer may leave without answering another question.
- If a guide cannot be read, report that limitation. Do not invent its process.

## 1. Introduce the choices

Begin with this introduction, preserving its plain meaning:

> We will help you fully integrate Agentic Commerce—Discover, Onboard, and Pay—
> into your Service. You can integrate all three or focus on a subset. We will
> follow a guided interview and implementation plan for each capability you choose.

Explain the practical value briefly:

- **Discover — ODP:** lets agents find and inspect what your Service offers and
  discover the Actions available for each Offering.
- **Onboard — AEP:** lets agents enroll, authenticate, and obtain supported
  credentials for ongoing access under your Service's policies.
- **Pay — InFlow Payments:** connects paid operations to MPP and x402, with a
  hosted buyer wallet and payment options configured through the payment SDK.
  The Payments guide explains the available choices for the integration.

Ask: **“Would you like to integrate all three or a subset?”** If they choose a
subset, offer Payments, AEP, and ODP as selectable capabilities. Reuse an explicit
choice already provided rather than asking again. Do not select all three on the
developer's behalf.

Say: “You can re-run this guide to add another capability or improve an existing
integration.” Do not imply that selecting only ODP requires enrollment or payments.

## 2. Confirm the route and save it

Confirm which repository and application the developer intends to integrate.
This establishes where plans belong; do not scan application code in this stage.

When building more than one of the three, recommend **Payments → AEP → ODP**,
skipping unselected capabilities. Payments establishes paid operations; AEP adds
Agent enrollment and authenticated access; ODP describes the resulting Offerings
and Actions so agents can discover them. This order reduces revisiting ODP
descriptions after the underlying behavior is implemented. It is a recommended
implementation order, not a protocol dependency or permission to weaken existing
authentication while Payments is being integrated.

Show only the selected route. Read the
[coordination template](https://directory.inflowpay.ai/integration-queue-template.md)
and create or reconcile `COMMERCE-INTEGRATION-PLAN.md` in the confirmed repository.
Preserve user notes. Record the selected and excluded capabilities, order, child
guide URLs, child-plan paths, current stage, and next action. Report any inability
to save; do not claim progress is durable when it is not.

Ask for confirmation of the route, then pause: “Next step: type `go` to begin the
[first selected capability] guide.” A different order can be agreed explicitly;
the affected individual guides must handle any resulting follow-up work.

## 3. Follow one individual guide

Load the next selected guide in this session:

| Integration     | Guide                                           | Child plan                   |
| --------------- | ----------------------------------------------- | ---------------------------- |
| InFlow Payments | https://app.inflowpay.ai/integration.md         | INFLOW-INTEGRATION-PLAN.md   |
| AEP             | https://www.aep.foundation/integration.md       | AEP-INTEGRATION-PLAN.md      |
| ODP             | https://www.offeringprotocol.org/integration.md | ODP-INTEGRATION-PLAN.md      |

Pass the confirmed repository, selected capabilities, approved order, existing
answers, previous child-plan paths, and this coordinator's path as context.
Declare that the child is running under the Directory coordinator. Each child
must still verify current source and obtain approval for its own design and plan.
Do not replay answered questions, duplicate the welcome gate, or skip unresolved
questions. Follow the child's remaining stage-by-stage pauses.

The individual guide, not this parent, determines existing capabilities and asks
what the developer wants to expose. It also verifies SDK support, payment methods,
blockchains, authentication requirements, and protocol behavior. A prior plan or
a repository name is not evidence that a capability works.

If the child suggests another selected integration, record that work for its turn
instead of opening a nested workflow. If it discovers a genuine blocker requiring
an earlier integration, save the blocker and return here to ask whether to reorder,
pause, or change scope. Do not bounce between guides. An unselected capability
remains excluded unless the developer approves adding it.

## 4. Return here between integrations

At each child's handoff, save its plan and summarize its stage, evidence, pending
checks, decisions, and next action in the coordination plan. Do not copy its whole
assessment or implementation queue.

When its implementation and applicable checks are complete, return here and offer
the next selected guide. Deployment or an explicitly deferred check may remain
pending; label that state accurately and ask before proceeding with dependent
work. “Implementation complete; deployed verification pending” is not “Complete.”

Stay in the same coding-agent session. Say which guide comes next and invite
`go` to begin it. If the developer stops, the saved plans explain where to resume.

## 5. Collect acceptance evidence

Every child plan must end with concrete exit criteria in two distinct groups:

1. **Project acceptance:** the application's required tests, coverage, static
   analysis, relevant integration and regression checks, and other agreed quality
   gates. The individual guide determines these from the project.
2. **InFlow acceptance:** checks against the running integration with InFlow CLI,
   plus Directory publication for ODP. These are additional requirements, not
   replacements for project acceptance or a reason to lower coverage thresholds.

The child generates exact commands, targets, environments, prerequisites, expected
results, and evidence. Examples include `inflow odp inspect`, `inflow aep enroll`,
and `inflow mpp pay` or `inflow x402 pay` for each selected payment protocol. These
command names are not executable test plans by themselves. Children verify syntax
and required inputs against the CLI and the running application. They obtain
authorization before state-changing checks or publication.

When multiple integrations are selected, the later child verifies its integration
with the capabilities completed earlier. For all three, the ODP plan includes an
authorized discovery → enrollment → paid Action check against the same Service.
It may refer to evidence and commands in the earlier child plans rather than
inventing a second payment or authentication test system. Keep unexecuted checks
pending and record their owner and prerequisites.

Collect the child results here without substituting another parent-level technical
assessment. Distinguish local tests, running-system checks, deployment, submission,
and actual listing. A successful submission does not prove indexing has completed.

## 6. Hand off or re-run

Report the selected capabilities, child-plan paths, acceptance results, outstanding
work, and precise next action. Mark the combined integration complete only when
its agreed exit criteria are met. A developer-approved deferral remains visible;
it does not become a passing check.

On a later run, confirm the current goal and reconcile the coordination plan if
present. Let each selected child reassess current application code. If plans are
missing, recreate them through the same guided process without assuming earlier
answers or repeating work blindly. The developer may select only one improvement,
such as raising an existing ODP integration from Minimal to Complete.