← Back to Social Reports

Agentic Payment Protocols — Research Report

2026-02-15

Agentic Payment Protocols — Research Report

Date: 2026-02-15 Purpose: Product testing report — comparative analysis of 5 agentic payment protocols

Table of Contents

  1. Visa Trusted Agent Protocol (TAP)
  2. Google AP2 (Agent Payments Protocol)
  3. Stripe Agentic Commerce Suite
  4. x402 Protocol
  5. Skyfire
  6. Comparative Summary

1. Visa Trusted Agent Protocol (TAP)

1.1 What It Is & Architecture

Visa's Trusted Agent Protocol (TAP), launched October 14, 2025, is a foundational framework for agentic commerce that enables secure communication between AI agents and merchants during every step of a transaction. Developed in collaboration with Cloudflare and Worldpay, it provides a standardized, cryptographic method for an AI agent to prove its identity and authorization to merchants.

Architecture components:

  • TAP Agent — AI shopping agent that generates RFC 9421 compliant HTTP message signatures
  • Agent Registry — Public key registry service where Visa maintains approved agent keys and metadata
  • CDN Proxy — Intercepts and verifies agent signatures at the edge (Cloudflare integration)
  • Merchant Frontend/Backend — Standard e-commerce with TAP signature verification added

How it works:

  1. Visa onboards and vets the AI agent through its Intelligent Commerce program
  2. Agent receives a unique cryptographic key pair (registered in Agent Registry)
  3. When visiting a merchant site, agent signs HTTP requests with its private key
  4. Signature carries three payloads:
    • Agent Intent — Flag indicating trusted agent with commerce intent (buy vs. browse)
    • Consumer Recognition — Tokens, loyalty IDs, or identifiers linking agent to the human user
    • Payment Information — Optional payment data (PAR for cards on file, etc.)
  5. Merchant (or CDN Proxy) verifies signature against the Agent Registry
  6. If valid, merchant treats agent as a trusted shopper (bypasses bot detection, pre-fills checkout, etc.)

Built on the HTTP Message Signature standard (RFC 9421) and aligned with Web Bot Auth (IETF working group). Designed for minimal UX changes on merchant side.

1.2 Onboarding Process

  • Agents must be approved by Visa through their Intelligent Commerce vetting program
  • Each agent gets a unique cryptographic key pair registered in Visa's Agent Registry
  • Merchants integrate TAP verification (no-code for basic use via Cloudflare CDN proxy)
  • Sample implementation available on GitHub with 5 components (Agent, Registry, CDN Proxy, Frontend, Backend)
  • Available on Visa Developer Center

1.3 Identity Model

  • Cryptographic key pairs — Each approved agent gets a unique private/public key pair
  • RFC 9421 HTTP Message Signatures — Agent signs every request, including timestamps, session IDs, key identifiers, and algorithm identifiers
  • Context-bound security — Signatures are cryptographically locked to a specific merchant domain and page
  • Replay attack protection — Time-sensitive, single-use signature elements
  • Payment Account Reference (PAR) — Can carry Visa card-on-file identifiers
  • Consumer identifiers — Loyalty numbers, emails, phone numbers (with consumer consent)
  • Aligning with IETF, OpenID Foundation, and EMVCo standards

1.4 What the Agent Can DO

  • Browse merchant websites as a recognized trusted agent (not blocked by bot detection)
  • Search and compare products across merchants
  • Carry payment credentials to streamline checkout
  • Pre-fill checkout forms with trusted consumer data
  • Complete purchases on behalf of consumers (guest or logged-in checkout)
  • Pass loyalty/account data for personalized pricing and experience

1.5 Financial Controls

  • Visa vets and approves each agent before it gets keys (gatekeeper model)
  • Signature includes explicit intent (browsing vs. purchasing)
  • Consumer must consent to sharing identifiers
  • Merchants retain full control over which agents to trust
  • Audit trail via cryptographic signatures with timestamps
  • Interoperability planned with other protocols for additional controls
  • Working with Agentic Commerce Protocol and x402 for cross-protocol alignment

1.6 Supported Payment Rails

  • Visa card network (primary — credit, debit)
  • Carries Payment Account References (PAR) for cards on file
  • Protocol is payment-method agnostic in design but initial specs apply to Visa network
  • Collaborating with Coinbase on x402 interoperability for crypto/stablecoin support
  • Partners include: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, Worldpay

1.7 Pricing / Fees

  • Not publicly disclosed for the protocol itself
  • Standard Visa interchange and processing fees apply to transactions
  • Protocol is positioned as free infrastructure (like a standard) — merchants and agents adopt it
  • Cloudflare CDN integration may have associated costs

1.8 Current Status

  • ✅ Production — Available since October 14, 2025
  • Open source on GitHub
  • Available on Visa Developer Center
  • Asia Pacific pilot planned for 2026
  • Active partnerships with 15+ major payment/tech companies

1.9 SDK / API Docs

1.10 Advantages & Disadvantages

Advantages:

  • Backed by Visa — massive merchant trust and network effects
  • Solves the critical bot-vs-agent identification problem
  • Minimal merchant integration (no-code path via Cloudflare)
  • Uses established HTTP standards (RFC 9421)
  • Open source with working sample code
  • Strong partner ecosystem (Shopify, Stripe, Microsoft, etc.)
  • Aligning with IETF/EMVCo standards for interoperability

Disadvantages:

  • Visa-centric — initial specs only for Visa network
  • Gatekeeper model — Visa controls who gets approved (centralized trust)
  • Doesn't handle the payment itself — it's an identity/trust layer, not a payment rail
  • Requires Visa approval to become a trusted agent (barrier to entry)
  • Currently no crypto/stablecoin support (only through future x402 interop)
  • Still early — limited real-world merchant adoption data

2. Google AP2 (Agent Payments Protocol)

2.1 What It Is & Architecture

The Agent Payments Protocol (AP2), announced September 16, 2025 by Google Cloud, is an open protocol for secure, interoperable agent-led payments across platforms. It was developed with 60+ organizations including Mastercard, American Express, PayPal, Coinbase, Intuit, Salesforce, Worldpay, and more.

AP2 is designed as an extension of the Agent2Agent (A2A) protocol and Model Context Protocol (MCP), creating a complete stack: build agents with ADK → equip with MCP → collaborate via A2A → pay via AP2.

Architecture — Role-based with Verifiable Digital Credentials (VDCs):

Three core VDC types:

  1. Intent Mandate — Captures conditions under which an agent can make purchases (signed by user). Used especially for "human-not-present" delegated tasks with rules (price limits, timing, conditions).
  2. Cart Mandate — Captures the user's explicit authorization for a specific cart (exact items and price). In human-present flows, the user signs this. In human-not-present, the agent generates it based on Intent Mandate rules.
  3. Payment Mandate — Shared with payment network/issuer, signals AI involvement and user presence status for risk assessment.

Trust model:

  • All VDCs are tamper-proof, cryptographically signed digital contracts
  • Creates a non-repudiable audit trail from intent → cart → payment
  • Answers authorization, authenticity, and accountability questions

Transaction modes:

  • Human present (real-time): User asks → agent finds options → user approves Cart Mandate → payment
  • Human not present (delegated): User signs detailed Intent Mandate upfront with rules → agent auto-executes when conditions met

2.2 Onboarding Process

  • Open protocol — anyone can implement
  • GitHub repo: https://github.com/google-agentic-commerce/AP2
  • Samples use Agent Development Kit (ADK) and Gemini 2.5 Flash (but any framework works)
  • Setup options:
    • Google API Key (development): Get key from Google AI Studio
    • Vertex AI (production): Configure gcloud CLI
  • Install AP2 types: uv pip install git+https://github.com/google-agentic-commerce/AP2.git@main
  • Multiple sample scenarios available with run.sh scripts

2.3 Identity Model

  • Verifiable Digital Credentials (VDCs) — Cryptographically signed, tamper-proof credentials
  • User identity proven through cryptographic signatures on mandates
  • Agent identity established through A2A Agent Cards
  • Aligns with broader decentralized identity direction
  • Payment Mandate signals agent involvement to issuers for risk assessment
  • Non-repudiable proof of user intent throughout transaction chain
  • Designed for interop with existing payment identity systems

2.4 What the Agent Can DO

  • Smarter shopping — Monitor prices/availability, auto-purchase when conditions met
  • Personalized offers — Agent communicates user context to merchant agents for custom deals
  • Coordinated tasks — Book flights + hotels simultaneously within budget constraints
  • Delegated purchases — "Buy concert tickets when they go on sale" with pre-authorized rules
  • Real-time purchases — Standard browse → select → approve → pay flow
  • B2B procurement — Autonomous purchasing via Google Cloud Marketplace
  • License management — Auto-scale software licenses based on real-time needs

2.5 Financial Controls

  • User always in control — Core design principle
  • Intent Mandates — Pre-authorized rules with:
    • Price limits
    • Timing constraints
    • Specific conditions
    • Vendor restrictions
  • Cart Mandate requires explicit approval for human-present transactions
  • Full cryptographic audit trail — Every step from intent to payment is signed and verifiable
  • Payment Mandate signals to issuers whether human is present
  • Dispute resolution supported by non-repudiable evidence chain
  • Privacy by design — Role-based architecture protects sensitive payment details

2.6 Supported Payment Rails

  • Credit and debit cards (initial version — "pull" payments)
  • Stablecoins and cryptocurrencies — via A2A x402 extension (with Coinbase, Ethereum Foundation, MetaMask)
  • Roadmap includes:
    • Real-time bank transfers (UPI, PIX)
    • Digital currencies
    • "Push" payment methods
  • Payment-agnostic framework — designed for any payment type

2.7 Pricing / Fees

  • Open protocol — free to implement
  • No Google fees for using AP2 itself
  • Standard payment processing fees apply (depends on payment rail chosen)
  • Google AI Studio API key needed for running samples with Gemini (standard Google AI pricing)

2.8 Current Status

  • 📢 Announced September 16, 2025 with code samples
  • Open beta — GitHub repo with working implementations
  • Production-ready x402 extension for crypto payments
  • 60+ partner organizations
  • Active development — PyPI package for AP2 types planned
  • Reference implementations from Google and community ongoing
  • Not yet widely deployed in production merchant environments

2.9 SDK / API Docs

2.10 Advantages & Disadvantages

Advantages:

  • Massive coalition (60+ partners including Mastercard, Amex, PayPal, Coinbase)
  • Open, non-proprietary protocol
  • Elegant cryptographic audit trail design (Intent → Cart → Payment Mandates)
  • Payment-agnostic — supports cards, crypto, real-time transfers
  • Built on A2A/MCP ecosystem — integrates with broader agent infrastructure
  • Strong "human-not-present" delegation model with pre-authorized rules
  • x402 integration already production-ready for crypto

Disadvantages:

  • Very new (Sep 2025) — limited production deployments
  • Complex protocol with multiple VDC types may slow adoption
  • Heavily Google-centric development (despite open protocol)
  • Requires Google API key or Vertex AI for running reference implementations
  • No PyPI package yet — install from Git
  • "Pull" payments only in initial version (no real-time bank transfers yet)
  • May compete/conflict with Visa TAP, creating merchant confusion

3. Stripe Agentic Commerce Suite

3.1 What It Is & Architecture

Stripe's Agentic Commerce offering is a developer toolkit that enables AI agents to interact with Stripe's full payment infrastructure through function calling and MCP (Model Context Protocol). Unlike TAP or AP2 which are trust/payment protocols, Stripe provides tools and APIs that let agents directly create and manage payment objects.

Architecture:

  • Stripe Agent Toolkit (stripe-agent-toolkit / @stripe/agent-toolkit) — SDK that exposes Stripe API operations as LLM-compatible function calls
  • Stripe MCP Server — Remote MCP server at https://mcp.stripe.com with OAuth auth; also runnable locally via npx
  • @stripe/ai-sdk — Integration with Vercel's AI SDK for billing
  • @stripe/token-meter — Integration with native OpenAI/Anthropic/Gemini SDKs for usage-based billing

Framework support:

  • OpenAI Agents SDK
  • Vercel AI SDK
  • LangChain
  • CrewAI
  • Any LLM provider supporting function calling

3.2 Onboarding Process

  1. Create a Stripe account (standard Stripe signup)
  2. Generate a Restricted API Key (rk_*) with specific permissions
  3. Install SDK:
    • Python: pip install stripe-agent-toolkit
    • TypeScript: npm install @stripe/agent-toolkit
  4. Or connect via MCP: npx -y @stripe/mcp --api-key=YOUR_STRIPE_SECRET_KEY
  5. Or use remote MCP server: https://mcp.stripe.com (OAuth-based)
  6. Start using — agent can now call Stripe operations as tools
  7. Recommended: Use Stripe Sandbox for testing (non-deterministic agent behavior)

3.3 Identity Model

  • Stripe API Keys — Restricted keys (rk_*) with granular permissions
  • OAuth — For remote MCP server connections
  • Connected Accounts — Multi-party payments context (acct_123)
  • No agent-specific identity protocol — agents authenticate as the Stripe account holder
  • Tool permissions controlled by API key permissions — key-level access control
  • MCP client sessions manageable in Stripe Dashboard

3.4 What the Agent Can DO

Full Stripe API operations via function calling:

  • Create Payment Links — Accept funds for products
  • Create products and prices — Set up offerings
  • Create and manage customers — Customer lifecycle
  • Create and send invoices — Billing
  • Process refunds — Customer support
  • Manage subscriptions — Create, update, cancel
  • List and search — Payment intents, disputes, products, etc.
  • Retrieve balance — Check account balance
  • Create coupons — Promotions
  • Update disputes — Handle chargebacks
  • Search Stripe knowledge base — Documentation and support
  • Scaffold test data — Development/testing

3.5 Financial Controls

  • Restricted API Keys — Most important control; limit agent to only needed operations
  • Sandbox environment — Test agent behavior before going live
  • Evaluation runs recommended — Assess non-deterministic agent performance
  • Dashboard oversight — Manage MCP sessions, view all operations
  • Stripe's built-in controls — Fraud detection (Radar), dispute management
  • Human confirmation recommended — Stripe suggests enabling human confirmation of tool use
  • No protocol-level spending limits — Controls are at the Stripe API key permission level

3.6 Supported Payment Rails

Everything Stripe supports:

  • Credit/debit cards (100+ countries)
  • Digital wallets (Apple Pay, Google Pay, etc.)
  • Bank debits and transfers (ACH, SEPA, etc.)
  • Buy now, pay later (Klarna, Afterpay, etc.)
  • Stablecoins (USDC)
  • Real-time payments
  • Local payment methods (iDEAL, Bancontact, etc.)
  • In-person payments (Stripe Terminal)

3.7 Pricing / Fees

Standard Stripe pricing (no additional fee for agent toolkit):

  • 2.9% + 30¢ per successful card transaction (domestic)
  • +1.5% for international cards
  • +1% for currency conversion
  • Agent toolkit/SDK: Free (open source, MIT license)
  • MCP server: Free (included with Stripe account)
  • Standard Stripe product pricing applies to specific features (Billing, Tax, etc.)

3.8 Current Status

  • 🔧 Developer Preview — Toolkit is functional but marked as developer preview
  • MCP server in Public Preview
  • Agent toolkit actively maintained on GitHub (https://github.com/stripe/ai)
  • Production-ready for basic use cases with Sandbox testing recommended
  • Remote MCP server live at https://mcp.stripe.com

3.9 SDK / API Docs

3.10 Advantages & Disadvantages

Advantages:

  • Leverages entire Stripe payment infrastructure (100+ countries, 100+ payment methods)
  • Extremely easy to integrate — pip install + API key
  • Works with all major agent frameworks (OpenAI, LangChain, CrewAI, Vercel)
  • MCP server for IDE integration (Cursor, etc.)
  • No additional fees beyond standard Stripe pricing
  • Open source (MIT license)
  • Huge existing Stripe merchant base — no new merchant onboarding needed
  • Production-ready payment processing (Stripe is proven at scale)

Disadvantages:

  • Not a protocol — it's a toolkit for Stripe's existing APIs (vendor lock-in)
  • Agent acts as the Stripe account holder, not on behalf of a consumer
  • No agent identity/trust framework (unlike TAP or AP2)
  • Non-deterministic agent behavior — Stripe warns about testing extensively
  • Primarily a B2B tool (business manages its own Stripe via agents)
  • Not designed for consumer-facing "agent shops for you" scenarios
  • Security risk if API key permissions are too broad
  • Developer preview — APIs may change

4. x402 Protocol

4.1 What It Is & Architecture

x402 is an open, internet-native payment standard built around the HTTP 402 Payment Required status code. Created by Coinbase, it enables services to charge for API access and content directly over HTTP using crypto-native payments. It's designed for machine-to-machine payments, especially AI agents.

Core philosophy: "Absolves the Internet's original sin" — making payments as native to the internet as HTTP itself. No accounts, no API keys, no subscriptions needed.

Architecture — three roles:

  1. Client (Buyer) — Entity wanting to pay for a resource (human dev or AI agent)
  2. Resource Server (Seller) — HTTP server providing API/content that requires payment
  3. Facilitator — Optional service that verifies and settles payments on the blockchain

Flow:

  1. Client sends HTTP request to resource server
  2. Server responds with 402 Payment Required + payment instructions (PAYMENT-REQUIRED header)
  3. Client selects a payment method from accepted options, signs a payment payload
  4. Client resends request with PAYMENT-SIGNATURE header
  5. Server verifies payment (via facilitator or locally)
  6. If valid, server performs work, settles payment on blockchain
  7. Server returns 200 OK + resource + PAYMENT-RESPONSE header

Schemes: Logical ways of moving money

  • exact — Transfer specific amount (e.g., $1 to read article)
  • upto (theoretical) — Transfer up to amount based on resources consumed (e.g., LLM token generation)

Network-agnostic: Same scheme can have different implementations per blockchain (EVM vs. Solana).

4.2 Onboarding Process

For Sellers (1 line of code):

app.use(paymentMiddleware({
  "GET /weather": {
    accepts: [...],
    description: "Weather data",
  },
}));

For Buyers:

  • Need a crypto wallet with stablecoins
  • Use x402-compatible HTTP client:
    • npm install @x402/fetch or @x402/axios
    • pip install x402
    • go get github.com/coinbase/x402/go

No accounts, KYC, or API keys needed — buyer just needs a wallet.

4.3 Identity Model

  • No identity layer — x402 is deliberately identity-free
  • Buyers are identified only by their blockchain wallet address
  • No accounts, no personal information needed
  • Permissionless — anyone with a wallet can pay
  • Trust-minimizing — facilitator/server cannot move funds except as client intended
  • Client signs payment payloads with their wallet private key
  • This is both a feature (privacy, permissionless) and a limitation (no agent identity verification)

4.4 What the Agent Can DO

  • Pay for any API endpoint per request (no subscription needed)
  • Access paywalled content with automatic payment
  • Use microservices with per-use micropayments
  • Autonomously pay for API access without human intervention
  • Proxy and resell API capabilities
  • Integrated with Google AP2 via the A2A x402 extension for broader commerce scenarios

4.5 Financial Controls

  • Minimal by design — x402 prioritizes permissionlessness
  • Agent controls spending based on wallet balance (can't spend what it doesn't have)
  • No built-in spending limits, human oversight, or approval workflows
  • Facilitator cannot move funds outside client's signed instructions
  • Payment amounts specified per-request in the 402 response
  • On-chain audit trail — All settlements are on public blockchains
  • No chargeback mechanism (crypto is final)
  • Controls must be implemented at the application layer above x402

4.6 Supported Payment Rails

Crypto only (stablecoins and tokens):

  • EVM chains: Base (primary), Ethereum, Polygon, Avalanche, Arbitrum
  • Solana (SVM)
  • Stablecoins: USDC (primary)
  • SDKs: @x402/evm, @x402/svm
  • Multiple live facilitators supporting various networks
  • Network-agnostic by design — supports any blockchain
  • No fiat support (though spec allows future fiat extensions, onchain payments always prioritized)

Stats (from x402.org):

  • 75.41M transactions
  • $24.24M volume
  • 94.06K buyers
  • 22K sellers

4.7 Pricing / Fees

  • Zero protocol fees — x402 itself is free
  • Only blockchain gas/network fees apply (nominal on L2s like Base)
  • No minimum payments, no percentage fees from x402
  • Facilitator services may charge small fees (Coinbase CDP facilitator is free currently)
  • Apache-2.0 open source license

4.8 Current Status

  • ✅ Production — Live with 75M+ transactions processed
  • Open source under Apache-2.0
  • Active development on GitHub
  • Integrated into Google AP2 ecosystem
  • Growing ecosystem of facilitators, services, and tools
  • v2 launched (referenced in site navigation)
  • Community on Discord (Coinbase CDP channel)

4.9 SDK / API Docs

4.10 Advantages & Disadvantages

Advantages:

  • Beautifully simple — 1 line of server code, HTTP-native
  • Zero protocol fees — only gas costs
  • No accounts, KYC, or API keys needed
  • Perfect for micropayments (traditional rails can't do sub-$1 cost-effectively)
  • 75M+ transactions prove it works at scale
  • Multi-language SDKs (TypeScript, Python, Go)
  • Multiple framework support (Express, Hono, Next.js)
  • Integrated into Google AP2 ecosystem
  • Truly open and decentralized
  • Coinbase backing provides credibility

Disadvantages:

  • Crypto-only — No fiat support (limits adoption for traditional businesses)
  • No identity layer — Can't verify agent legitimacy or authorization
  • No built-in financial controls — No spending limits, no human approval flows
  • No chargeback/dispute resolution — Payments are final
  • Requires crypto wallet — Barrier for non-crypto-native users/agents
  • On-chain settlement has inherent delays (even on L2s, not instant)
  • Regulatory uncertainty — Crypto payments face varying legal status globally
  • Price volatility risk (mitigated by stablecoins, but still a perception issue)

5. Skyfire

5.1 What It Is & Architecture

Skyfire is a centralized agentic commerce platform providing payments and identity ("Know Your Agent" / KYA) for AI agents. It's a managed service that enables AI agents to process payments, verify identities, and access services without human intervention.

Architecture — User → Agent → Service model:

  • Users — Top-level entities (person or business) who manage agent accounts
  • Buyer Agents — Act on behalf of users to discover and purchase services
    • Created automatically at signup
    • Have funded wallets
    • Generate KYA tokens (identity) and PAY tokens (payment)
  • Seller Agents — Enable users to offer services/APIs for consumption
    • Created via Dashboard
    • Register Seller Services for discovery
    • Verify buyer tokens via JWKS
  • Seller Services — Products, APIs, MCP servers, or websites offered by sellers
    • Define pricing, identity requirements, and token format
  • Wallets — Managed by Skyfire for both buyers and sellers
  • Settlement — Skyfire handles fund transfers between wallets

Token-based protocol:

  • KYA tokens — Identity verification (JSON Web Tokens verified via JWKS)
  • PAY tokens — Payment authorization
  • KYA+PAY tokens — Combined identity + payment
  • Tokens passed via HTTP headers or request body per seller's API spec

5.2 Onboarding Process

  1. Visit https://app.skyfire.xyz
  2. Enter email, log in via magic link (no password)
  3. Buyer Agent auto-created with pre-funded wallet
  4. Navigate to Playground → Generate API Key
  5. Use API key to create tokens (testpay via Playground or API)
  6. Browse Directory for available services
  7. For sellers: Click "Create Seller Account" → set display name → define services → submit for approval (24h review)

5.3 Identity Model

  • KYA (Know Your Agent) — Skyfire's proprietary identity verification system
  • JWT-based tokens verified via standard JWKS mechanisms
  • Identity tiers:
    • No identity: buyer's email in bid claim
    • Individual identity verification
    • Business identity verification
    • Sellers can require specific identity levels
  • API keys scoped per agent (Buyer or Seller), passed as skyfire-api-key header
  • Centralized identity — Skyfire is the identity authority

5.4 What the Agent Can DO

  • Create accounts at seller services autonomously
  • Subscribe to or pay for services (APIs, MCP servers, websites)
  • Discover services via Skyfire Directory
  • Access data and services in real-time
  • Verify identity to third-party services
  • Make payments to businesses without human involvement
  • Monetize websites (sellers can enable AI agent access)

5.5 Financial Controls

  • Pre-funded wallets — Agents can only spend what's been deposited
  • Skyfire manages settlement — No direct blockchain access for agents
  • Seller approval process — Services reviewed within 24 hours
  • Pricing controls — Sellers set prices and pricing models (PAY_PER_USE, PAY_PER_MB, etc.)
  • Identity requirements — Sellers can require verified identity before access
  • Centralized oversight — Skyfire as intermediary provides audit trail
  • One buyer agent per user — Limits agent proliferation

5.6 Supported Payment Rails

  • Skyfire managed wallets (internal settlement)
  • USDC (stablecoin) — Primary underlying payment rail
  • Users fund wallets (method of funding not extensively documented)
  • Settlement between buyer/seller wallets handled by Skyfire
  • Not directly supporting traditional payment rails (cards, bank transfers)

5.7 Pricing / Fees

  • Not publicly documented in detail
  • Pre-funded wallet model — users deposit funds
  • Platform likely takes a cut of transactions (typical marketplace model)
  • Seller pricing is configurable (pay-per-use, pay-per-MB, etc.)
  • Free tier appears available (pre-funded wallet at signup for testing)

5.8 Current Status

  • 🔄 Beta / Early Production — Platform is live and functional
  • Dashboard at https://app.skyfire.xyz
  • Developer docs at https://docs.skyfire.xyz
  • Seller service approval process operational
  • Service directory active
  • Getting started docs updated ~3-5 months ago

5.9 SDK / API Docs

  • Developer Portal: https://docs.skyfire.xyz
    • Getting Started guide
    • Buyer/Seller flow documentation
    • API Reference
  • Dashboard: https://app.skyfire.xyz
    • Playground for testing
    • API key management
    • Service directory
  • No public GitHub SDK found
  • Token creation via REST API

5.10 Advantages & Disadvantages

Advantages:

  • Complete platform — Identity + payments in one place
  • KYA (Know Your Agent) — Unique identity verification for agents
  • Easy onboarding — Magic link signup, auto-created buyer agent with pre-funded wallet
  • Service directory — Marketplace for AI-accessible services
  • Seller tools — Easy to monetize APIs and services for AI consumption
  • No crypto knowledge needed — Abstracts away blockchain complexity
  • JWT-based tokens — Standard, well-understood technology

Disadvantages:

  • Centralized — Skyfire controls everything (single point of failure/trust)
  • Vendor lock-in — Proprietary protocol, not interoperable
  • Limited payment rails — Primarily USDC/crypto wallets
  • Small ecosystem — Not as many partners as Visa TAP or Google AP2
  • Opaque pricing — Fees not publicly documented
  • Limited documentation — Docs are sparse compared to competitors
  • No open source components — Can't self-host or audit
  • 24-hour seller approval — Friction for sellers vs. x402's permissionless model

Comparative Summary

FeatureVisa TAPGoogle AP2Stripe Suitex402Skyfire
TypeTrust protocolPayment protocolDeveloper toolkitPayment protocolPlatform/marketplace
LaunchedOct 2025Sep 20252024-202520252024-2025
StatusProductionOpen BetaDev PreviewProduction (75M+ txns)Beta/Early Production
Open Source✅ Yes✅ Yes✅ Yes (MIT)✅ Yes (Apache-2.0)❌ No
IdentityCrypto keys + registryVDCs/MandatesAPI keysWallet address onlyKYA tokens (JWT)
Fiat Support✅ Visa cards✅ Cards (initial)✅ 100+ methods❌ Crypto only⚠️ Via stablecoin
Crypto Support⚠️ Via x402 interop✅ Via x402 extension✅ USDC✅ Native (USDC, multi-chain)✅ USDC wallets
Micropayments❌⚠️ Future❌ (30¢ min)✅ Native strength✅ Pay-per-use
Agent Identity✅ Strong (Visa vetting)✅ Strong (VDCs)❌ None❌ None✅ KYA verification
Financial Controls✅ Merchant-side✅ Mandates with limits⚠️ API key scope❌ Minimal✅ Wallet balance
Protocol FeesNone (standard Visa)NoneNone (standard Stripe)None (gas only)Not disclosed
Human OversightConsumer consent✅ Mandate signing⚠️ Manual❌ None built-in⚠️ Wallet funding
Onboarding DifficultyMedium (Visa approval)Low-Medium (code setup)Low (pip install)Low (wallet needed)Low (magic link)
Best ForMerchants accepting AI shoppersCross-platform agent commerceBusinesses automating Stripe opsAPI monetization, micropaymentsAI service marketplace
Key PartnersCloudflare, Shopify, Microsoft60+ (Mastercard, Amex, PayPal)OpenAI, LangChain, VercelCoinbase, Google AP2Independent

Key Takeaways for Product Testing

  1. For traditional e-commerce agent payments: Google AP2 + Visa TAP will likely dominate. AP2 handles the payment protocol; TAP handles merchant trust. They're complementary.

  2. For API/service monetization: x402 is the clear winner — zero fees, instant setup, micropayment-native. Already has 75M+ transactions.

  3. For Stripe-based businesses: Stripe Agent Toolkit is a no-brainer — zero additional cost, works with existing infrastructure.

  4. For agent identity: Skyfire's KYA or Visa's TAP — depends on whether you want centralized managed identity (Skyfire) or decentralized cryptographic identity (TAP).

  5. For crypto-native use cases: x402 is the gold standard. AP2's x402 extension bridges it to the mainstream.

  6. Interoperability is key: These protocols are converging. Visa TAP is aligning with x402, Google AP2 integrates x402, and Stripe partners with everyone. The winning strategy is likely multi-protocol.

Sources & Links

Visa TAP

Google AP2

Stripe

x402

Skyfire