Skip to content

AP2 Shopping Agents with a Mandate Ledger

Show who authorized an agent-led purchase, and prove it later, from stated intent to payment.

Request an intro

Shopping, merchant, and auditor agents trade signed mandates over A2A, and every step lands in a ledger nobody can edit.

What the agents do

Turns a shopper's request into signed mandates, negotiates the cart with a merchant agent, and binds payment to the agreed cart.

Built by
MongoDB Industry Solutions
Contributed by
MongoDB (Built the reference implementation and the ledger data layer)
Industry
Retail
Audience
B2C
Category
Payments & CheckoutTrust, Safety & GovernanceCommerce & Ordering
01
The problem

Why this exists

When an AI agent starts a payment for a customer, the usual assumptions of commerce stop holding. A payment system cannot confirm that the customer authorized this purchase, that the request reflects what the customer actually wanted rather than an error, or who is accountable if it goes wrong: the customer, the agent's developer, the merchant, or the issuer.

Read more

Google's Agent Payments Protocol (AP2) answers with signed, tamper-evident mandates. A protocol alone does not help a retailer, though. Someone has to store those mandates, make sure they cannot be edited, and keep the chain reconstructable for disputes and audits.

02
Outcomes

What this demonstrates

  • A full AP2 mandate chain stored as immutable records, with the agreed cart signed by both the shopping agent and the merchant agent.
  • Updates and deletes are blocked; a change of state is written as a new versioned record, never as an edit.
  • Role-based access by agent type, and idempotency keys so a network retry cannot charge the shopper twice.
Read more
  • A read-only auditor agent can verify the whole chain without touching production data.

What you would add to ship it

  • Connect a real credentials provider and payment processor in place of the sample credentials.
03
How it works

Architecture

The agents talk over the A2A protocol and follow the AP2 role model: a shopping agent that talks to the customer and signs mandates, a merchant agent that presents inventory and negotiates, a credentials provider that returns payment tokens rather than card numbers, a merchant payment processor, and a read-only auditor agent.

Read more

Between the merchant agent and the database sits the Mandate Ledger Service. Each request passes authentication by agent role, then validation, concurrency control, idempotency, and immutability checks, and schema validation in MongoDB Atlas blocks any update or delete.

Every transaction leaves a chain. The shopping agent signs an Intent Mandate. The merchant proposes a Cart Mandate, which is co-signed when the customer accepts and stored as a new version. A Payment Mandate then binds the agreed cart to a payment token, hashed to the accepted cart so the token cannot be replayed against another transaction.

All three mandate types live in one collection, alongside payment records, API keys, a 90-day audit log, and 24-hour idempotency records.

A customer talks to a shopping agent, which signs the Intent Mandate. Over the A2A protocol it works with a merchant agent, which presents inventory and proposes the Cart Mandate, and a credentials provider, which returns payment tokens rather than card numbers. The merchant agent also works with a merchant payment processor. Requests from the merchant agent pass through the Mandate Ledger Service: authentication by agent role, validation, then concurrency control, idempotency, and immutability checks. The ledger writes to one MongoDB Atlas collection holding the Intent, Cart, and Payment Mandates, payment records, API keys, a 90-day audit log, and 24-hour idempotency records, where schema validation blocks updates and deletes. A read-only auditor agent reads the collection.

A customer talks to a shopping agent, which signs the Intent Mandate. Over the A2A protocol it works with a merchant agent, which presents inventory and proposes the Cart Mandate, and a credentials provider, which returns payment tokens rather than card numbers. The merchant agent also works with a merchant payment processor. Requests from the merchant agent pass through the Mandate Ledger Service: authentication by agent role, validation, then concurrency control, idempotency, and immutability checks. The ledger writes to one MongoDB Atlas collection holding the Intent, Cart, and Payment Mandates, payment records, API keys, a 90-day audit log, and 24-hour idempotency records, where schema validation blocks updates and deletes. A read-only auditor agent reads the collection.
Open standards used
Agent-to-Agent (A2A)REST APIsJSON
Tech stack
MongoDB AtlasPythonFastAPIgRPCNext.js
Get hands-on

Resources

Blog post
Next step

Take the code

This one is published in full. Read it, run it, fork it. Nothing here is behind a conversation.

Open the repositoryRead the docs

Request an intro

MongoDB is behind this solution. Ask about keeping an auditable record of agent-led purchases, and the MACH Alliance will put you in touch with the person who can answer.

The MACH Alliance passes your details to a named contact at MongoDB who knows this work and can answer your questions. We aim to reply within 2 business days. Your details are handled under the MACH Alliance privacy policy.

Not ready to talk to anyone? MACH Insider is the Alliance mailing list. New solutions, program openings, and the research behind them, once a month.

Join MACH Insider

Everyone credited on this solution

  • MongoDBBuilt the reference implementation and the ledger data layer

Every organization named here has a page listing the rest of its work on the Hub.

Keep reading

Related solutions

Verification

Published case study

The detail on this page is drawn from a case study published by the contributor or the MACH Alliance. Any figures on this page are the ones that case study states.

What this page does not establish

  • The agents are adapted from Google's public AP2 and A2A samples rather than written from scratch.
  • The demo uses sample payment credentials, not live payment rails.
  • No retailer runs this ledger in production yet.

Where this came from

Written from MongoDB's Solutions Library page, public repository, and blog post on the mandate ledger, and the write-up MongoDB sent the MACH Alliance in October 2026.

Status: Reference prototypeAdded Oct 29, 2026A listing is an editorial decision, not a MACH Alliance certification.
Put a solution forwardBack to the Hub

Built something worth showing?

Put your agentic solution in front of the enterprise leaders who use the hub to decide what to build next. Submissions are open to MACH Alliance Members, Collaborators, or Ambassadors.

Put a solution forward