Skip to content

CONCEPT Cited by 1 source

Payment token over credit card sharing

Definition

The principle that raw payment details (credit card numbers, CVVs, full PANs) never reach the agent or the external provider being provisioned; instead, the orchestrator ships a scoped payment token — issued by the payment processor, redeemable only by the specified provider for the specified scope — and the provider exchanges it against the processor for settlement.

Canonicalised by the 2026-04-30 Cloudflare + Stripe launch:

"Stripe includes a payment token in the request to the Provider (Cloudflare). Raw payment details like credit card numbers aren't ever shared with the agent."

Why it matters for agents

Three compounding reasons:

  1. Agents are untrusted credential handlers. LLM agents can be prompt-injected, memory-leak context across turns, and be coaxed into logging sensitive values. Handing an agent raw card data places PCI-scope on the agent runtime and on every log sink the agent writes to.
  2. Tokens enable structurally-bounded spend. The orchestrator can bake per-token scope (provider, amount, period) into issuance, making budget caps enforceable at the payment-processor layer rather than relying on the agent to respect them.
  3. Single revocation target. Revoking the orchestrator credential revokes every outstanding agent-issued token; rotating a leaked card number does not have an equivalent clean fan-out.

How it works (2026-04-30 shape)

user's card stored at Stripe (PCI scope stays at Stripe)
                 ↓
orchestrator (Stripe Projects CLI) issues a token
  scoped to:
    provider = cloudflare
    cap      = $100/month
    period   = current month
                 ↓
agent ships token to provider on provisioning request
                 ↓
provider (Cloudflare) redeems token via Stripe for
  actual charge
                 ↓
Stripe settles against stored card, bills user on
  their Stripe account

The provider never sees the card number. The agent never sees either the card or the Stripe-held vault credential — only the scoped token.

Peer primitive: Shared Payment Token (SPT)

Stripe's prior canonicalisation of the vault-preserving payment primitive for agentic commerce is the Shared Payment Token (SPT). SPTs and the agent-provisioning payment tokens share the same architectural intent — decouple credential storage from agent control — but differ in scope:

Property SPT (agentic commerce) Agent-provisioning payment token
Scope Single checkout Provider subscription (period)
Lifetime Transaction Month (or user-set)
Caller Agent-acting-for-buyer Agent-acting-for-user
Redeemer Seller checkout API Service provider billing API
Cap intent Cart amount + window Per-provider monthly cap
Issuing standard ACP / UCP layer Stripe Projects protocol

Both are agent-initiated; both are vault-preserving; both are load-bearing for bounded agent autonomy.

What this is not

  • Not PCI-scope transfer to the provider. The provider never handles card data; PCI stays at the processor.
  • Not OAuth access-token passthrough. An OAuth token authorizes an API call; a payment token authorizes a charge. They are distinct primitives, even though both often ride the same HTTPS request.
  • Not a cryptocurrency wallet primitive. Payment tokens here are card-network-backed (via Stripe) and settled through the orchestrator. Stablecoin rails for machine payments are a parallel but distinct mechanism.

Open questions

  • Token replay at the provider. Can the provider redeem the same token twice? The protocol does not explicitly state single-use vs. cap-bounded-multi-use semantics.
  • Cross-provider leakage. If a token for provider A leaks, can it be redeemed at provider B? The scope field in the token should prevent this, but schema is bilateral at launch.
  • Refund path. Who processes a refund — orchestrator or provider? How does it interact with the spend cap headroom?
  • Token TTL vs cap period. A monthly cap implies month-long token validity; shorter TTLs + renewal would reduce leaked-token damage but aren't specified.
  • Chargeback mechanics. A user disputing a charge may cancel the card behind the token. Is the token still valid until orchestrator revocation? Stripe-side semantics aren't detailed in the launch post.

Seen in

Last updated · 433 distilled / 1,256 read