For Cloudflare merchants

Accept agent traffic
without getting scraped.

AI agents will soon make purchases on your site on behalf of real customers. As a merchant, your slice is the smallest in agentic commerce — but it's still more than just verifying a signature. You confirm eligibility, set up your edge, install TAPKit, prove conformance, hand the verified request to your existing processor, and run it in production. Six phases. This page walks through all six.

The protocol (TAP) was co-developed by Cloudflare and Visa. The toolkit we ship for the merchant's slice — TAPKit — is the canonical implementation. Round-trip tested against Visa's reference.

See the six phases ↓ Open TAPKit →

TAPKit covers

RFC 9421 signature verification
Ed25519 + RSA-PSS (including Visa's salt quirk)
Nonce replay protection at Cloudflare scale
Browsing / payer tag enforcement
JWKS discovery and caching
Conformance test suite

You arrange separately

Card-network onboarding (Visa Intelligent Commerce)
Payment processor integration (Stripe, Adyen, etc.)
Bot-management rule config in your dashboard
Business logic on verified requests

Experimental release. Published as @mconroy-cf/tapkit-workers while we gather partner feedback. Expect breaking changes; not for production traffic. Send feedback to mconroy@cloudflare.com.

worker.ts The whole merchant integration

import { verifyTap, TAP_TAGS } from "@mconroy-cf/tapkit-workers";

export default {
  async fetch(request, env) {
    if (new URL(request.url).pathname === "/checkout") {
      const result = await verifyTap(request, {
        tag: TAP_TAGS.PAYER,
        nonceStore: env.NONCE_STORE,
      });
      if (!result.ok) return result.toResponse();

      // Signature verified. Process the order.
      const order = JSON.parse(result.rawBody);
      return Response.json({ status: "approved", order });
    }
    return new Response("Not found", { status: 404 });
  },
};

That's it. Everything below this line is optional context — full quick-start →

Getting Started at a Glance

TAPKit is the middle slice. Before it, you check eligibility and get your Cloudflare edge ready. After it, you process the verified request through the same payment stack you already run. Six phases, in order:

0 · Eligibility

Confirm you're on Cloudflare, your processor accepts network tokens with cryptograms, and you're enrolled (or enrolling) with Visa Intelligent Commerce. The longest-lead-time items live here — start them first.

Check the prerequisites →

1 · Edge prereqs

Site proxied through Cloudflare. WAF and Bot Management enabled. Decide which paths are agent-eligible (browse vs checkout). Optional MCP server on Workers if you want a structured agent surface.

See what to set up →

2 · Install TAPKit

Ten-line Worker middleware. KV binding for replay protection. Wrap your checkout handler. Browsing endpoints can stay log-only at first.

Jump to the snippet →

3 · Verify conformance

Run tapkit check against your staging URL. Eleven scenarios. Green-light to enforce when all pass.

See the conformance run →

4 · Process the request

Verified payer payload arrives at your origin. Read the tokenised PAN and cryptogram, hand them to your existing processor, return order confirmation in a shape the agent can consume.

See the handoff →

5 · Operate

Pipe the verdict log to Logpush, Workers Analytics Engine, or your SIEM. Wire TAPKit pass/fail into Bot Management as a positive signal. Tune thresholds.

See the operations playbook →

Phases 1–3 are quick if you're already a Cloudflare customer — install the package, bind a KV namespace, run the conformance suite. Phase 4 and the VIC enrolment in Phase 0 are the items that turn this into a multi-week rollout. See the day-by-day plan →

Today, an agent and a scraper look the same.

Both arrive as HTTP requests with a User-Agent string you can't trust and an IP that tells you nothing. You're choosing between blocking all bots (and losing real agent-driven sales) or letting them through (and getting scraped). TAP — and the TAPKit verifier at your edge — is what closes that gap.

Today (no TAP)

Incoming request. Who is it?

? User-Agent: ChatGPT-User/1.0 Trivially spoofed. Means nothing.

? Residential IP from a datacentre proxy Can't tell a real browser from a scraper farm.

✕ No way to prove user consent Is this request on behalf of a real, authenticated consumer — or mining your prices?

✕ Block everything → lose agent sales. Let it through → get scraped.

With TAPKit

Incoming request. Verified in milliseconds.

✓ Signature-Input: …keyid="visa/chatgpt-prod" RFC 9421 signature. Not spoofable.

✓ Key resolved via Visa's Agent Registry JWKS Agent is who it says it is — or the request is rejected.

✓ Intent tag enforced per endpoint agent-browser-auth on product pages, agent-payer-auth on checkout.

✓ Nonce + freshness window block replays Same signed request can't be used twice.

Phase 0 · Before you start

Are you eligible to accept agentic payments?

TAPKit verifies signed agent traffic at your edge — but accepting an agent-driven payment requires a few things that sit outside Cloudflare and outside TAPKit. Three checks. If any of these are "no", start them now, before you write any code.

1. You're on Cloudflare

This page assumes your site is already proxied through Cloudflare with at least Workers and WAF available. Bot Management is the relevant paid add-on (Enterprise plan). If you're not on Cloudflare today, the pilot programme below includes help fronting a non-Cloudflare origin with a Worker for agent routes.
2. You have a payment processor that accepts network tokens with cryptograms

The payment that arrives in an agent's payer payload is a Visa Token Service network token plus a transaction cryptogram — the same shape your processor already accepts for Apple Pay and Google Pay. Stripe, Adyen, Braintree, Worldpay, and most major acquirers support this today. If you can already accept Apple Pay, you can accept this. If you can't, talk to your processor before going further.
3. You're enrolled (or enrollable) with Visa Intelligent Commerce

VIC is Visa's agentic-commerce programme. It issues per-transaction tokens, runs the user's passkey challenge, and enforces network-level controls. Merchants accept it via their acquirer. If you're not enrolled yet, this is the longest-lead-time item in the whole rollout — start it now. Speak to your Visa account team or your acquirer; they'll coordinate sandbox credentials, Token Requestor identity, and the production go-live.

The honest version: Phases 1–5 below are work you can start today, in parallel with VIC enrolment. You can install TAPKit, pass conformance, and have your edge fully ready while you're still waiting on Visa credentials. The mock signers in the TAPKit repo let you exercise the full edge flow without real VIC sandbox access.

Phase 1 · Before TAPKit

Get your Cloudflare edge ready.

TAPKit verifies signed requests at your edge — but it can only do that once your traffic flows through the edge, your bot policy is set, and you've decided which routes are agent-eligible. Four checks, none of them TAPKit-specific. If you're already on Cloudflare, most of this is "confirm and move on".

1. Site is proxied through Cloudflare

Your origin needs to be behind Cloudflare's CDN with the orange cloud on, so requests hit a Worker before they hit your origin. Standard prerequisite — same as any other edge feature. DNS proxy status docs ↗.
2. WAF and a bot product are enabled

WAF gives you the rule engine. For acting on TAPKit's verdict (allow signed agents, block unsigned bots), you'll want a bot product — Bot Management on the Enterprise plan gives you the richest signal (per-request bot score), or Super Bot Fight Mode on Pro/Business is a lighter-weight starting point. Cloudflare bots docs ↗. Either works. Enterprise + Bot Management gives you the most precise custom-rule control.
3. Decide your agent-eligible routes

Pick which paths agents are allowed to hit. The typical split: product / search / catalogue routes accept agent-browser-auth; the /checkout route accepts only agent-payer-auth. Account, admin, and internal routes accept neither. Write this down before you install TAPKit — the route map drives the tag enforcement config.
4. Choose a rollout stance

Three reasonable starting points: shadow (verify, log, let everything through), permissive (block on obvious failures only — bad signature, expired, replayed), strict (TAP signature required on agent-eligible routes). Most merchants start shadow on day one and graduate to strict on /checkout within a week. The rollout section below is the day-by-day version of this.
Optional · An MCP server on Workers

If you want agents to interact with structured tools (searchProducts, getProduct, addToCart) instead of scraping HTML, you can publish an MCP server alongside your site. It runs as a Worker, sits behind the same TAPKit verification, and gives you a much cleaner contract with agent traffic. Browser-based agents will still hit your HTML; MCP is the extra surface for agents that prefer an API. Cloudflare Agents SDK ↗.

Phase 2 · Install TAPKit

Where TAPKit sits.

TAPKit is one Worker middleware call, at your Cloudflare edge, before any request reaches your origin. Your existing payment processor, business logic, and database don't change.

Agent

Signs every request with an RFC 9421 HTTP Message Signature. You never interact with the agent builder directly; you trust the registry they published their key to.

Edge (TAPKit)

Parses the signature, resolves the key via JWKS, checks freshness and nonce replay, enforces the intent tag. Pass or block — before the request hits your origin.

Origin

Only verified agent traffic arrives. Your existing checkout flow reads the tokenised PAN from the payer payload and hands it to your processor like any other transaction.

Processor

Nothing changes. The card transaction settles through your existing acquirer relationship — TAP is an authentication layer, not a payment rail.

Your scope — and what handles the rest.

A map of who does what. Agent commerce has many moving parts, but almost none of them are the merchant's problem.

You verify the signature

Every agent request carries an RFC 9421 signature naming a public key. You check it against a trusted registry and confirm the intent (browsing vs payer). Valid → through. Invalid → blocked.

You enforce the intent tag

Browsing endpoints accept agent-browser-auth; checkout endpoints accept agent-payer-auth. Mixing them is a subtle bypass — the tag is what tells you whether the agent is looking or buying.

You block replays

Every signature carries a nonce. You track it for the signature's 8-minute freshness window so the same signed request can't be replayed. On Cloudflare, KV is the obvious backing store.

That's the full merchant scope

One verification call, two intent variants, replay protection. No crypto library selection, no HSM, no key custody. Everything else in agentic commerce happens somewhere else.

Phase 3 · Verify conformance

tapkit check against our deployed reference merchant — the 11 scenarios TAPKit ships with. Run it live against your own staging URL →

tapkit check

Running tapkit check against https://tapkit-reference-merchant…

PASS  browsing-valid           31ms
PASS  checkout-valid           45ms
PASS  replay-rejected          62ms
PASS  expired-rejected         28ms
PASS  window-too-large         27ms
PASS  wrong-tag-on-browsing    33ms
PASS  wrong-tag-on-checkout    41ms
PASS  missing-signature        19ms
PASS  unknown-keyid            24ms
PASS  checkout-with-cro        48ms
PASS  checkout-with-apc        45ms
────────────────────────────────────────────
PASS  11 passed  (11 scenarios)

Phase 4 · After TAPKit

Process the verified request.

A request that survives TAPKit lands at your origin pre-authenticated. The shape of what arrives — and what you do with it — is the part of the merchant integration that's your business logic. Here's the handoff.

result.rawBody An example agent-payer-auth payload at your origin

{
  "intent": "purchase",
  "merchant_order_id": "ord_2026_04_25_8f2c",
  "items": [
    {
      "sku": "WH-1000XM5-BLK",
      "name": "Sony WH-1000XM5 — Black",
      "qty": 1,
      "unit_price_minor": 39900
    }
  ],
  "totals": {
    "currency": "USD",
    "subtotal_minor": 39900,
    "tax_minor": 3293,
    "shipping_minor": 0,
    "grand_total_minor": 43193
  },
  "shipping": {
    "name": "J. Doe",
    "line1": "101 Townsend St",
    "city": "San Francisco",
    "region": "CA",
    "postal": "94107",
    "country": "US"
  },
  // Visa-issued, scoped to this merchant + amount.
  "payment": {
    "network": "visa",
    "token_pan": "4111111111111234",
    "token_expiry": "12/29",
    "cryptogram": "AgAAAAAABk4DjkxQVxQAAAAA",
    "eci": "05",
    "token_requestor_id": "50110030273"
  }
}

Plus, on signed query parameters: par, email, loyalty_id — all covered by the RFC 9421 signature, all available via new URL(request.url).searchParams.

What arrives at your origin

The original signed request body, unchanged, plus TAPKit's VerifyInfo: the verified tag (browser vs payer), the keyid of the agent that signed it, the covered fields, and the freshness window. You can trust every one of those values without re-checking.

The payer payload (checkout only)

On agent-payer-auth requests, the body carries the tokenised PAN and cryptogram issued by Visa Token Service for this transaction. Consumer identifiers (PAR, email, loyalty ID) ride along as signed query parameters — covered by the signature, so they can't be tampered with in transit.

Hand off to your existing processor

Pass the tokenised PAN and cryptogram to your processor (Stripe, Adyen, your acquirer) the way you already pass any other card credential. The card transaction settles through the same rail as before — TAP is an authentication layer, not a payment rail. Most processors already accept network tokens with a cryptogram field; the only difference is that the token comes from the agent payload instead of from a wallet handshake.

Return a response the agent can read

Order confirmation should be machine-friendly: order ID, status, line items, totals, delivery estimate, and a stable schema. Agents will parse your response — make it application/json on the API path or structured data on the HTML path. This is the same thing you'd want for any partner integration.

Verified ≠ approved

TAPKit only proves the request is from a trusted agent acting in payer intent. Your processor can still decline (insufficient funds, fraud rules, velocity limits). Treat a TAPKit-pass / processor-decline like any other declined transaction — return a structured failure to the agent so it can explain the result to the user clearly.

Reconcile against signed identity

The PAR, email, and loyalty ID in the signed query params are the cleanest customer identifiers you'll ever get from a bot — cryptographically tied to the request. Use them to pre-fill guest checkout, look up an existing customer record, or reconcile loyalty points. TAPKit doesn't do any of this — but it's what makes all of it possible.

A realistic four-week rollout.

You don't enforce TAP in production on day one. Here's the shape of a cautious, conformance-backed rollout from prereqs to fully operating — the same six phases above, mapped to real days. Cloudflare merchants typically compress days 1–3 into an afternoon.

Day 0

Eligibility + prereqs check

Confirm Phase 0 (you have an acquirer that accepts network tokens, and VIC enrolment is under way) and Phase 1 (your site is proxied through Cloudflare, WAF and a bot product are on, and you've written down which routes are agent-eligible). Nothing TAPKit-specific yet.

Day 1

Install in shadow mode

npm i @mconroy-cf/tapkit-workers, bind a KV namespace, wrap your checkout handler. Call verifyTap but log-only — let every request through regardless of result. You're gathering signal.

Day 2

Run the conformance suite

Point tapkit check at your staging URL. Fix any failing scenarios. Expect 11/11. This is your green light to enforce.

Day 3

Enforce on checkout

Switch verifyTap from log-only to enforcing on /checkout first. Leave browsing endpoints permissive. Watch your logs for unexpected rejects.

Week 2

Browse + bot-management

Enable agent-browser-auth enforcement on product pages. Wire the verifier's pass/fail into your Cloudflare Bot Management rules so unverified bots get blocked while TAP traffic flows through.

Week 3

Processor end-to-end

Wire the verified payer payload into your existing processor (Stripe, Adyen, your acquirer). Run a handful of sandbox transactions through the full agent → TAPKit → origin → processor → confirmation loop. Fix the response shape until it's something an agent can confidently parse.

Week 4

Operate — observability + Bot Management tuning

Pipe the verdict log into Logpush or Workers Analytics Engine. Build the dashboard tile that matters to you: verified-agent volume, top agents by keyid, reject-reason breakdown. Tune your Bot Management custom rules now that you have real signal — TAPKit-pass becomes a strong positive, low-bot-score + no-signature becomes a strong negative.

Day 30+

Steady state — what success looks like

tapkit check passes 11 / 11 in CI on every deploy. Verified-agent traffic appears in your verdict log with a non-zero rate that climbs as agent platforms add merchants. Replay rejects and unknown-keyid alerts stay near zero. Agent checkouts land in your processor with the same decline rate as your card-not-present baseline. Your Bot Management dashboard shows a clean separation between TAPKit-pass traffic and unverified bot noise. From here, ongoing work is small: keep the package up to date and watch for new registries (Mastercard, AP2) as they stand up.

Phase 5 · Operate

Run the verifier in production.

Once TAPKit is enforcing, three things sit on the operations team's plate: send the verdict log somewhere you can query it, wire the verdict into Bot Management, and watch a handful of signals. Each one is a one-time setup; after that it runs itself.

1. Ship the verdict log

Set up a Logpush job pointing at your SIEM, R2, or a Workers Analytics Engine dataset. TAPKit's decision JSON is pre-structured — result, keyid, tag, reason, latency_ms. Field shape is stable across versions, so dashboards and alerts won't break on upgrade. Logpush quick-start ↗.

2. Wire the verdict into Bot Management

When TAPKit returns a pass, set a header on the forwarded request — say cf-tap-verified: true. In your Bot Management custom rule, allow that header through; without it, fall through to the standard bot score. Verified agents flow through unimpeded; unverified bots get the same answer they always got.

3. Watch four signals

Verified-agent rate — should climb as agent platforms add merchants. Reject-reason mix — replay spikes signal an attacker; expired-signature spikes signal clock skew. Unknown-keyid rate — alert above zero; it usually means a JWKS issue. Processor decline rate on TAPKit-pass traffic — compare against your card-not-present baseline.

What TAPKit emits, in detail

Per-request verdict log Structured JSON with result, keyid, tag, latency, reject reason. Pipe to Logpush, Workers Analytics Engine, or your SIEM.
Stable machine-readable reason codes signature_invalid, signature_expired, nonce_replay, wrong_tag, unknown_keyid, window_too_large, and a dozen more. Stable across TAPKit versions; downstream alerting can branch on them.
Nonce-store hit rate KV read counts tell you how much verified traffic you're actually getting, per-route.
Agent-traffic dashboard Verified-agent volume, top agents by keyid, intent mix (browse vs payer), reject-reason breakdown, and the four-signal trust gradient (Web Bot Auth, signed-agents list, KYA token, UA-only). Shipping soon as agent-traffic-logger — a drop-in Worker that classifies agent traffic into trust tiers and emits to Workers Analytics Engine. Source preview in the TAPKit repo.
Bot-management integration panel One-click wire-up from TAPKit verdicts into Cloudflare Bot Management rules. Today it's a manual config step.

The honest version: TAPKit is a verification library, not an analytics product. Today it gives you the decision data; you own the dashboard. We're closing that gap with agent-traffic-logger — a separate drop-in Worker that classifies agent traffic into trust tiers and emits to Workers Analytics Engine. Source is in the TAPKit repo today; one-click deploy template to follow.

example — fields from VerifyInfo

ok true

info.tag "agent-payer-auth"

info.keyid "visa/chatgpt-prod"

info.alg "ed25519"

info.keySource "jwks:mcp.visa.com"

info.created 1745500412

info.expires 1745500892

info.nonce "mz8x…f2a"

info.coveredFields [ 5 items ]

Merchant FAQ.

The specific questions that come up every time we walk a merchant engineering team through TAPKit. If yours isn't listed, open a discussion on the TAP repo ↗.

What's the latency cost of TAPKit verification?

Ed25519 verification runs in single-digit milliseconds on Workers; RSA-PSS is a touch more. JWKS lookups are cached per-key, so after the first request you're amortising close to zero network cost. In practice the TAPKit hop is comfortably inside the variance of any regular CDN edge request — not something your end users will notice. We'll publish hard numbers once we've collected enough pilot data to say them honestly.

What happens to requests that aren't signed at all?

That's a policy decision, not a TAPKit decision. The default verifyTap call returns ok: false with reason missing-signature, and you decide what to do: reject (strict TAP enforcement), pass through (during rollout), or route to your existing Bot Management rules. Browsing routes typically stay permissive for a while; checkout routes go strict first.

Visa's JWKS endpoint goes down. What happens?

TAPKit caches resolved keys per keyid and falls back to the cache when the JWKS origin is unreachable. Cache TTL tracks the endpoint's Cache-Control. In practice Visa's endpoint is highly available, and a short outage is invisible to your traffic; an extended one would eventually expire cached keys and you'd start rejecting signed requests as unknown-keyid. The mitigations are straightforward (longer cache, multiple trusted issuers) — both configurable.

How does this interact with my existing Bot Management rules?

TAPKit runs before your origin but the order relative to Bot Management is up to you. A typical configuration: Bot Management handles obvious scrapers (low bot score, no TAP signature); TAPKit handles the "claims to be an agent" traffic that needs cryptographic proof. The two are complementary — TAP signatures are a strong positive signal you can feed into a Bot Management custom rule via a response header or worker variable.

We don't run on Cloudflare Workers today. Can we use TAPKit?

The @mconroy-cf/tapkit-workers package is Workers-specific because of the KV binding and the Workers Fetch API. The underlying verification logic is pure TypeScript with Web Crypto, so porting it to Node, Deno, or a sidecar at your existing edge is feasible — and it's something we'd like to do officially. Today the fastest path for a non-Workers merchant is to put a thin Cloudflare Worker in front of your origin for the agent-facing routes. Talk to us — see the pilot section below.

Do we need to tell customers we're doing any of this?

No. TAP is a server-to-server authentication layer between the agent and your site. The consumer-facing experience happens in the agent's UI (card enrolment, passkey approval, per-transaction consent) and is unchanged from your side. If anything, verified agent traffic reduces the weird-looking bot traffic your customer-service team has to explain.

Is TAPKit officially supported by Cloudflare?

TAPKit is open-source, MIT-licensed, and written by the team at Cloudflare working on agentic commerce. Right now it's published as an experimental partner-feedback release under a personal npm scope (@mconroy-cf/tapkit-workers) so external merchants can install and try it without waiting on the formal Cloudflare release process. Expect breaking changes; it's not packaged as a product with a commercial SLA yet. Once the official Cloudflare-scoped release ships, the experimental package will deprecate and point at it. If you need formal support for a pilot, the pilot programme below is the path.

Do we need a special integration with Stripe / Adyen / our acquirer?

No. The tokenised PAN that arrives in the payer payload is a Visa Token Service network token with a transaction cryptogram — the same shape your processor already accepts for Apple Pay, Google Pay, and other tokenised wallets. You pass it through your existing card-not-present flow. The only thing that's new is the source of the token (an agent payload instead of a wallet handshake); the settlement rail downstream is unchanged. If your processor supports network tokens with a cryptogram field, you're already wired up.

What does the Bot Management config actually look like?

TAPKit gives you a pass/fail decision and a reason code per request. The simplest wiring is to set a custom header (or a Worker variable) on the verified request — say cf-tap-verified: true — and write a Bot Management custom rule that allows requests with that header through, and challenges or blocks anything with a low bot score and no header. The result: human traffic flows normally, verified agent traffic flows normally, and unverified bots that previously slipped past on a borderline bot score now get the answer right. Specifics live on developers.cloudflare.com/bots ↗.

When Mastercard Agent Pay (or AP2) ships, do we start over?

No. TAPKit's verifier is protocol-pluggable — the signature-layer plumbing (RFC 9421, JWKS, nonces) is shared; the per-scheme adapters live alongside. When a competing spec stabilises and its registry is live, you'll get a new tag option and a new default JWKS URL, not a new integration. Your handler code stays the same shape.

Could you just build it yourself? Yes. Here's what that looks like.

TAPKit is MIT-licensed — you could absolutely clone it, fork it, or reimplement from the spec. Here's what each row actually costs. We're not hiding the ball: this is why we wrote TAPKit in the first place.

What you need	Build in-house	With TAPKit
RFC 9421 parser	Structured-fields inner lists, covered-field parameters, strict spelling of `@path` (which includes query string in practice despite the RFC). 1–2 engineer-days to get subtly wrong.	Built in, fuzz-tested. Zero config.
Ed25519 + RSA-PSS verification	Pick a crypto library that runs on Workers. Figure out Visa's RSA-PSS salt length — the spec is ambiguous, Visa's reference uses `MAX_LENGTH`, JOSE says 32. Half a day of crypto tears.	Both algorithms, both salt conventions, auto-detected.
Nonce replay protection	KV store, check-early/write-late timing, cross-colo consistency window. Get it wrong and a malformed request can race and burn a real nonce. 2–3 days including tests.	`nonceStore: env.NONCE_STORE`. Done.
JWKS discovery + caching	Fetch Visa's JWKS, cache per-key, honour `Cache-Control`, refresh on unknown `keyid`, handle rollover without downtime.	Default: `mcp.visa.com/.well-known/jwks`. Multi-issuer via `jwksUrls`.
Intent tag enforcement	Route `agent-browser-auth` away from checkout, and vice versa. Missing this is a subtle auth bypass — every merchant rolling their own has to remember.	One line: `tag: TAP_TAGS.PAYER`.
Bidirectional Visa interop	Test your verifier against Visa's reference signer and your signer against their verifier, both directions, or real agent traffic won't round-trip. Multi-day setup + coordination.	Already proven. Test matrix in the repo.
Conformance suite	Write 11 test scenarios that cover the spec's corner cases. Maintain them as the spec moves.	`tapkit check` ships with 11 scenarios you can run on every deploy.
Spec evolution	When TAP v1.1 lands (and AP2, and Mastercard Agent Pay), you re-read every spec and diff your implementation.	Pluggable protocol adapters. You update the package.

Honest rule of thumb: a focused engineering team gets from zero to conformant in about 1–2 weeks, plus a third week of integration surprises. TAPKit is ten lines. Either path is valid — we just want you to price the choice accurately.

TAPKit: the code you'd otherwise write yourself.

TAPKit is an open toolkit that packages the merchant slice above as a Workers middleware. Drop it into any Cloudflare Worker and you're done — it handles parsing, crypto, replay protection, tag enforcement, and both signing algorithms that live TAP agents emit.

TAPKit landing page ↗

Live demo that runs 11 conformance scenarios against the reference merchant in the browser. Quick-start with the actual ten-line integration snippet.
Start here
Quick start →

Three steps: install the middleware, bind a KV namespace for replay protection, wrap your handler. Full code on the page.
Integration
Live conformance demo →

Point it at our reference merchant or paste your own staging URL. Streams pass/fail per scenario in real time. Proves your integration matches the spec.
Verify
TAPKit repo →

Open source. Full monorepo includes the middleware, a CLI signer you can use as a test agent, and a deployed reference merchant.
Source

External coordination, in one place.

A few relationships sit outside TAPKit and outside Cloudflare. Each is covered in earlier phases — this is the one-line recap so you don't have to scroll back.

Visa Intelligent Commerce

Sandbox credentials, Token Requestor identity, and the production go-live for accepting VIC-tokenised payments. Coordinate via your Visa account team or your acquirer. See Phase 0 →

Your payment processor

Confirm your processor accepts network tokens with a cryptogram field (Stripe, Adyen, Braintree, Worldpay, and most acquirers do today). Same integration shape as Apple Pay or Google Pay. See Phase 4 →

Multi-network registries · later

Mastercard Agent Pay, AP2, and other agentic commerce standards are emerging. TAPKit's architecture is protocol-pluggable: when a new registry stabilises, you add its JWKS URL to jwksUrls. Your handler stays the same shape.

Not on Workers today? Want a hand on rollout?

Installing TAPKit and passing conformance is self-serve and typically an afternoon's work for a Cloudflare merchant. The rest of the rollout (Phase 0 eligibility, Phase 4 processor handoff, Phase 5 observability) is where most teams want help. We're running a small early-access programme for merchants with real agent-traffic volume.

Staged rollout review, including your Bot Management setup
Help fronting a non-Workers origin with a Worker for agent routes
Direct channel to the team shipping the spec

Talk to the team → Try self-serve first Typical reply: 1–2 business days.

Ready to try it?

Open TAPKit's live demo, run the conformance suite against our reference merchant, and see your own staging site light up the same way. Takes about 30 seconds.

Open the live demo → Back to the front door

Accept agent traffic without getting scraped.