Integrating Your Store into AI Chat with UCP: What You Need to Know

What is UCP and why should I care?

So your store is considering integrating with Universal Commerce Protocol (UCP), which is a way for AI platforms and chat services to connect to your store for inventory and sales. That’s smart—it opens up new sales channels. But before you dive in, let’s talk about what could go wrong and what you need to watch out for.

Think of UCP like giving a trusted friend access to your cash register. You want to make sure:

1. Only actual trusted friends get access
2. They can’t change the prices or steal from the drawer
3. When they handle money, they do it safely

The thing is, “trusted friends” can be compromised. A platform you trust could get hacked. Or a malicious user could try to exploit the checkout flow. Let me walk you through some real security concerns.

The Basic Setup: How UCP Works

When you integrate with UCP, you’re essentially saying: “Hey platforms, here’s my checkout API. Use it to sell my stuff.”

Here’s what happens:

1. A platform discovers you - They look at your /.well-known/ucp endpoint to see what you support (checkout, orders, payment handling, etc.)
2. You agree on capabilities - You and the platform negotiate which features you both support
3. They initiate checkout - A customer adds your product to their cart in Google Chat or some AI agent
4. You handle the payment - The platform sends you payment info (as a token, not raw card numbers), and you process it
5. You send updates - You tell the platform when the order ships, arrives, etc.

You stay in control. You’re still the merchant. The platform just facilitates the checkout.

How platforms connect to you:

UCP supports multiple protocols for platforms to communicate with you:

• REST/HTTPS - Standard HTTP API
• MCP - For LLM agents via JSON-RPC
• A2A - Agent-to-agent communication
• Embedded Checkout (ECP) - Checkout UI embedded directly in a host application

All of these use bearer token authentication and validate platform profiles. The difference is the protocol format, not the security mechanism. 

Threat 1: Checkout Flow Manipulation

The scenario: A malicious user OR a compromised platform manipulates the checkout flow and changes:

• The price (charges $5 instead of $50)
• The quantity (orders 1,000 items instead of 1)
• The shipping address (sends to their address instead of the customer’s)
• The order total or discounts

This could result in revenue loss, incorrect fulfillment, or fraud.

How UCP helps:

UCP uses a concept called binding. When a customer’s payment info is collected, it’s tied to a specific checkout session with a unique ID. That ID is embedded in the payment token. When you process the payment, you verify that the token’s checkout ID matches the current order.

It’s like a receipt that says: “This payment is for order #ABC123 only. Don’t use it for order #XYZ789.”

Here’s the flow:

1. Platform initiates a checkout session with you
2. You return a checkout object with payment handlers and configuration
3. Platform collects payment credentials from the customer via a compliant payment credential provider
4. Credentials are tokenized or encrypted, bound to the specific checkout_id
5. Platform submits the token along with the checkout ID to complete the order
6. You verify that the token’s binding matches the current checkout

What you need to do:

1. Verify binding on every payment - Check that the token’s checkout_id matches your current checkout. If a malicious platform tries to use a token from checkout A for checkout B, it should fail.
2. Set token expiration - Tokens should only be valid for 5-30 minutes. After that, they expire and can’t be reused. If a token sits around too long, an attacker has more time to exploit it.
3. Enforce single-use - Ideally, a token should only work once. After the first use, it’s invalid. This prevents attackers from reusing a valid token across multiple checkouts.
4. Validate payment handler configuration - Before accepting payment via a handler (like Google Pay), verify that the handler config matches what you advertised. A misconfigured or spoofed handler could redirect payments to an attacker’s account.
5. Verify checkout details match - When a platform submits a complete checkout request, verify that the items, prices, and totals haven’t changed since the checkout was created. A malicious platform or user could try to submit a checkout with different prices than what you approved.

Threat 2: Malicious Platforms Sending Fake Data

The scenario: A compromised or malicious platform sends fake order events (webhooks) to you, claiming orders were placed, shipped, or refunded when they weren’t. This could lead to:

• Incorrect inventory counts
• Fraudulent refunds
• Confused customer records
• Revenue loss

How UCP helps:

UCP requires platforms to cryptographically sign all webhook payloads. When you receive a webhook, you can verify the signature using the platform’s public key. If the signature is invalid, the webhook is fake.

It’s like checking a signature on a check—if it doesn’t match, you don’t cash it.

What you need to do:

• Verify signatures on every webhook - Don’t skip this step. If a malicious platform tries to send fake order events, or if an attacker intercepts and modifies a webhook, the signature will be invalid. Test with an invalid signature—it should fail.
• Only accept signatures from an allow list of supported algorithms - Define which algorithms your system supports for webhook signatures and reject any signature using a different algorithm. This prevents algorithm confusion attacks and other JWT vulnerabilities. Test with an unsupported algorithm—it should fail.
• Use the correct key to verify - Check the kid (key ID) in the signature header to find the right public key from the platform’s profile. Using the wrong key will cause verification to fail. Test with a signature from the wrong platform—it should fail.
• Reject expired signatures - Signatures should have an expiration time. Don’t accept signatures older than a reasonable threshold. Test with an expired signature—it should fail.

Threat 3: Unauthorized Operations

The scenario: A malicious platform or user tries to perform operations on your store that they shouldn’t be able to:

• Accessing checkout sessions they didn’t create
• Requesting capabilities you don’t support
• Using expired or invalid credentials
• Performing operations with someone else’s token

How UCP helps:

UCP uses two mechanisms to prevent unauthorized operations:

1. Bearer token authentication - Platforms must include a valid bearer token with every request. Invalid or expired tokens are rejected.

Note: ECP allows use of any common authentication format, not just Bearer Tokens. The same security considerations still apply though.

2. Capability negotiation - You and the platform agree on which operations are allowed. If a platform requests something you don’t support, it’s rejected.

You need to do:

1. Validate bearer tokens on every request - Verify the token is valid, not expired, and belongs to an authorized platform. Test with an invalid token—it should fail. Test with an expired token—it should fail.
2. Reject malformed tokens - If a token doesn’t match the expected format, reject it. Test with a malformed token—it should fail.
3. Use HTTPS only - Bearer tokens are only secure over HTTPS. Never accept bearer tokens over plain HTTP. This prevents token interception.
4. Validate the platform’s profile - Before processing requests, fetch and validate the platform’s profile from the URI they provide. Test by providing a malicious profile—it should be rejected or handled safely.
5. Compute the capability intersection correctly - Only allow operations that are in the intersection of your capabilities and theirs. Test by requesting an unsupported operation—it should fail.
6. Reject unsupported operations - If a platform requests something you don’t support, reject it with a clear error. Test by requesting an operation you don’t advertise—it should fail.
7. Handle version mismatches - If a platform is using a newer version of UCP than you support, handle it gracefully (usually by rejecting the request). Test by connecting with an unsupported version—it should fail.

Threat 4: Embedded Checkout Exploitation

The scenario: Imagine you embed a checkout form directly into a host application—say, a kiosk, mobile app, or website. The host app communicates with your checkout via messages. A malicious user or attacker could:

• Trigger payment without the customer pressing “confirm”
• Escape the sandbox and access sensitive data
• Inject malicious scripts
• Steal payment credentials or customer information

This could result in unauthorized charges, data theft, or fraud.

How UCP helps:

UCP’s Embedded Checkout Protocol (ECP) is designed to be sandboxed—restricted to only handling checkout, not accessing other data or triggering actions without permission. But this requires careful configuration.

What you need to do:

1. Sandbox the embedded checkout - Restrict what the embedded checkout can do. It should only handle checkout, not browse the web or access other data. Test by trying to access data outside the checkout—it should be blocked.
2. Use Content Security Policy (CSP) - Tell the browser what resources the checkout can load and what it can do. This prevents injected scripts from running. Test by trying to inject a script—it should be blocked by CSP.
3. Require host confirmation before payment - The host app should confirm before releasing payment info. No silent payments. If the embedded checkout tries to trigger payment without the host’s approval, it should fail. Test by having the embedded checkout attempt to trigger payment silently—it should fail.
4. Validate message origins - Only accept messages from trusted origins. If a message comes from an unexpected origin, reject it. Test by sending a message from an untrusted origin—it should be rejected.

Threat 5: Autonomous Agent Fraud

The scenario: An AI agent makes a purchase on behalf of a customer without proper authorization, or an attacker manipulates an autonomous purchase to:

• Charge the wrong amount
• Order to the wrong address
• Change items after authorization
• Forge proof of customer consent

How UCP helps:

UCP’s AP2 Mandates extension adds cryptographic proof of authorization. Both you and the agent sign the checkout terms, creating a tamper-proof record of what was authorized.

It’s like getting a signed contract from both parties—if anyone tries to change the terms, the signatures no longer match.

What you need to do:

1. Verify signatures using the correct algorithm - Only accept ES256, ES384, or ES512 as specified by UCP. Reject any signature using a different algorithm, including alg: "none". This prevents algorithm confusion attacks and other JWT vulnerabilities. Test with an unsupported algorithm—it should fail.
2. Reject invalid signatures - If a signature doesn’t match, reject the payment. Test with an invalid signature—it should fail.
3. Ensure the signature covers the right data - Verify that the signature covers the checkout terms and hasn’t been stripped or modified. Test by changing the checkout details after signing—verification should fail.
4. Handle key rotation gracefully - When you update your signing keys, make sure old signatures still verify for a grace period. Test with an expired key—it should fail (or succeed if within the grace period, depending on your policy).
5. Validate handler configuration - Before accepting payment via a handler used by an autonomous agent, verify that the handler config is legitimate. A misconfigured handler could redirect payments to an attacker’s account. Test with a malicious handler config—it should be rejected. 

Payment Data Handling: Know Your Model

UCP is designed so you never touch raw card numbers. Instead, you work with tokens. But there are different models, and each has different security implications and complexity for your business:

Option 1: Your payment processor (PSP) runs the tokenizer

• Your PSP handles raw card numbers and tokenization (PSP must be PCI-DSS compliant)
• You only receive tokens, never raw credentials
• Neither you nor the platform needs to be PCI-DSS compliant
• This is the lowest compliance burden for your business

Option 2: Platform encrypts for you

• Platform encrypts the card using your public key
• You decrypt it locally (you become PCI-DSS compliant)
• You manage encryption keys securely and rotate them periodically

Option 3: Platform runs the tokenizer

• Platform’s payment provider handles raw card numbers
• You call their /detokenize endpoint to get the card info when you need to charge
• You must be PCI-DSS compliant to receive card info
• Platform’s credential provider must be PCI-DSS compliant
• Only onboarded businesses can call /detokenize—verify this is enforced

Option 4: You run the tokenizer (Most Complex)

• You receive raw card numbers (you become PCI-DSS compliant, which is expensive and complex)
• You generate tokens for platforms to use
• Tokens should be single-use or short-lived to prevent reuse

Action item: Understand which model you’re using and what compliance obligations come with it. If you’re handling raw card data, PCI-DSS compliance is mandatory. If your PSP handles tokenization, you may be able to avoid PCI-DSS compliance entirely.

Your Pre-Launch Checklist

Before you go live with UCP, make sure you’ve tested:

Signature Verification

• Verify signatures on every incoming request/webhook
• Reject invalid, expired, or malformed signatures
• Reject signatures with alg: "none"
• Test with a fake signature—it should fail
• Test with an expired signature—it should fail

Binding Validation

• Verify checkout IDs match between token and payment
• Test using a token from one checkout for another—it should fail
• Test with expired tokens—they should fail
• Verify checkout details (items, prices, totals) haven’t changed

Token Expiration

• Tokens expire after the documented time (usually 5-30 minutes)
• Expired tokens are rejected
• Test with an old token—it should fail

Handler Configuration

• Validate payment handlers before accepting them
• Verify handler config matches your expectations
• Test with a fake handler—it should fail
• Test with a malicious handler config—it should fail

Capability Negotiation

• Validate platform profile before processing requests
• Compute capability intersection correctly
• Reject unsupported operations
• Handle version mismatches appropriately
• Test with unsupported capabilities—they should fail

Embedded Checkout (if used)

• Sandbox restrictions prevent escape
• CSP directives are enforced
• Host app confirms before releasing payment info
• Test silent payment attempts—they should fail
• Test sandbox escape attempts—they should fail

Autonomous Agents / AP2 Mandates (if used)

• Signatures verify correctly
• Invalid signatures are rejected
• Algorithm confusion attacks are rejected
• Test with tampered checkout—signature verification should fail
• Test with expired keys—it should fail (or succeed if within grace period)

The Bottom Line

UCP is well-designed, but it puts security responsibility on you. 

The good news: most of the security checks are straightforward. 

The bad news: if you skip them, you’re exposed to both malicious platforms and malicious users.

Have questions about your specific implementation? Before you launch, run through these scenarios with your security team and a third party such as Bureau Veritas Cybersecurity. It’ll save you headaches later.