Draft Spec · Alpha SDKs Open Standard

Delegated Payments Protocol

The open standard for delegated AI financial actions.

DPP lets users delegate bounded payment authority to AI agents via signed capability tokens and explicit consent without giving agents raw card numbers, UPI PINs, or wallet passwords. When a payment rail requires OTP or strong authentication, agents pause and escalate; the protocol orchestrates human completion rather than bypassing it.

Explore the spec Run local sandbox Report vulnerability
Open standard
Security by default
No raw credentials to agents

Foundation

Core Principles

Six non-negotiable guarantees built into the protocol.

No raw credentials

Delegation uses capability tokens and scoped permissions, not stored card numbers, UPI PINs, or API secrets.

Security by default

Least privilege, explicit scopes, replay protection, and cryptographic identity are baseline—not optional.

Graceful degradation

When a payment rail requires OTP or user approval, agents pause and escalate. DPP orchestrates around human steps, never bypasses them.

Merchant verifiability

Merchants independently verify that an agent is authorized for a specific payment intent before accepting funds.

Auditability

Every delegated action produces a traceable, attributable record for users, merchants, and regulators.

Open ecosystem

An open standard with reference schemas and SDKs. No proprietary lock-in, no single-vendor dependency.

Audience

Who It's For

Users

Maintain full control over payment authority. Set spending bounds, approve linking, complete OTP challenges on your own channel. Agents act within exactly what you authorize—nothing more.

  • Explicit consent via OAuth UI
  • Capability-bounded authority
  • Revocable at any time

Agent Platforms

Integrate DPP via MCP tools or platform adapters (Claude, Gemini, OpenAI Actions). Store OAuth tokens in an agent vault—never in LLM context. Handle escalation handles for step-up flows.

  • MCP stdio server (reference)
  • Gemini function-calling adapter
  • OpenAI Actions adapter

Merchants

Verify JWS capability tokens and payment intents via dpp-merchant-sdk before charging any PSP. Consult /.well-known/jwks.json + issuer allowlist for trustless verification.

  • Stripe & Razorpay test support
  • JWS intent verification
  • Allowlist-based trust model

Architecture

Money Flow

How payment authority travels from user consent to PSP settlement—and back when escalation is needed.

Critical boundary: The LLM never calls the wallet. Only the MCP/agent platform HTTPS client holds OAuth tokens and capability JWS. wallet-oauth-linking.md §2 ↗

Local sandbox architecture

MCP payment tool (stdio)
      │
      ├──→ wallet-issuer :3350   (OAuth + delegation issuance)
      │
      └──→ express-merchant :3340 (payment verification + PSP)

Scenarios

Use Cases

Real scenarios grounded in the reference implementations.

Local Sandbox MCP · wallet-issuer · express-merchant

Claude/Cursor agent pays a demo merchant

User links wallet via MCP link_wallet (OAuth PKCE). Agent calls preview_payment → confirm_payment → get_payment_status. Full end-to-end flow on a local three-service stack.

User Agent (MCP) Merchant :3340
local-sandbox.md ↗
Delegation Bounds capability-token · payment-intent

Subscription refill within user-approved ceiling

User grants delegation with amount and merchant constraints. Agent issues a payment intent bound to the capability. Merchant verifies JWS + intent digest before PSP charge—no charge outside the bound is possible.

User (grants ceiling) Agent Merchant (JWS verify)
payment-intents.md ↗
Step-Up Auth OTP · escalation-handle · Razorpay

Card checkout requiring OTP — step-up, not bypass

Merchant returns requiresUserAction and an escalation handle. User completes OTP on wallet/issuer channel only. Agent polls get_payment_status—never sees the OTP. Protocol enforces isolation.

User (OTP on wallet UI) Agent (polls only) Razorpay
verification-flows.md ↗
Class B Rail UPI · per-transaction PIN

UPI payment with per-transaction PIN

Same escalation pattern as card OTP. UPI PIN challenge is returned via escalation handle; user completes on wallet UI. Agents must not—and cannot—collect PIN in the chat interface per protocol rules.

User (PIN on wallet UI) Agent (polls status) UPI rail
upi.md ↗
Platform Adapter Gemini · function-calling

Gemini function-calling checkout

Gemini model invokes DPP tools via the platform adapter. User still completes wallet link and rail challenges outside the model context. DPP's consent model is not adapter-specific—it works across Claude, Gemini, and OpenAI Actions.

User (links wallet) Gemini model DPP adapter
gemini adapter ↗

Protocol

How Linking Works

From agent registration to authorized payment—step by step.

Agent platform (MCP)

Register OAuth client

One-time POST /v1/agents registers an OAuth client and agentSub (DID). Demo uses pre-registered client from wallet /health.

wallet-oauth-linking.md §5 ↗
User

Sign into wallet demo

GET /login establishes a user session cookie on the wallet only. No credentials leave the wallet service.

wallet-issuer ↗
User + Browser

OAuth authorization + consent

MCP link_wallet opens GET /oauth/authorize (PKCE S256). User sees consent UI and approves or denies via POST /oauth/consent.

wallet-oauth-linking.md §6–8 ↗
MCP Server

Token exchange — stored in vault

Callback to http://127.0.0.1:8765/oauth/callback. POST /oauth/token exchanges code. Tokens stored in agent vault—never in LLM context.

mcp-payment-tool ↗
User (ongoing)

OAuth token authorizes wallet APIs only

The access token authorizes POST /v1/delegations/issue only—not merchant charges alone. Delegation is still bounded by user-approved constraints.

mcp-http-surface.md ↗
Merchant

Trust wallet via JWKS

Merchant fetches GET /.well-known/jwks.json and validates issuer against allowlist (DPP_TRUST_JWKS_URI, DPP_TRUST_ISSUER). Trustless cryptographic verification.

express-merchant ↗
Wallet → Merchant (sensitive routes)

Operator auth for card context + OTP submission

Card-context and OTP submission use a shared Bearer DPP_WALLET_OPERATOR_TOKEN on private path (v0.1). Capability JWS still gates delegation on payment body. Production requires ≥32-char secret.

wallet-operator-auth-f02.md ↗

Developer surface

MCP Tool Surface

Four tools. One stdio server. Full payment lifecycle.

Tool Purpose Charges?
link_wallet OAuth PKCE link — opens browser consent flow No
preview_payment Intent + digest preview — no charge issued No
confirm_payment Issue capability + charge merchant via wallet delegation Yes
get_payment_status Poll PSP status — handles pending_user_action escalation No
mcp-payment-tool · stdio 
// 1. Link wallet (OAuth PKCE — opens browser)
link_wallet({ walletUrl: "http://localhost:3350" })

// 2. Preview intent — no charge
preview_payment({
  amount: 2500, currency: "INR",
  merchantId: "demo-merchant"
})

// 3. Confirm — issues capability JWS, charges merchant
confirm_payment({ intentId: "pi_…" })

// 4. Poll status (agent never receives OTP)
get_payment_status({ paymentId: "pay_…" })

Repository

Build with DPP

Everything in the repo, organized for implementers.

Specs & Schemas

Protocol Docs

SDKs & Packages

Security

Honest Status — v0.1 Alpha

DPP is an open-standards draft, not a production payment processor. Please read before integrating:

  • Demo servers only — wallet-issuer and express-merchant are in-memory reference servers, not production wallets or a global merchant network.
  • Draft KMS story — docs/operations/wallet-kms-signing.md is Draft; production HSM/KMS signing is not prescribed yet.
  • No LLM-native wallet APIs — forbidden by protocol design; DPP requires an out-of-band MCP/adapter layer.
  • OTP/PIN/3DS cannot be bypassed — capability claims do not skip rail authentication; this is a deliberate security property.
  • mTLS deferred — wallet↔merchant mTLS authentication is planned for v0.2; v0.1 uses operator Bearer token.