Pricing for Agents: Step-by-Step Fake‑Door & Deposit Experiments for ACP/UCP Payments

Agent-enabled payments (ACP, UCP, AP2 and related agent payment layers) let software act on a buyer’s behalf: create carts, request shared payment tokens, and complete delegated payments. That changes two things about pricing tests: the UX you validate must include agent prompts and delegation affordances, and signaling (payment widgets, deposit flows) must match the protocol’s lifecycle (create checkout → shared payment token → complete). (docs.xpay.sh)

Because agents can finish purchases autonomously, a simple link-to-checkout test is no longer enough. You must simulate or stub the agent lifecycle so visitors see the same sequence an agent would: capability discovery, intent confirmation, optional budget/limit negotiation, and delegated payment confirmation. That allows you to measure true willingness‑to‑pay in the presence of agent behaviors (routing, multipath quotes, or cross-merchant coordination). (ucp.dev)

Goal: test demand and price sensitivity before building a full ACP/UCP payment handler. Show a product/feature page where the CTA appears to allow an agent to buy or negotiate on behalf of the user (for example: “Let an Agent Buy This For You — $X per month” or “Agent‑managed purchasing, first 5 orders $Y”). Clicking the CTA should lead to a pre-order or interest form (or immediate payment stub) that captures email, use case, and willingness‑to‑pay. Use copy that matches agent affordances (delegated payment scope, refund policy, agent identity). (future-foundry.io)

Implementation notes: instead of a normal checkout, present a short “Agent intent” dialog that asks one question the agent would need (budget, allowable categories) and then shows a fake checkout confirmation page that explains this is a pre-order/interest capture and that payment is not yet taken. Important: include a clear but honest commitment signal (e.g., “We’ll email a private beta invite — reserve your spot”) and optionally offer a refundable deposit variant (see deposit test). Track conversion rate on CTA → intent dialog → form completion and segment by declared willingness‑to‑pay. (future-foundry.io)

Gated demo: use a small friction gate that simulates agent payment handshakes. After visitors sign up, show a live simulated agent that can build a cart and request permission to use a shared payment token (you can mock the token step). The goal is to observe whether users accept delegated‑payment language and whether they are willing to pay for the agent’s time/automation. Collect quantitative signals (accepts permission, proceeds to payment simulation) and qualitative feedback (why or why not). (docs.xpay.sh)

Deposit page template: when you want stronger purchase intent, ask for a small refundable deposit or activation fee that an agent will later use when it transacts. The page must make the deposit semantics explicit: scope (what agent can spend the deposit on), refund rules, and how the deposit interacts with shared payment tokens (e.g., deposit reserves budget, final settlement uses customer’s chosen PSP). Implement the deposit via your normal PSP in test mode; if ACP/UCP handlers will be used later, show the same lifecycle language (Create Checkout → SharedPaymentToken → Complete) so users experience identical consent steps. (openfort.io)

Primary metrics: conversion rate on intent CTA (fake‑door), paid deposit rate (deposit test), and demo‑to-paid conversion (gated demo). Secondary metrics: drop-off during agent consent step, support requests, and refund rate. For early experiments use Bayesian or frequentist rules with conservative thresholds to avoid false positives from small samples. (2crolabs.github.io)

Concrete decision rules (examples you can adopt): • Fake‑door preorders: if preorder conversion ≥ 3% from targeted traffic (n ≥ 500), proceed to a refundable deposit test. • Deposit test: if deposit conversion ≥ 1.5% (n ≥ 1,000) AND net refund rate < 10% in 30 days, consider a paid pilot. • Gated demo: if consent-to-deposit ratio ≥ 25% and demo → deposit conversion ≥ 10% in 60 days, proceed to a small closed beta with real ACP/UCP flows. Use sequential analysis for rapid stopping: run tests for a minimum exposure window (2 weeks or 1,000 unique visitors, whichever is larger) before evaluating. These thresholds are starting points — your product, price point, and acquisition channel may require adjustment. (2crolabs.github.io)

Don’t build a payment handler until you’ve validated intent with at least one paid, refundable signal. When you do integrate, match your experiment’s language to production flows: the same consent screens, the same budget/limit explanations, and the same refund rules. This reduces churn and customer confusion when you flip the switch to a live ACP/UCP handler. (docs.xpay.sh)

Technical checklist: mock the Create/Update/Complete checkout endpoints during testing, verify how your chosen PSP implements shared payment tokens, and log every agent consent event with a signed record (use JWKs or the protocol’s signing tools). Design your UX for agent reversibility: let users revoke delegated payment tokens and show clear activity history for agent actions. These steps shorten the path from experiment to safe production roll‑out. (openfort.io)