TL;DR: MoltsPay 2.0.0 (published 2026-06-20) adds its first fiat payment rail — Alipay (支付宝 AI 收), settling in CNY — alongside the existing crypto rails (Base, Polygon, Solana, BNB, Tempo, XRPL). The same skill can now quote a price in USDC and in CNY, and the agent routes by preference and capability. Crucially, nothing about the crypto rails changed: this is a backward-compatible, additive release. The reason it was a config change and not a rewrite is the same reason we wrote about before — MoltsPay is abstraction-first, not protocol-first.

Where We Left Off

In Why MoltsPay is Emerging as the Best Stack for Multi-Chain Agentic Commerce the argument was simple:

Agentic commerce assumes the opposite of what today's payment systems were built for. Today's rails assume a human in the loop, single-chain execution, and explicit wallet interaction. Agents need programmatic, cross-chain payments with no human and no wallet ceremony.

The answer there was the Universal Payment Protocol (UPP) — an abstraction layer that wraps heterogeneous protocols (x402, MPP, Solana Pay) behind one unified API, so the agent expresses intent and MoltsPay picks the optimal protocol per chain. The whole bet was that abstraction-first beats protocol-first in a fragmented world.

2.0 is that bet paying off in the place it matters most: a payment type that isn't a blockchain at all.

The Next Wall: Crypto-Only Is Still a Silo

Multi-chain solved fragmentation within crypto. But "pay any chain" is still "pay in crypto." For real-world agentic commerce that's a hard ceiling:

1. Most real merchants settle in fiat. A merchant in mainland China prices a service in CNY, reconciles in CNY, and is regulated in CNY. Telling them "accept USDC on Base" is a non-starter, not a UX nit.
2. Most real buyers' agents hold fiat-backed balances, not a gas-funded wallet on six chains.
3. An agent shouldn't know or care which world a price lives in. "This service costs ¥6.99" and "this service costs $0.99 USDC" should be the same shape of decision.

A protocol-first stack hits this wall hard: x402 is an HTTP-native crypto settlement protocol. Bolting fiat onto it means a parallel, bespoke integration with its own SDK, its own signing, its own error model — exactly the fragmentation UPP was built to hide.

MoltsPay 2.0's Move: Fiat Is Just Another Rail

In MoltsPay, a "rail" is the unit of abstraction. Adding Alipay didn't mean a new protocol surface for developers — it meant implementing one more rail behind the same UPP boundary.

The Alipay rail (支付宝 AI 收) at a glance:

• Rail / chain id — "alipay", type: "fiat-rail"; sits at the same level as EVM/SVM chains
• Currency — CNY (amount is yuan as a string, not cents)
• Settlement protocol — Alipay AI 收, RSA2 (SHA256WithRSA) merchant-key signing
• Server — 100% native TypeScript, holds the RSA2 private key
• Client — Node CLI shells out to alipay-bot (auto-provisioned on install); browser not yet supported
• Eligibility — Mainland-China merchants only (ICP + business license + Alipay Open Platform)
• Backward compatibility — Zero changes to crypto rails

The developer-facing change is one config block, not a new mental model:

{
  "provider": {
    "name": "My AI Service",
    "wallet": "0xYourEVMAddress",        // crypto rails, unchanged
    "alipay": {                           // NEW: fiat rail
      "seller_id": "2088...",
      "app_id": "2021...",
      "private_key_path": "./cert/ALIPAY_PRIVATE_KEY.txt",
      "alipay_public_key_path": "./cert/ALIPAY_PUBLIC_KEY.txt",
      "sign_type": "RSA2"
    }
  },
  "services": [{
    "id": "text-to-video",
    "price": 0.99, "currency": "USDC",    // crypto price
    "alipay": { "price_cny": "6.99" }     // NEW: fiat price on the same service
  }]
}

Now the same skill can be paid in USDC on six chains or in CNY via Alipay. The agent chooses.

How It Stays Backward-Compatible: Dual-Emit 402

The wire-level trick is the same 402 Payment Required flow, but the server now dual-emits payment requirements:

• X-Payment-Required — the x402 / UPP-aware header that newer agents read
• Payment-Needed — the legacy header existing MoltsPay clients already understand

Agent ──request──▶ Server
Agent ◀─402 + {X-Payment-Required, Payment-Needed}── Server
        (offers: USDC on Base/Solana/BNB/…  AND  CNY via Alipay)
Agent ──picks a rail, pays──▶ Server ──settles──▶ result

Because both headers ship together, an old crypto-only client sees exactly what it saw in 1.x, while a 2.0 agent additionally sees the fiat option. No client was forced to upgrade. That is what "additive release" means in practice, and it's only cheap because the abstraction boundary already existed.

Why This Matters for Agentic Commerce

1. Intent over instrument. The agent says "buy this," not "sign an EIP-712 transfer on BNB" or "call the Alipay gateway with an RSA2 signature." Crypto and fiat collapse into the same programmable decision.
2. Real merchants can onboard. A mainland-China merchant accepts agent payments in their own currency and compliance regime — and, if they want, also accepts USDC from overseas agents, from one skill file.
3. Routing becomes a feature, not a fork. Buyer prefers fiat? Settle Alipay. Seller only wants crypto? Settle USDC. The decision lives in MoltsPay, not in every agent's code.
4. The hardest integration validated the architecture. Fiat doesn't have a chain, gas, or a wallet — it's the least "crypto-shaped" thing you could add. Adding it as a rail rather than a rewrite is the strongest evidence yet that abstraction-first was the right call.

Abstraction-First, Restated

The original article compared MoltsPay to protocol-first stacks and argued abstraction wins as the world fragments. 2.0 sharpens the claim:

A protocol-first stack is only as broad as its protocol. An abstraction-first stack is as broad as the rails you can implement behind it — and rails don't have to be blockchains.

Crypto fragmentation was the first proof. Crossing the crypto/fiat boundary with a config change — and breaking nothing — is the second.

Try It

npm install moltspay        # auto-provisions the alipay-bot CLI (best-effort;
                            # skip with MOLTSPAY_SKIP_CLI_INSTALL=1)
npm view moltspay version   # 2.0.0

• Crypto rails: Base · Polygon · Solana · BNB · Tempo · XRPL — gasless, USDC
• Fiat rail: Alipay (支付宝 AI 收) — CNY, mainland-China merchants
• Overseas merchants / individual developers: use the USDC rails (no onboarding required)
• Full config reference: docs/ALIPAY-RAIL.md

About MoltsPay

MoltsPay is open-source payment infrastructure for AI agents: HTTP-native, intent-based payments where agents pay each other — and now real merchants — for services without a human in the loop. As of 2.0.0, that spans six crypto chains and one fiat rail behind a single Universal Payment Protocol.

Compatibility note: 2.0.0 introduces no breaking changes to the existing crypto rails. Existing 1.x users can upgrade directly.

Tags: #ai #agenticcommerce #payments #alipay #fiat #crypto #x402 #web3 #opensource