Skip to content

CONCEPT Cited by 2 sources

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

  • sources/2026-04-29-stripe-giving-agents-the-ability-to-pay — canonicalises a third instance shape of the principle at the agentic-commerce / consumer-wallet altitude. Stripe Link's wallet for agents issues a one-time- use virtual card or an SPT per approved spend, "backed by the cards and bank accounts already in your wallet. The agent never gets access to your raw payment credentials." The wallet substitutes for the agent-provisioning-altitude "orchestrator" role at a different transaction granularity. Extends the principle's coverage from agent-provisioning (2026-04-30 Cloudflare + Stripe Projects) to consumer commerce (2026-04-29 Link wallet for agents) — two distinct agent-money-movement altitudes with the same underlying principle.
  • sources/2026-04-30-cloudflare-agents-can-now-create-cloudflare-accounts-buy-domains-and-deploy — canonical instance of the principle applied to agent- initiated provider provisioning.
Last updated · 542 distilled / 1,571 read