Agentic Commerce Protocol (ACP)

OpenAI and Stripe's protocol for AI-native commerce.

What is ACP?

ACP (Agentic Commerce Protocol) is a joint initiative from OpenAI and Stripe announced in 2025 to enable AI agents to complete purchases. It focuses on the checkout flow—how agents acquire payment credentials and execute transactions.

Checkout Sessions

Structured checkout flows agents can navigate programmatically.

Payment Elements

UI components for human-in-the-loop payment confirmation.

Cart Management

Standardised cart operations (add, remove, update).

SPT (SharedPaymentToken)

Secure payment credential sharing between agents and merchants.

ACP vs Hospitality

ACP was designed for retail commerce: immediate payment, immediate fulfillment. Hospitality differs:

ACP (Retail)	Hospitality
Pay now, ship later	Deposit now, balance later
Single payment	Multiple payment events
Simple cancellation	Tiered refund policies
No "no-show" concept	No-show penalties

ACP provides the payment rails. Folio adds hospitality payment semantics.

Extending ACP for Hospitality

Payment Schedule Extension

ACP's checkout assumes single payment. We extend with a payment schedule:

{
  "acp_checkout": {
    "session_id": "cs_abc123",
    "total": { "amount": 29000, "currency": "GBP" }
  },
  "hospitality_extension": {
    "payment_schedule": [
      {
        "type": "deposit",
        "amount": { "amount": 5000, "currency": "GBP" },
        "due": "on_booking"
      },
      {
        "type": "balance",
        "amount": { "amount": 24000, "currency": "GBP" },
        "due": "14_days_before"
      }
    ]
  }
}

Cancellation Policy Extension

ACP doesn't model cancellation. We add tiered refund policies:

{
  "hospitality_extension": {
    "cancellation_policy": {
      "tiers": [
        { "days_before": 14, "refund_percent": 100 },
        { "days_before": 7, "refund_percent": 50 },
        { "days_before": 0, "refund_percent": 0 }
      ]
    }
  }
}

SPT for Hospitality

ACP's SharedPaymentToken (SPT) allows agents to store and reuse payment credentials. For hospitality, we extend SPT to support:

Deferred Charges

{
  "spt": {
    "token_id": "spt_xyz789",
    "payment_method": "pm_abc123"
  },
  "authorized_charges": [
    {
      "type": "deposit",
      "max_amount": { "amount": 5000, "currency": "GBP" },
      "execute_at": "on_creation"
    },
    {
      "type": "balance",
      "max_amount": { "amount": 24000, "currency": "GBP" },
      "valid_from": "2026-03-01"
    }
  ]
}

No-Show Authorization

{
  "authorized_charges": [
    {
      "type": "no_show",
      "max_amount": { "amount": 29000, "currency": "GBP" },
      "valid_from": "2026-03-16",
      "requires_proof": true
    }
  ]
}

SPT Hospitality Requirements

Current SPT implementations support expires_at (don't charge after this date) but hospitality requires additional constraints:

Field	Purpose	Current SPT	Hospitality Need
`expires_at`	Don't charge after	Supported	Sufficient
`valid_from`	Don't charge before	Not supported	Required
`max_amount`	Maximum chargeable	Supported	Sufficient
`condition`	Charge only if	Not supported	Required

The Gap

A hotel booking with "balance due 14 days before check-in" needs:

{
  "spt": {
    "amount": 24000,
    "currency": "gbp",
    "valid_from": "2026-03-01",
    "expires_at": "2026-03-15"
  }
}

Without valid_from, there's no way to prevent early collection of the balance payment. This matters for:

Balance payments: Should not be collected until the due date
No-show charges: Only valid after check-in time has passed
Incidental holds: Only valid during the stay window

This gap is being addressed through hospitality protocol extensions. Implementations should validate timing constraints at the application layer until SPT natively supports valid_from.

See Settlement Spec for the full hospitality payment token requirements.

Implementation Pattern

1. Agent creates booking → Venue returns ACP checkout session

2. User completes checkout → SPT stored with hospitality extensions

3. Deposit captured immediately via SPT

4. Balance captured on due date via scheduled charge

5. If cancelled → Refund calculated per policy, executed via SPT

6. If no-show → Charge executed with proof attestation

Relationship to AP2

ACP and AP2 solve similar problems differently:

Aspect	ACP	AP2
Origin	OpenAI + Stripe	Google + UCP
Focus	Checkout flow	Authorization proof
Strength	Stripe integration	Cryptographic mandates
Hospitality fit	Needs extension	Needs extension

Both need hospitality extensions. Folio provides the vocabulary; either protocol can execute it.