Agentic commerce

Expedition Insure supports buying insurance from inside an AI agent — not just quoting. There are five ways to take a quote to a paid policy, from “hand the human a link” to “the agent’s wallet pays, no human in the loop.”

All five start from a quote (get_instant_quote → quoteId, planId). Pick the path that matches your agent.

Path	Who pays	Best for
Hosted checkout link	The customer, on expedition.insure	Any agent. Keeps the human in the loop for payment + sign-in.
ACP checkout session	The customer’s agent wallet (Stripe SPT)	ChatGPT Instant Checkout and other ACP-compatible agents. Structured, in-chat.
MPP machine payment	The agent’s wallet (Stripe SPT)	Fully autonomous machine-to-machine purchase.
A2A + AP2 mandates	The trusted shopper agent	Cryptographically bound intent, cart, and payment authorization.
x402 USDC payment	The agent’s Base wallet	Agent-native HTTP payment with exact USDC settlement.

1. Hosted checkout link

The simplest, most universal path. The agent quotes, picks a plan, and generates a secure link; the customer reviews, signs in, and pays on the Expedition Insure site.

• MCP tool: create_checkout_link — inputs quoteId, planName (+ optional email, guestNames, agentSummary). Returns { checkoutUrl }.
• The link expires in 30 minutes. Up to 5 active checkout tokens per session.

get_instant_quote → compare_plans → create_checkout_link → (hand URL to user)

Use this when you want the carrier sign-in, payment, and consent to happen on a human-operated page.

2. ACP checkout session (ChatGPT Instant Checkout)

The Agentic Commerce Protocol (ACP) exposes structured checkout sessions so an agent can build a cart, review line items and totals, and complete payment in-chat with a Stripe Shared Payment Token (SPT). This is what powers ChatGPT Instant Checkout.

• Spec: /acp/v1/openapi.json (ACP version 2026-01-16)
• MCP tools: create_purchase_session, update_purchase_session, complete_purchase — the same flow, callable over MCP.
• Mutating requests require the API-Version header (minimum 2026-01-16). POST /checkout_sessions accepts an Idempotency-Key header for safe retries.
• Sessions expire after 1 hour. Insurance premiums are tax-exempt — tax is always 0.

Flow

1. POST /acp/v1/checkout_sessions            → create session with trip details
2. GET  /acp/v1/checkout_sessions/:id        → review line items + totals
3. POST /acp/v1/checkout_sessions/:id        → (optional) change plan or buyer
4. POST /acp/v1/checkout_sessions/:id/complete → pay with Stripe SPT → order
5. POST /acp/v1/checkout_sessions/:id/cancel → (optional) cancel

Example

# 1. Create a session
curl -X POST https://mcp.expedition.insure/acp/v1/checkout_sessions \
  -H "Content-Type: application/json" \
  -H "API-Version: 2026-01-16" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "items": [{ "id": "<planId>" }],
    "buyer": { "email": "traveler@example.com", "name": "Jordan Lee" }
  }'

# 2. Review
curl https://mcp.expedition.insure/acp/v1/checkout_sessions/<sessionId> \
  -H "API-Version: 2026-01-16"

# 3. Complete with a Stripe Shared Payment Token
curl -X POST https://mcp.expedition.insure/acp/v1/checkout_sessions/<sessionId>/complete \
  -H "Content-Type: application/json" \
  -H "API-Version: 2026-01-16" \
  -d '{ "payment": { "shared_payment_token": "spt_..." } }'

complete creates a Stripe PaymentIntent, records the payment, and returns the order. Over MCP, the same three steps are create_purchase_session → update_purchase_session → complete_purchase.

3. MPP machine payment

The Machine Payments Protocol (MPP) is the fully autonomous path — the agent’s own wallet pays, with no human checkout. It uses the standard HTTP 402 Payment Required challenge.

• MCP tool: purchase_with_mpp — inputs quoteId, planId.
• HTTP: POST https://mcp.expedition.insure/api/v1/purchase.

Flow

1. Agent calls purchase_with_mpp { quoteId, planId }
2. Server replies HTTP 402 with payment details (the challenge)
3. Agent wallet pays via Stripe SPT (card, Link, etc.)
4. Agent retries → payment is verified, PaymentIntent created + confirmed
5. Server returns { status, quoteNumber, planName, amountCharged, currency }

The first call returns the 402 challenge; an MPP-capable wallet settles it and retries automatically to finish the purchase. This is true machine-to-machine commerce — quote, compare, and pay without a human checkout step.

get_instant_quote → compare_plans → purchase_with_mpp

4. A2A + AP2 signed mandates

Discover /.well-known/agent-card.json, then send A2A JSON-RPC message/send requests to https://mcp.expedition.insure/a2a. Expedition Insure declares the AP2 merchant extension as required.

The merchant validates the shopper’s signed Intent Mandate, returns a merchant-signed Cart Mandate, then validates the shopper’s Payment Mandate against the cart, quote, plan, amount, currency, audience, expiry, and payment method. Replay claims and per-quote purchase serialization are durable. Merchant verification keys are published at /.well-known/jwks.json.

Expedition Insure AP2 v0.1 authorization profile

AP2 v0.1 does not define a verifiable Intent Mandate wire envelope, so Expedition Insure uses an explicit ES256 profile. The A2A DataPart contains ap2.mandates.IntentMandate and expedition.insure.selection (quoteId and planId); its metadata contains the compact JWS at ap2.authorization. The JWS binds iss, aud, iat, exp, jti, mandate_type, mandate_hash, message_id, and the identical selection. Merchant, SKU, and refundability constraints in the signed intent are enforced.

Payment uses user_authorization with the same base claims plus cart_hash, transaction_data, and context_id. Mandate hashes are SHA-256 over recursively key-sorted JSON; array order is retained, and non-JSON or non-finite values are rejected. Shopper issuers and public ES256 keys must be configured in the merchant trust allowlist.

5. x402 Base USDC payment

The x402 resource is POST https://mcp.expedition.insure/api/v1/x402/purchase/{quoteId}/{planId}. The selected quote and plan live in the signed resource path. An unpaid request receives HTTP 402; an x402-capable wallet authorizes exact USDC on Base mainnet and retries with PAYMENT-SIGNATURE.

After chain settlement, Stripe transaction verification records the payment and the existing fulfillment lifecycle issues the policy. The response preserves PAYMENT-RESPONSE. A settled payment that needs downstream recovery returns a receipt-preserving HTTP 503 and is durably fenced from MPP or another x402 attempt.

This route is operationally fail-closed and returns HTTP 503 until live Stripe Stablecoins/Crypto, machine payments, a Stripe Base deposit address, and Coinbase facilitator credentials are enabled.

After purchase

However the policy is paid, the customer receives confirmation and policy documents from Expedition Insure. Quote a plan’s coverage figures and policy wording verbatim when summarizing what was purchased, and keep the required disclosures in view — the agent provides information only, and the policy documents are the source of truth the customer should confirm against.