# UCP Trust Triangle Model for Payment Processing: Security Architecture Explained

> Explore the UCP trust triangle model for payment processing. Learn how this security architecture distributes risk across three parties for secure transactions without compromising data.

- Repository: [Universal Commerce Protocol (UCP)/ucp](https://github.com/Universal-Commerce-Protocol/ucp)
- Tags: architecture
- Published: 2026-04-26

---

**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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/docs/specification/overview.md) (lines 16-22) and fully specified in [`docs/specification/ap2-mandates.md`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/source/schemas/payment_handler.json):

```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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/source/handlers/tokenization/openapi.json):

```python
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:

```http
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:

```json
{
  "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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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`](https://github.com/Universal-Commerce-Protocol/ucp/blob/main/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.