Two-Layer Design: Protocol + PaaS
ItPay is architected as a two-layer system that separates open, community-driven standards from commercial, infrastructure-grade services.
┌══════════════════════════════════════════════════════════════════════════┐
║ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ │ ║
║ │ APPLICATION LAYER │ ║
║ │ │ ║
║ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ ║
║ │ │ AI Agents │ │ MCP Hosts │ │ Web/Mobile │ │ ║
║ │ │ (LangChain, │ │ (Claude, │ │ Apps │ │ ║
║ │ │ AutoGPT, │ │ Cursor, │ │ │ │ ║
║ │ │ Custom) │ │ Custom) │ │ │ │ ║
║ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ ║
║ └───────────┼─────────────────┼─────────────────┼────────────┘ ║
║ │ │ │ ║
║ ┌───────────┼─────────────────┼─────────────────┼────────────┐ ║
║ │ │ MCP Protocol (Model Context Protocol) │ ║
║ │ │ + x402 (HTTP 402 Payment Required) │ ║
║ │ └──────────────┬──────────────────┘ │ ║
║ └──────────────────────────┼──────────────────────────────────┘ ║
║ │ ║
╠════════════════════════════════╪════════════════════════════════════════╣
║ LAYER 1: PROTOCOL (OPEN SOURCE) ║
║ │ ║
║ ┌──────────────────────────┼──────────────────────────────────┐ ║
║ │ ▼ │ ║
║ │ ┌──────────────────────────────────────────────────────┐ │ ║
║ │ │ PROTOCOL LAYER (Open Source) │ │ ║
║ │ │ │ │ ║
║ │ │ Core Standards: Agent ↔ Agent Interaction │ │ ║
║ │ │ │ │ ║
║ │ │ ┌────────────────────────────────────────────────┐ │ │ ║
║ │ │ │ ● Agent Discovery (broadcast + query) │ │ │ ║
║ │ │ │ ● Service Manifest specification │ │ │ ║
║ │ │ │ ● Capability Negotiation │ │ │ ║
║ │ │ │ ● Payment Intent Protocol │ │ │ ║
║ │ │ │ - Request Payment (402) │ │ │ ║
║ │ │ │ - One-Time Pay │ │ │ ║
║ │ │ │ - Cumulative Pay │ │ │ ║
║ │ │ │ - Subscribe Pay │ │ │ ║
║ │ │ │ ● Install (service setup) │ │ │ ║
║ │ │ │ ● Refund │ │ │ ║
║ │ │ │ ● Void Service │ │ │ ║
║ │ │ │ ● KYC/KYB │ │ │ ║
║ │ │ └────────────────────────────────────────────────┘ │ │ ║
║ │ │ │ │ ║
║ │ │ ┌────────────────────────────────────────────────┐ │ │ ║
║ │ │ │ SDKs: Python · TypeScript · Go │ │ │ ║
║ │ │ └────────────────────────────────────────────────┘ │ │ ║
║ │ └──────────────────────────────────────────────────────┘ │ ║
║ └─────────────────────────────────────────────────────────────┘ ║
║ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ │ ║
║ │ LAYER 2: PaaS (PAID — COMMERCIAL INFRASTRUCTURE) │ ║
║ │ │ ║
║ │ ┌──────────────────────────────────────────────────────┐ │ ║
║ │ │ PaaS LAYER (Managed Service) │ │ ║
║ │ │ │ │ ║
║ │ │ Channel Connectivity: AI-Native Features: │ │ ║
║ │ │ ┌────────────────────┐ ┌─────────────────────┐ │ │ ║
║ │ │ │ ● WeChat Pay │ │ ● QR Code Generation│ │ │ ║
║ │ │ │ ● Alipay │ │ ● AI QR Recognition │ │ │ ║
║ │ │ │ ● PromptPay (Thai) │ │ ● FX Rate Routing │ │ │ ║
║ │ │ │ ● QRIS (Indonesia) │ │ ● Multi-currency │ │ │ ║
║ │ │ │ ● Bank Transfers │ │ ● Reconciliation │ │ │ ║
║ │ │ │ ● Crypto Channels │ │ ● Invoice & Receipt │ │ │ ║
║ │ │ └────────────────────┘ └─────────────────────┘ │ │ ║
║ │ │ │ │ ║
║ │ │ ┌────────────────────────────────────────────────┐ │ │ ║
║ │ │ │ Managed APIs · Dashboard · Webhooks │ │ │ ║
║ │ │ │ Usage Analytics · SLA Guarantees │ │ │ ║
║ │ │ └────────────────────────────────────────────────┘ │ │ ║
║ │ └──────────────────────────────────────────────────────┘ │ ║
║ └─────────────────────────────────────────────────────────────┘ ║
║ ║
╚══════════════════════════════════════════════════════════════════════════╝
Layer 1: Protocol (Open Source)
The Protocol Layer is a fully open-source specification that defines how AI agents discover each other, negotiate payment terms, and execute payments — without any intermediary holding funds.
What the Protocol Defines
The Protocol specifies a standard set of capabilities that any payment-capable agent can implement:
| Capability | Description |
|---|---|
| Discovery | Broadcast or query the network to find agents offering specific services. Agents publish service manifests describing what they do, at what price, under what terms. |
| Install | Set up a service relationship between two agents — exchange manifests, negotiate terms, establish shared context. |
| Request Payment (x402) | Issue an HTTP 402 Payment Required response with a payment intent, prompting the requesting agent to fulfill payment before the service is delivered. |
| One-Time Pay | A single, indivisible payment for a discrete service (e.g., "generate a report"). |
| Cumulative Pay | Accumulate multiple micro-charges into a single settlement to minimize transaction fees. |
| Subscribe Pay | Recurring payments on a schedule — daily, weekly, monthly — with budget caps and auto-renewal. |
| Refund | Full or partial reversal of a completed payment, with channel-specific rules. |
| Void Service | Cancel access to a service mid-cycle, including pro-rated refund logic. |
| KYC/KYB | Identity verification primitives for connecting real-world identities to agent identities. |
Protocol SDKs
The Protocol ships with reference implementation SDKs in three languages, each implementing the full capability set:
- Python SDK — Primary reference implementation, suitable for Python-based AI frameworks (LangChain, AutoGPT, etc.)
- TypeScript SDK — For web-first agents, MCP hosts, and Node.js services
- Go SDK — For high-performance gateway services and infrastructure components
All SDKs are open source under the MIT license and available on GitHub.
Who Would Run the Protocol Layer?
- Self-hosted AI agents — Run the protocol directly to accept payments without any third-party service
- Enterprise deployments — Internal agent-to-agent payments within a private network
- Protocol-only mode — An agent can implement the Protocol spec independently, using its own payment methods (no PaaS required)
Layer 2: PaaS (Paid — Commercial Infrastructure)
The PaaS Layer is a managed SaaS offering that provides the channel connectivity, AI-powered features, and operational tooling that make the Protocol practical for real-world use.
What PaaS Provides
Channel Connectivity
The PaaS maintains integrations with major payment networks across Asia and global markets:
| Channel | Region | Type |
|---|---|---|
| WeChat Pay | China | Mobile wallet / QR |
| Alipay | China / Global | Mobile wallet / QR |
| PromptPay | Thailand | Real-time payment / QR |
| QRIS | Indonesia | National QR standard |
| Bank Transfer | Global | Traditional bank rails |
| Crypto Stablecoins | Global | USDC/USDT on L2 |
AI-Native Features
The PaaS layer is designed specifically for the AI agent use case:
- QR Code Generation — Generate channel-specific QR codes programmatically (no manual image creation)
- AI QR Recognition — Extract payment details from a QR code image using computer vision (an agent "sees" a QR and initiates payment)
- FX Rate Routing — Real-time multi-currency conversion; lock in rates for a payment session
- Multi-Currency Support — Quote and settle in any currency; the PaaS handles the conversion math and channel routing
- Reconciliation — Match payment intents against channel settlement statements; detect discrepancies
- Invoice & Receipt Generation — Create formatted invoices and receipts for compliance and record-keeping
Operational Tooling
- Managed API — Hosted endpoints with guaranteed uptime SLA
- Dashboard — Web UI for monitoring payments, managing agents, viewing reconciliation reports
- Webhooks — Reliable event-driven notifications with retry and signature verification
- Usage Analytics — Volume tracking, success rates, latency distributions
- Support — Channel-specific support for integration issues
Who Uses the PaaS Layer?
- Independent AI developers — Building an agent that accepts payments but doesn't want to integrate 8+ payment channels individually
- Agent marketplaces — Running a platform that needs multi-channel payment acceptance for its agent ecosystem
- Enterprise teams — Need reconciliation, dashboards, and SLA guarantees
- Anyone who wants to go to production quickly — The PaaS provides the infrastructure; the Protocol provides the standards
Design Philosophy
ItPay's architecture is built on three foundational design choices:
1. MCP-Compatible
The Model Context Protocol (MCP) is an emerging standard for how AI applications communicate with external tools and services. ItPay is designed as an MCP-compatible payment layer:
- Agents talk to ItPay through MCP tool calls (e.g.,
request_payment,check_balance,get_qr_code) - Service manifests can be discovered through MCP's tool discovery mechanism
- Payment intents are represented as MCP resources that agents can inspect
- The ItPay MCP server can be dropped into any MCP host (Claude Desktop, Cursor, VS Code extensions, custom hosts)
2. x402 (HTTP 402 Payment Required) Semantics
ItPay embraces the HTTP 402 Payment Required status code as a first-class protocol signal:
Request:
GET /api/generate-report HTTP/1.1
Authorization: Bearer agent_token_abc
Response (402):
HTTP/1.1 402 Payment Required
Content-Type: application/json
X-ItPay-Payment-Intent: pay_2xK3m9QrL8vN5pW1
X-ItPay-Accepted: USD, CNY, THB
{
"error": "payment_required",
"payment_intent": {
"id": "pay_2xK3m9QrL8vN5pW1",
"amount": { "value": "5.00", "currency": "USD" },
"methods": ["x402", "qr", "mcp"],
"mcp_server": "itpay://payments.itpay.network"
}
}
This allows any HTTP-capable agent to participate in the protocol without installing SDKs — the 402 response itself contains everything needed to proceed with payment.
3. Custom Financial Primitives
Beyond standard charge/capture/refund, ItPay defines novel financial primitives tailored for AI agent interactions:
| Primitive | Description |
|---|---|
| Cumulative Pay | Aggregate micro-charges into one settlement; reduce transaction costs by 10-100x for high-frequency, low-value payments |
| Budget-Enforced Pay | A payer sets a budget cap (daily/weekly); the protocol enforces the cap and refuses over-limit charges |
| Subscribe with Budget | Recurring subscription plus a per-cycle budget cap with auto-negotiation on overages |
| Agent-to-Agent Escrow | Two agents use a channel-based escrow for multi-step workflows (deposit → delivery → release) |
| Proof of Payment | Verifiable, signed receipt that a payment was completed — machine-readable for downstream automation |
Protocol vs. PaaS: When to Use What
| Scenario | Use Protocol Only | Use Protocol + PaaS |
|---|---|---|
| Two agents on the same internal network | ✅ | ❌ |
| Agent accepting WeChat Pay | ❌ | ✅ |
| Enterprise with dedicated payment channel | ✅ | Optional |
| Consumer-facing AI agent with multi-currency | ❌ | ✅ |
| Prototype / hackathon | ✅ | Optional |
| Production deployment with reconciliation | ❌ | ✅ |
| Agent marketplace with 100+ merchants | ❌ | ✅ |
| Self-sovereign agent with no intermediary | ✅ | ❌ |
Summary
The two-layer design gives ItPay its unique position:
- Protocol (open source) ensures the standard is free, auditable, and universally adoptable — no lock-in, no permission required
- PaaS (paid) provides the value-added infrastructure that makes the protocol practical — channel integration, AI features, operational tooling
- Together, they create a complete ecosystem where any agent can pay any other agent, using any channel, in any currency, without any intermediary holding funds
This separation is intentional and structural: the Protocol defines what is possible, the PaaS delivers what is practical.
Related
- Architecture Overview — The microservices behind the PaaS layer
- Four-Party Payment Model — How money flows within this architecture
- MCP Integration — Connecting ItPay to MCP hosts
- x402 Semantics — HTTP 402 payment protocol in detail