ItPay Protocol
What is ItPay Protocol?
ItPay Protocol is an open-source specification for AI-native, QR-based payment aggregation. It defines a four-party model — Payer, Payee, Channel, Platform — where the platform never touches money. The protocol achieves this through a decoupled architecture that routes only payment intent and status data, while actual funds movement occurs exclusively between the Payer's wallet and the Payee's merchant account over existing payment rails.
Key Design Decisions
| Decision | Rationale |
|---|---|
| Decoupled money and data | The Platform routes payment information only. Funds flow directly from Payer to Payee over the chosen Channel. This eliminates custodial risk, reduces regulatory surface area, and enables the protocol to operate without holding licenses for money transmission. |
| QR-native | Built around the EMVCo QR standard. Any consumer wallet capable of generating or scanning a merchant-presented QR code can participate without custom integration. The protocol extends the QR payload with structured intent data (amount, currency, expiry, description) encoded as a standard URI. |
| Channel-agnostic core | The core protocol specification has zero channel dependency. All payment-rail-specific logic is encapsulated in pluggable Channel adapters. Adding a new payment channel requires implementing only the adapter interface — the protocol, core objects, and data flow remain unchanged. |
| Agent-first | All operations are designed for autonomous execution by AI Agents. Payment lifecycle management uses HTTP 402 (Payment Required) semantics for synchronous request-response, MCP tools for agent-native tool calling, and webhook-driven state machines for asynchronous status propagation. No human-in-the-loop required beyond the initial Payer authorization. |
Two-Layer Architecture
┌────────────────────────────────────────────────────────┐
│ LAYER 2: PaaS (Managed) │
│ Channel Routing · FX Engine · Reconciliation · No- │
│ code Dashboard · Compliance Tooling · Audit Logging │
│ ────────────────────────────────────────────────── │
│ Optional hosted layer. One integration → any channel. │
├────────────────────────────────────────────────────────┤
│ LAYER 1: Protocol (Open Source) │
│ 9 Core Capabilities: │
│ Broadcast/Discovery · Install · KYC/KYB · One-Time │
│ Pay · Cumulative Pay · Subscribe Pay · Request Pay- │
│ ment · Refund · Void Service │
│ ────────────────────────────────────────────────── │
│ Free to implement. Apache 2.0. Channel-agnostic spec. │
└────────────────────────────────────────────────────────┘
Layer 1 (Protocol) — Open-source specification under Apache 2.0. Defines 9 core capabilities, a set of core objects (ServiceManifest, PaymentIntent, QRCharge, Invoice, Subscription), and the data flow between the four parties. Any agent framework, merchant platform, or payment gateway can implement the protocol without requiring the PaaS layer.
Layer 2 (PaaS) — Optional managed service providing Channel routing, FX conversion, automated reconciliation, and compliance tooling. The PaaS implements the protocol on behalf of agents and merchants, bridging multiple payment channels through a single integration surface.
Four-Party Model
The protocol separates four distinct roles:
| Role | Description |
|---|---|
| Payer | The human end-user. Scans a QR code presented by the Agent and authorizes payment through their existing wallet application. |
| Payee | The AI Agent, merchant, or service provider receiving funds. Integrates via the protocol or PaaS API. Never needs direct payment infrastructure. |
| Channel | The payment rail (Alipay, WeChat Pay, PromptPay, etc.) that executes the actual funds transfer from Payer to Payee. |
| Platform | The protocol orchestrator. Relays PaymentIntent creation, status updates, webhook callbacks, and reconciliation data. Never touches money. |
How It Works
-
Agent broadcasts a ServiceManifest. The Agent publishes its capabilities, pricing, and accepted channels via the Broadcast/Discovery capability. The manifest is a structured document that conforms to the protocol spec.
-
Human requests service; Agent creates a PaymentIntent. When a human initiates a paid interaction, the Agent constructs a PaymentIntent specifying amount, currency, description, and preferred channels. The protocol serializes this into a QR Charge payload, which the Agent renders as a QR code.
-
Human scans QR; Channel processes payment; Platform relays status. The human scans the QR with their wallet app and confirms the payment. The Channel processes the funds transfer directly to the Payee. The Channel sends a status callback to the Platform, which propagates the update to the Agent via webhook. The Agent receives the confirmed state and delivers the service.
Quick Links
| Protocol | PaaS | |
|---|---|---|
| Overview | Architecture | PaaS Overview |
| Quick Start | Quick Start Guide | Merchant API |
| Reference | Core Objects | Channel Matrix |
| Developer | Integration | SDKs |
| Security | Threat Model | Error Codes |
Supported Channels
| Channel | Region | Type |
|---|---|---|
| WeChat Pay | China (Global) | Consumer QR |
| Alipay | China (Global) | Consumer QR |
| AlipayHK | Hong Kong | Consumer QR |
| PromptPay | Thailand | National QR |
| PayNow | Singapore | National QR |
| DuitNow QR | Malaysia | National QR |
| VietQR | Vietnam | National QR |
| GCash | Philippines | Mobile Wallet |
| USDC | Global | Stablecoin (on-chain) |
The protocol is channel-agnostic by design. Any QR-based payment rail can be integrated by implementing the Channel adapter interface.