AP2: Google's Agent Payments Protocol, Reviewed From the Repository

What AP2 Is Trying to Fix in Agent Payments

The repository describes itself as code samples and demos of the Agent Payments Protocol, with the stated goal of a secure and interoperable future for AI-driven payments. The problem it points at is narrow and real: when an agent acts for a person, the merchant and the payment network need something better than a chat transcript to decide whether the purchase was authorized. AP2's answer is a set of protocol objects, defined as Pydantic models under code/sdk/python/ap2/models/ and code/sdk/python/ap2/sdk/generated/, with canonical JSON schemas in code/sdk/python/ap2/schemas/. The audience is engineers building shopping or purchasing agents, and the merchants and payment services on the other side of that transaction. It is a specification repository first. Anyone expecting a hosted service or a drop-in payment library will be reading the wrong project.

How the Protocol Objects and Scenario Layout Fit Together

The top-level layout separates three concerns. docs/ holds the specification, flows, FAQ and the MkDocs sources, so the normative description of the protocol lives there rather than in the Python code. code/sdk/ holds the SDK, with Python at code/sdk/python/ap2/. code/samples/ holds reference implementations, split by language: code/samples/python/scenarios, code/samples/go/scenarios and code/samples/android/scenarios. Each scenario carries its own README.md and a run.sh script. Most agent and server source sits in code/samples/python/src, while the Android shopping assistant lives in code/samples/android and the Go roles in code/samples/go. That structure tells you what kind of artifact this is: the models and schemas are the durable part, and the scenarios exist to show the flows end to end. The samples use Agent Development Kit and Gemini 3.1 Flash Lite Preview, but the README is explicit that the protocol does not require either. That separation matters, because it means the mandate and payment objects are not bound to Google's agent framework.

Installing the AP2 Types Package and Running a First Scenario

Prerequisites are Python 3.11 or higher and the uv package manager. The README states that a PyPI package will be published at a later time, so until then the install goes straight to the git repository. Run this from a shell:

uv pip install git+https://github.com/google-agentic-commerce/AP2.git@main

That command installs the package named ap2 from the main branch, which is where the Pydantic models and generated SDK types come from. Next, credentials. For development the README recommends a Google API key from AI Studio, set as GOOGLE_API_KEY either in your shell or in a .env file at the root of your project:

export GOOGLE_API_KEY='your_key'

For production it recommends Vertex AI instead, which needs three variables and an application-default login:

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT='your-project-id'
export GOOGLE_CLOUD_LOCATION='global'
gcloud auth application-default login

With credentials in place, run a scenario from the repository root. The README gives the human-present card payment flow as its example:

cd AP2
bash code/samples/python/scenarios/a2a/human-present/cards/run.sh

The run script installs dependencies and starts the agents. What you should see is the scenario's agents coming up and a Shopping Agent URL to open in a browser. The exact URL is documented per scenario, so read the README.md next to the run.sh you invoked.

Where AP2 Is the Wrong Tool

The repository is a demo collection, and the README says so in its first paragraph. There is no published PyPI package yet, which means every install pins to a moving branch unless you pin a commit yourself. The dependency set in pyproject.toml is pinned exactly (cryptography 46.0.5, jwcrypto 1.5.6, pydantic 2.12.5, sd-jwt 0.10.4, pytest 9.0.2), which is good for reproducibility but also means AP2 will hold those versions back in a shared environment. The samples depend on Gemini and ADK for the agent side, so a team standardized on a different model provider will be reading the protocol and rewriting the samples rather than running them. If your requirement is a settled, versioned payment integration with a vendor behind it, this is not that. If your requirement is to understand what an agent-authorized payment should look like on the wire, it is.

AP2 and A2A Are Not the Same Layer

The most useful comparison here is not against another payments product but against the transport AP2 sits on. The repository's own scenario paths place AP2 flows under an a2a directory, and the samples use Agent Development Kit for the agents themselves. A2A-style messaging answers how agents and services talk to each other. AP2 answers what must be inside that conversation for a payment to be authorized and later verified: mandates, credentials and the schemas that make them checkable. A team that has already built agent-to-agent messaging has not solved the payment authorization problem, and a team that adopts AP2 still needs a transport. Treating them as alternatives is the common mistake; the repository layout treats them as layers.

Maintenance, Licensing and Upgrade Cost

The repository is not archived. Its last push was on 2026-06-17, and the most recent release, v0.2.0, was tagged on 2026-04-28, following v0.1.0 on 2025-09-16. Two releases in roughly a year, with a version number still below 1.0, is the signal to plan for breaking changes in the models and schemas rather than assume stability. The licence is Apache-2.0, declared in both LICENSE and pyproject.toml, which permits commercial use and modification with the usual notice and patent terms. That is a permissive baseline, but it is a licence, not a legal opinion about your payment flows: the protocol governs authorization between parties, and whether your specific deployment satisfies a card network's rules is a separate question the repository does not answer.

Editorial conclusion

Adopt AP2 if you are building an agent that needs a signed, verifiable record of what a user authorized, and you are willing to read the spec in docs/ rather than wait for a stable package. Do not adopt it if you need a published PyPI release or a production payment rail, because the README states a PyPI package will be published at a later time and the scenarios are demos. Before committing, verify two things: that the mandate models under code/sdk/python/ap2/models/ cover the authorization semantics you need, and that the scenario closest to your flow (human-present cards, for example) runs with your Gemini credentials.

Frequently asked questions

Official sources

1. google-agentic-commerce/AP2 on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases