dist/cursor/ap2-agentic-payments/skills/ap2-payment-mandate/SKILL.md
Implement the AP2 Payment Mandate — the VDC shared with payment networks and issuers to signal AI involvement and user authorization. Use when building payment authorization flows, tokenization, and network integration.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins ap2-payment-mandateInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Fetch live docs:
https://ap2-protocol.org/specification/ for the Payment Mandate schemasite:github.com google-agentic-commerce AP2 payment mandate for type definitionssite:github.com google-agentic-commerce AP2 src/ap2/types payment for Python typeshttps://ap2-protocol.org/topics/core-concepts/ for Payment Mandate conceptual detailsThe Payment Mandate is a separate VDC specifically for the payment ecosystem — shared with payment networks (Visa, Mastercard) and issuers (banks). Unlike the Cart/Intent Mandates that focus on purchase authorization, the Payment Mandate provides visibility into the agentic nature of the transaction.
The Payment Mandate serves three functions:
The Merchant Payment Processor (MPP) constructs the Payment Mandate from the transaction information after the user has authorized the purchase. The Shopping Agent does not create the Payment Mandate — it is assembled on the MPP side from the payment context.
{
"payment_mandate_contents": {
"payment_mandate_id": "pm_unique_id",
"payment_details_id": "order_id",
"payment_details_total": {
"amount": {
"currency": "USD",
"value": "29.99"
},
"refund_period": 30
},
"payment_response": {
"request_id": "order_id",
"method_name": "CARD",
"details": {
"token": "dpan_token_xyz"
},
"shipping_address": null
},
"merchant_agent": "MerchantAgentName",
"timestamp": "2025-09-01T12:00:00Z"
},
"user_authorization": "eyJhbGc..."
}
1. User authorizes purchase on trusted device surface
2. Shopping Agent sends Cart Mandate + user attestation to Merchant
3. Merchant submits payment to Merchant Payment Processor (MPP)
4. MPP constructs the Payment Mandate from the transaction context
5. MPP requests payment credentials from Credentials Provider (CP)
6. CP verifies and performs tokenization (if needed)
7. CP returns credentials to MPP
8. Network/Issuer evaluates the mandate for risk assessment
9. Payment authorized (or challenged)
The Payment Mandate includes a tokenized payment method (DPAN — Digitized Primary Account Number):
All three work together: the Cart/Intent Mandate proves the purchase is authorized; the Payment Mandate proves the payment is authorized and provides network visibility.
The refund_period field in the mandate specifies the refund window (in days). This is important for:
Fetch the specification for exact Payment Mandate fields, token formats, and network integration requirements before implementing.
development
Build with Spree's headless Next.js storefront — the official `spree/storefront` repo (Next.js 16 App Router with Server Actions and Turbopack, React 19 Server Components, Tailwind CSS 4, TypeScript 5, `@spree/sdk`, Sentry), server-only auth (httpOnly JWT cookies + publishable key), MeiliSearch faceted catalog, one-page checkout with Apple/Google Pay/Klarna/Affirm/SEPA, multi-region market routing, GA4 + JSON-LD SEO, and Vercel/Docker deployment. Use when forking or customizing the storefront, or evaluating headless adoption.
tools
Build Spree extensions as Rails engines — gem scaffolding, `bin/rails g spree:extension`, mounting routes/migrations/assets, the modern `prepend` decorator pattern (`*_decorator.rb` with `self.prepended(base)`), generators (`spree:model_decorator`, `spree:controller_decorator`), the four customization surfaces in preference order (Events > Webhooks > Dependencies > Decorators), Spree::Dependencies for swapping service objects, gem release/versioning, and the deprecated Deface engine. Use when building a reusable Spree extension or adding non-trivial customization to an app.
development
Build with Spree's event bus and Webhooks 2.0 — `Spree::Events` publication, `Spree::Subscriber` DSL with `subscribes_to` and `on`, wildcard matching, lifecycle events (`{model}.created/.updated/.deleted` via `publishes_lifecycle_events`), the canonical event catalog (order.*, payment.*, shipment.*, product.*), Webhooks 2.0 endpoints, HMAC-SHA256 signing (`X-Spree-Webhook-Signature`), exponential-backoff retries, and Sidekiq job orchestration. Use when wiring event-driven business logic, building webhook consumers, or replacing ActiveSupport callback chains.
tools
Cross-cutting Spree development patterns — the customization preference hierarchy (Events > Webhooks > Dependencies > Decorators), `Spree::Dependencies` service-object swapping, the `_decorator.rb` + `prepend` + `self.prepended` idiom, idempotent subscribers and webhook receivers, multi-store scoping discipline, prefixed IDs, calculator polymorphism (shipping/promotion/tax share the base), service-object composition with `dry-monads` or simple results, why to avoid `class_eval` reopening and Deface, and Spree-on-Rails idioms (Hotwire/Turbo Stimulus, ActiveStorage, Action Cable, Sidekiq). Use when designing the architecture of a Spree extension or solving cross-cutting concerns.