ap2-agentic-payments/skills/ap2-human-present-flow/SKILL.md
Implement the AP2 human-present transaction flow — the checkout process where the user is actively present to confirm cart details and payment method selection. The primary VDC in this flow is the Cart Mandate. Use when building interactive agentic checkout with user in the loop.
npx skillsauth add orcaqubits/agentic-commerce-claude-plugins ap2-human-present-flowInstall 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 human-present flow specificationsite:github.com google-agentic-commerce AP2 samples human-present for reference implementationshttps://github.com/google-agentic-commerce/AP2/blob/main/samples/python/scenarios/a2a/human-present/cards/README.md for the card payment samplehttps://ap2-protocol.org/topics/core-concepts/ for flow overviewIn a human-present flow, the user is actively engaged throughout the transaction. They review products, select items, choose a payment method, and confirm the purchase — all while interacting with the Shopping Agent.
The official AP2 specification describes approximately 11 high-level steps for the human-present flow. The primary VDC in this flow is the Cart Mandate.
Phase 1: Shopping Intent
1. User → Shopping Agent: Provides shopping prompt ("I want to buy a coffee maker")
2. SA → User: Confirms intent and collects CP preference + shipping address
Phase 2: Product Discovery
3. SA → CP: Queries Credentials Provider for available payment methods
4. SA → Merchant: Presents shopping intent
5. Merchant → SA: Creates and signs Cart Mandate(s) with product offers
Phase 3: User Confirmation
6. SA → User: Displays final cart + payment options
7. User → SA: Reviews cart, selects payment method, confirms on trusted device surface
Phase 4: Payment Processing
8. SA → Merchant: Sends confirmed Cart Mandate + user attestation
9. Merchant → MPP: Submits payment for processing
10. MPP: Constructs Payment Mandate and requests credentials from CP
Phase 5: Completion
11. MPP → Merchant → SA → User: Payment processed, receipt delivered
Each step involves A2A protocol communication:
The user is involved at these critical points:
Step 7 is a load-bearing security step:
During the flow, any participant may trigger a challenge:
Fetch the specification and sample implementations for exact message formats, mandate structures at each step, and agent communication patterns 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.