What is the difference between AGIRAILS and Google AP2?

When Google ships a payments protocol, the rest of the field gets measured against it. AP2 arrived in September 2025 with sixty-plus partners and moved to the FIDO Alliance in April 2026; since then, anyone building agent payments hears the same first question: how is this different from AP2? For AGIRAILS the answer is short, because the two protocols barely touch.

AP2 proves authorization. Its mandates are cryptographically signed statements: a human approved this checkout, this payment, under these constraints. When a transaction goes wrong, that evidence lets the payments industry work out who is liable. AGIRAILS, through its protocol ACTP, enforces settlement: the contracts take custody of a buyer agent's USDC before work starts and give it back only when delivery is proven or a dispute concludes. AP2 produces evidence for institutions to act on afterward; ACTP executes the outcome itself, and if nobody disputes, nobody acts.

Both carry the label "agent payment protocols," and the label is where the mix-up starts. AP2 is an authorization layer for agent commerce on existing rails. ACTP is a settlement rail.

The definition

Google AP2 (Agent Payments Protocol) is an open specification for proving that an AI agent's purchase was authorized. A human, or their agent acting within limits the human pre-signed, issues mandates: tamper-evident verifiable digital credentials that travel with the transaction and give merchants, processors, and networks cryptographic evidence of who approved what. AP2 moves no money. Settlement happens on whatever rail the merchant already uses, from card networks to on-chain stablecoins (the latter through its x402 extension). Google published AP2 in September 2025 with 60+ partner organizations, as an extension of A2A, its agent-to-agent messaging protocol, and donated it to the FIDO Alliance in April 2026; the spec now stands at v0.2.

AGIRAILS operates ACTP, the Agent Commerce Transaction Protocol: settlement infrastructure live on Base. A buyer agent's USDC moves into contract-held escrow at commitment, the provider's delivery is attested on-chain, and the funds release when the transaction's state machine reaches settlement. The lifecycle is a fixed eight-state machine (INITIATED, QUOTED, COMMITTED, IN_PROGRESS, DELIVERED, SETTLED, with DISPUTED and CANCELLED branches), and releasing money is a validated state transition; no one decides it.

Is AGIRAILS the same as Google AP2?

No. AP2 is a specification you implement; AGIRAILS runs infrastructure you transact on. Integrating AP2 means your agents and merchant endpoints exchange signed mandates and receipts in the prescribed format while your existing processor settles the money. Integrating AGIRAILS means your agents hold USDC and the ACTP contracts on Base carry the transaction from quote to settlement. AP2 has no ledger and no vault: in its own specification's words, it "operates as a security feature within a Commerce Protocol." ACTP is the machinery and nothing else.

Neither side of the comparison below is a verdict; the two rarely sit in the same place in a stack.

What is the difference between AGIRAILS and Google AP2?

The difference is what each protocol proves: AP2 proves a human authorized a purchase, ACTP enforces the transaction itself.

Start with AP2. Its v0.2 spec defines two mandate types, the Checkout Mandate and the Payment Mandate, each existing in an open stage that captures the user's constraints and a closed stage that locks a specific, finalized transaction. (Earlier coverage says Intent, Cart, and Payment Mandates; v0.2 restructured that triad.) Mandates are SD-JWT verifiable credentials (selectively disclosable signed tokens): in human-present mode the user signs the finalized checkout on a Trusted Surface, a non-agentic UI; in human-not-present mode the user signs the open mandates that set constraints, and the agent signs the closed ones within them. AP2's protocol overview states the purpose: to "provide supporting evidence that helps payment networks establish accountability and liability principles." When something goes wrong, the mandate chain shows what the human approved, and the card ecosystem's dispute machinery takes it from there.

ACTP enforces delivery. The provider attests the work on-chain, the buyer's capital is already in the contract, and if nobody disputes, settlement executes on its own. When someone does dispute, ACTP is built to adjudicate without leaving the chain. Challengers stake a bond, so frivolous escalation costs real money; an ensemble of AI arbiters renders the first ruling; UMA, a decentralized oracle protocol, has the last word. AP2 hands its evidence to the card ecosystem's adjudicators; ACTP carries its disputes itself.

Then ask whose signature the transaction hangs on. AP2 is human-rooted: even its autonomous mode is the tail end of a human's signed intent, and its implementation guidance states that AP2 "is designed to constrain Agent behaviors without them having to be inherently trustworthy." ACTP is agent-rooted: the transacting agents are the principals, carrying their own on-chain identity and reputation under ERC-8004. In machine-to-machine service work there is often no human at either end, so there is no signature to anchor to. AP2 constrains agents so they don't need to be trusted; ACTP lets two agents that don't trust each other transact anyway.

The last split is scope. AP2 spans nearly all of agent commerce (physical goods, subscriptions, cards, bank transfers, crypto through an extension, human present or not) and manages that breadth by standardizing only the authorization evidence, deferring commerce APIs, agent identity, dispute adjudication, and settlement to other layers. ACTP covers one transaction shape, an agent paying another agent for verifiable work, and implements it end to end: escrow, delivery attestation, dispute resolution, reputation, fees, all on one rail.

Side by side

What people conflate about AGIRAILS and Google AP2

"AP2 is Google's payment rail." It is not a rail. AP2 moves no money: the merchant's processor, the networks, and the issuers settle as they do today, and the word "settlement" does not appear anywhere in the AP2 specification or documentation. Google's own documentation places AP2 as the specialized payment layer, with the Universal Commerce Protocol orchestrating the broader purchase lifecycle around it. Calling AP2 a rail makes it sound like a competitor to ACTP. The spec describes something narrower and more useful: a signature scheme for purchase authority.

"Human-not-present mode makes AP2 agent-to-agent." Human-not-present, the headline feature of v0.2, means the human signed the constraints in advance and the agent executes within them. The root of trust is still a person's credential. What AP2 does not specify is delegation between agents: its spec calls agent-to-agent mandate chains conceptually possible and leaves them out of scope. A transaction where two agents are the principals, one hiring the other with no human signature anywhere in the chain, sits outside AP2's current design. It is the transaction ACTP settles.

"x402 support puts AP2 and AGIRAILS on the same rail." In AP2's orbit, x402 is a separate extension in which a crypto payment payload rides inside a Payment Mandate: authorization wrapped around a push payment, with the merchant settling through a facilitator. On ACTP, x402 skips the vault: payment and delivery happen in one exchange, for calls too small to justify locking capital. Both stacks speak the same wire format and use it for different jobs.

Can AGIRAILS and Google AP2 work together?

Yes. Each stops where the other starts.

Picture an orchestrator agent with a human-approved budget. The human's authority arrives via AP2: signed mandates capping what the orchestrator may spend and on what. The orchestrator then subcontracts: a research agent, a data-cleaning agent, a rendering agent. Those legs are agent-to-agent service work, outside AP2's scope. Each subcontract settles through ACTP escrow, and each produces an on-chain record of delivery and payment. The human's mandate proves the spending was authorized at the top; the settlement records prove the work was delivered at the bottom.

AP2 is rail-agnostic, and ACTP is a rail; nothing in either design excludes the other.

Is AGIRAILS a Google AP2 alternative for agent-to-agent payments?

For agent-to-agent payments, AGIRAILS is the option rather than an alternative: AP2 roots every flow in a human mandate, leaves inter-agent delegation unspecified, and offers no native way for one agent to hire another as a principal. ACTP was built from that end. The agents are first-class parties, the buyer's capital is committed before work starts, and delivery, dispute, and reputation all resolve on the same rail. If your transaction is a human authorizing an agent to buy from merchants, AP2 is the standard to reach for, and AGIRAILS is not trying to be. If one agent is paying another for work and needs the outcome guaranteed, that is the ACTP lane.

When should I use AGIRAILS instead of Google AP2?

The rule of thumb: AP2 when a human is delegating purchases to an agent on existing rails; ACTP when one agent pays another for work it must be able to verify, with no human signature to root the transaction in.

Choose Google AP2 if:

• you are building shopping or purchasing agents that act for human customers at merchants
• your settlement must run on card networks and bank rails, with the issuer and processor relationships you already have
• you need authorization evidence the payments industry recognizes: signed mandates that allocate liability in an established dispute process
• your stack is already aligned with A2A and Google's agentic commerce tooling
• you want a specification with multi-stakeholder standards governance: FIDO working groups with the card networks at the table

Choose AGIRAILS if:

• your agents hire other agents, with no human signing at either end
• payment must be conditional on proof the work arrived, not recoverable after the fact
• the money should sit where no operator, ours included, holds a key while the work is in flight
• a disagreement between agents has to resolve on-chain, without a bank or network adjudicator in the loop
• the counterparty's track record should be readable on a public registry before you commit capital

Where this connects

Where the evidence-versus-enforcement thread continues: Who is accountable in a non-custodial agent payment system?

The mechanism on the ACTP side of the table: What is agent escrow?

The property that makes contract-held funds credible in the first place: What is non-custodial settlement?

A comparison at a different edge of the category, delegated-spending orchestration rather than authorization standards: AGIRAILS vs Nevermined

The whole series in one place: How does AGIRAILS compare to other agent payment systems?

The rail itself: agirails.io

The lifecycle described above has run on mainnet; the record is public: BaseScan transaction (February 21, 2026: $3.69 USDC settled end to end, no human in the loop, no gas paid by either agent).

Sources and verification

Last verified: July 2, 2026.

Primary AP2 sources used for this comparison:

• AP2 specification: mandate types and stages, Trusted Surface, dispute-verification steps, "operates as a security feature within a Commerce Protocol."
• AP2 documentation: the protocol overview (source of the "supporting evidence" objective quoted above), verifiable digital credentials, and the FAQ on AP2's place beside the Universal Commerce Protocol.
• AP2 implementation considerations: agent identification, "designed to constrain Agent behaviors without them having to be inherently trustworthy."
• google-agentic-commerce/AP2 on GitHub: v0.2.0 release (April 28, 2026), Apache 2.0 license, reference samples.
• Google Cloud AP2 announcement (September 16, 2025): launch framing and the original Intent/Cart mandate naming.
• Google's AP2 donation to the FIDO Alliance and the FIDO Alliance announcement (April 28, 2026): governance and the Payments Technical Working Group.
• a2a-x402 extension spec (v0.2): the Embedded Flow and the decoupled smart-contract escrow pattern.

AP2 gives the payments industry a signature that proves a human meant it. ACTP gives two machines a transaction that holds with no one vouching for anyone. A serious agent-commerce stack will end up carrying both.