UCP Trust Triangle Model for Payment Processing: Security Architecture Explained

The UCP trust triangle model splits payment processing risk across three parties—the Business, the Platform, and the Payment Credential Provider (PCP)—ensuring that no single entity handles raw payment data while maintaining end-to-end transaction security.

The Universal Commerce Protocol (UCP) introduces a novel trust triangle model for payment processing that eliminates the need for any single party to store sensitive card data. According to the UCP specification hosted at Universal-Commerce-Protocol/ucp, this architecture creates a secure handoff between merchants, commerce platforms, and payment providers using cryptographically opaque tokens and unidirectional credential flows.

The Three Parties of the Trust Triangle

The UCP architecture explicitly defines three distinct roles that form the vertices of the trust triangle:

• Business: The merchant or service provider that ultimately receives funds and holds the direct contractual relationship with the PCP.
• Platform: The commerce interface (website, app, or agent) that facilitates the transaction without ever touching raw payment credentials or owning the funding flow.
• Payment Credential Provider (PCP): The tokenization service (e.g., Google Pay, Stripe, or bank wallets) that transforms raw PANs into opaque, chargeable tokens.

As documented in docs/specification/overview.md at line 1110, the model ensures that each participant only trusts the two edges it directly contacts, creating a "Trust-by-Design" property that minimizes PCI-DSS scope for all parties.

The Three Edges of Trust

Business ↔ Payment Credential Provider

In this edge, the Business maintains a legal contract and API credentials (merchant keys) directly with the PCP. The Business trusts the PCP to tokenize and process raw payment data on its behalf. This relationship guarantees that the Business never needs to store or handle raw Primary Account Numbers (PANs), significantly reducing compliance burden.

Platform ↔ Payment Credential Provider

The Platform interacts directly with the PCP’s tokenization API—often via an iframe, SDK, or server-to-server call—to obtain an opaque credential (token, encrypted payload, or mandate). According to the specification in docs/specification/overview.md, the Platform never owns the funds and acts strictly as a thin conduit, preserving the "no raw credentials" guarantee while presenting a seamless checkout UI.

Platform ↔ Business

After acquiring the opaque credential from the PCP, the Platform forwards it to the Business, which then completes the charge using its PCP credentials. The Business receives only a token it can safely forward to the PCP; the Platform never sees the token’s secret key, and the Business never sees the user’s raw payment data.

Core Architectural Constraints

The UCP trust triangle enforces four critical security constraints to prevent credential leakage and confusion attacks:

Unidirectional Credential Flow

Credentials move Platform → Business only. The Business must not echo the token back to the Platform. This prevents credential leakage and keeps the Platform out of the funding loop, as specified in docs/specification/overview.md at line 31.

Opaque Credentials

The token is a self-contained, cryptographically protected object (e.g., a network token or an AP2 mandate). The Platform cannot read its contents, and the Business can only present it to the PCP for charging (see docs/specification/overview.md, line 32).

Handler-ID Routing

Each credential is tagged with the handler_id that identifies which PCP’s key should be used for decryption or charging. This eliminates "key-confusion" attacks where tokens might be routed to the wrong provider (defined in docs/specification/overview.md, line 33).

AP2 Mandates Extension

For autonomous agents requiring cryptographic proof of user intent, the optional AP2-Mandates extension adds a Verifiable Digital Credential (VDC) to the token flow. Described in docs/specification/overview.md (lines 16-22) and fully specified in docs/specification/ap2-mandates.md, this extension preserves non-repudiation while maintaining the trust triangle boundaries.

Implementation Examples

Business Advertises Payment Handler (Negotiation)

During the negotiation phase, the Business advertises which PCP it supports through a structured payment handler definition. The handler definition conforms to the JSON Schema in source/schemas/payment_handler.json:

{
  "ucp": {
    "payment_handlers": {
      "com.google.pay": [
        {
          "id": "8c9202bd-63cc-4241-8d24-d57ce69ea31c",
          "version": "2026-04-01",
          "config": {
            "api_version": 2,
            "environment": "TEST",
            "merchant_info": {
              "merchant_name": "Demo Store",
              "merchant_id": "01234567890123456789"
            }
          }
        }
      ]
    }
  }
}

The Business’s checkout response lists the handler it expects the Platform to call, establishing the Business ↔ PCP edge of the triangle.

Platform Obtains Token from PCP (Acquisition)

The Platform uses the configuration provided by the Business to call the PCP’s tokenization endpoint directly. The following Python example demonstrates calling a tokenization service as defined in source/handlers/tokenization/openapi.json:

import requests, json, base64, hashlib

def tokenise_card(card_data, handler_cfg):
    # Example: call Google Pay tokenisation endpoint

    resp = requests.post(
        "https://payments.google.com/token",
        json={"card": card_data, "config": handler_cfg},
        timeout=5,
    )
    resp.raise_for_status()
    token = resp.json()["token"]          # opaque, never inspected

    return token

The Platform talks directly to the PCP using the config supplied by the Business. The returned token is opaque and will be forwarded unchanged to preserve the Platform ↔ PCP trust boundary.

Platform Completes Checkout (Completion)

The Platform forwards the opaque credential to the Business via a completion request. The Business then uses its PCP credentials to charge the token:

POST /checkout-sessions/abc123/complete HTTP/1.1
Host: merchant.example.com
Content-Type: application/json
UCP-Agent: profile="https://platform.example/.well-known/ucp"

{
  "payment": {
    "instruments": [
      {
        "id": "pm_1",
        "handler_id": "8c9202bd-63cc-4241-8d24-d57ce69ea31c",
        "type": "card",
        "credential": {
          "type": "PAYMENT_GATEWAY",
          "token": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9..."
        }
      }
    ]
  }
}

The handler_id ties the token to the correct PCP, ensuring the Business routes the charge to the appropriate provider. This completes the Platform ↔ Business edge while maintaining the unidirectional flow constraint.

AP2 Mandate for Autonomous Agents

When the AP2 Mandates extension is negotiated, the Platform adds a VDC that cryptographically proves the user’s consent:

{
  "ap2": {
    "checkout_mandate": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9..."
  }
}

This mandate is issued by the User’s wallet (acting as a PCP) and consumed by the Business, preserving the trust triangle edges while enabling agentic commerce. The main.py entry point in the reference implementation demonstrates how these extensions are negotiated alongside standard payment handlers.

Summary

• The UCP trust triangle model splits payment processing across three parties—Business, Platform, and PCP—so no single entity holds raw payment data.
• Three trust edges govern the relationships: Business↔PCP (contract and tokenization), Platform↔PCP (opaque credential acquisition), and Platform↔Business (unidirectional token forwarding).
• Unidirectional flow prevents credential leakage by ensuring tokens travel only from Platform to Business, never in reverse.
• Handler-ID routing eliminates key-confusion attacks by explicitly binding tokens to their issuing PCP.
• AP2 Mandates extend the model for autonomous agents while preserving the core security boundaries defined in docs/specification/overview.md.

Frequently Asked Questions

How does the UCP trust triangle reduce PCI-DSS compliance scope?

By ensuring that only the PCP handles raw PANs while the Platform and Business exchange only opaque tokens, the model removes cardholder data environments from the Platform and minimizes storage requirements for the Business. As specified in docs/specification/overview.md, the Business never stores raw payment data, and the Platform never possesses decryption keys.

Can the Platform charge the payment token itself?

No. The Platform receives an opaque credential that it cannot decrypt or charge. Only the Business, using its direct PCP credentials, can present the token for charging. This constraint, enforced by the unidirectional flow described at line 31 of docs/specification/overview.md, ensures the Platform remains out of the funding loop.

What prevents a Business from using tokens with the wrong Payment Credential Provider?

Each token includes a handler_id that explicitly identifies the issuing PCP. This routing mechanism, defined at line 33 of docs/specification/overview.md, ensures that Businesses route tokens to the correct provider, eliminating key-confusion attacks where a token might be maliciously or accidentally presented to the wrong endpoint.

How do AP2 Mandates fit into the trust triangle model?

AP2 Mandates add a Verifiable Digital Credential (VDC) to the standard token flow, providing cryptographic proof of user consent for autonomous transactions. According to docs/specification/ap2-mandates.md, this extension preserves the trust triangle because the mandate is issued by the User’s wallet (PCP) and consumed by the Business, maintaining the Platform as a non-custodial conduit.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}