# TrustedPAI — pilot and commercial plan

Updated: 2026-08-24. This is a working commercial hypothesis, not a
forecast or a promise of revenue.

## Positioning that can be tested

TrustedPAI should not be sold as “another fraud engine” or as a payment
processor. Stripe already provides payment credentials plus risk signals
through shared payment tokens, and its agentic-commerce product remains in
private preview. AP2 v0.2 defines authorization and evidence artefacts, not
a cross-rail merchant policy and decision log. The testable wedge is:

> An independent policy, evidence, and control layer that sits before an
> agentic-payment execution flow, initially in shadow mode.

That positioning is narrower than the original ambition and more credible:
the merchant or PSP keeps its existing processor, fraud stack, and final
decision. TrustedPAI observes and recommends, producing a reasoned record
for high-risk or novel agent flows.

Primary sources used for this conclusion:

- [AP2 v0.2 specification](https://github.com/google-agentic-commerce/AP2/blob/main/docs/ap2/specification.md)
- [Stripe agentic commerce documentation](https://docs.stripe.com/agentic-commerce)
- [Stripe shared payment tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens)
- [Google A2A x402 extension](https://github.com/google-agentic-commerce/a2a-x402/blob/main/spec/v0.1/spec.md)

## Ideal first customer profile

Start with one design partner, not a bank or a high-volume marketplace:

1. A merchant platform, PSP, procurement-automation provider, or agentic
   SaaS product that is already experimenting with delegated purchases.
2. Has 1–3 engineers able to send an API call and share labelled outcomes.
3. Can run the product in **shadow mode** for 6–8 weeks: TrustedPAI never
   blocks a real payment during the pilot.
4. Has transactions where a false approval is materially painful, but not
   so regulated that SOC 2/DORA supplier requirements stop a pre-revenue
   vendor at procurement.

Avoid initially: generic ecommerce stores with no agent traffic, businesses
asking TrustedPAI to guarantee chargebacks, and regulated financial
institutions requiring production-grade vendor assurance before a pilot.

## Pilot offer

| Element | Proposed starting point |
|---|---|
| Duration | 6–8 weeks |
| Scope | One payment rail and one merchant workflow |
| Mode | Shadow; merchant retains final decision and payment execution |
| Volume | Up to 10,000 screened events |
| Support | Shared Slack/email channel and weekly 30-minute review |
| Data | Pseudonymised agent/merchant IDs; no raw payment credentials |
| Commercial model | Free only against a written learning agreement and a case-study option; otherwise €1,500–€3,000 paid pilot |
| Exit | Export/delete pilot data, retrospective report, no automatic renewal |

The free-pilot exception should be rare. A small paid pilot is a stronger
signal of demand than many enthusiastic calls, and it prevents building
custom features for non-buyers.

## Pilot metrics and go/no-go gates

Measure a baseline before comparing recommendations. Do not claim fraud
prevention without verified ground truth.

| Metric | Target / decision use |
|---|---|
| API availability and p95 decision latency | Set a baseline in week 1; no production promise before observing it |
| Coverage | ≥95% of intended eligible events are successfully normalised |
| Safe failure | 100% of malformed/unverifiable events receive a safe non-approval result |
| Review yield | Share of HOLD/REJECT decisions that a merchant reviewer calls useful; target ≥60% in a small pilot |
| Decision explainability | ≥80% of sampled decisions understandable without engineering support |
| Confirmed adverse outcome capture | Count only confirmed events tied to transaction IDs; never infer savings from unlabelled data |
| Willingness to pay | At least one signed paid continuation or clear budget owner by pilot end |

Go to a paid beta only if coverage, useful-review yield, and a budget signal
all pass. Otherwise narrow the workflow or stop rather than adding features
without evidence.

## Indicative pricing after validation

These are price tests, not market facts. Quote a price only after the target
workflow and observed volume are known.

- **Developer / early beta:** €300–€750/month, up to an agreed event limit;
  support is asynchronous and no SLA.
- **Business:** €1,500–€3,500/month plus event overage, including policy
  controls, evidence export, and monthly review.
- **Enterprise:** annual minimum starting around €25k–€60k only when the
  customer asks for security review, named support, sandbox separation,
  contractual terms, or custom integration.

This is a control-plane price, not a percentage of payment volume. A
per-transaction price can be tested later only if decision value and volume
are demonstrated.

## Roadmap to revenue or acquisition readiness

### Gate 0 — technical truth (now)

- Migrate the legacy AP2 route to AP2 v0.2 before advertising AP2 support.
- Keep ACP as the primary demonstrable integration; describe x402 and MPP
  exactly at their documented beta/partial levels.
- Finish a reproducible sandbox and automated integration suite.

### Gate 1 — one shadow pilot

- Establish a legal entity and pilot terms/DPA appropriate to the data.
- Run the scoped pilot above and publish only anonymised results with written
  customer approval.
- Turn the evidence record, policy versioning, and audit export into the
  recurring product loop.

### Gate 2 — paid design partner

- Build only the integrations requested by the partner: webhook callbacks,
  SDK, and/or a specific agent platform connector.
- Add operational basics demanded by the deal: separate sandbox, retention
  controls, incident runbook, status page, audit log.

### Gate 3 — acquisition or scalable SaaS

An acquirer will value contracted revenue, unique integration access,
repeatable onboarding, labelled decision data with lawful rights to use it,
and clean IP/security records. Code alone is unlikely to command a material
acquisition price in a market where platform providers own the payment rail.
The realistic early outcome is a small acqui-hire/asset deal or strategic
integration; material value requires at least repeatable paid usage and a
defensible data/distribution advantage.

## First outreach message

“We are testing a shadow-mode control layer for agent-initiated payments. It
does not replace your PSP or fraud tooling and it never blocks execution in
the pilot. It records protocol verification, applies a policy you control,
and returns an explainable recommendation and evidence record. Would you be
open to a 30-minute call to see whether one agentic workflow is suitable for
a six-week design-partner pilot?”