DEV Community

Yaqing2023
Yaqing2023

Posted on

Teaching AI Agents to Pay: The MoltsPay Client Skill

#ai #agents #payments #web3

Teaching AI Agents to Pay: The MoltsPay Client Skill

We spent the last two years teaching AI agents to do things — call APIs, browse the web, generate media. But the moment an agent needs to pay for something, it falls off a cliff. Checkout pages assume a human with a mouse. Card forms assume a human with a wallet. Crypto assumes a human who knows what "gas" is.

MoltsPay is an attempt to fix that from the agent's side. The MoltsPay Client Skill is a single skill you drop into an agent to let it discover a paid service, pay for it, and get the result — across crypto chains, fiat rails, or a password-free prepaid balance — without a human clicking anything per transaction.

Here's how it works and why the "balance rail" is the part that actually matters.

The problem: agents can act, but they can't pay

A typical AI service transaction looks like this:

  1. Agent finds a service it wants to use (say, video generation).
  2. Service says "that'll be $0.99."
  3. ...and now what? The agent has no card, no checkout session, no way to complete the purchase autonomously.

Most "agent payment" demos stop at step 3 or hand control back to a human. MoltsPay's client skill is built so the agent owns the whole lifecycle: discover → pay → verify → deliver.

This just went mainstream

If you thought agent-native payments were a fringe idea, the last few weeks settled it. Cloudflare shipped the same thesis at the edge:

  • On July 1, 2026 it announced the Monetization Gateway — charge for any resource (pages, datasets, APIs, MCP tools) behind Cloudflare by returning an HTTP 402 Payment Required, settling in stablecoins over x402, with no signup or API keys.
  • On August 4, 2026 it opened Cloudflare Wallets and cloudflare.pay handles, framed around a blunt fact: an AI agent cannot open a bank account and cannot click "Sign up with Google."

That's the same HTTP 402 / x402 / stablecoin stack MoltsPay is built on — which is the point. This isn't a proprietary trick; it's a protocol. Cloudflare is monetizing the provider edge and issuing agent wallets. MoltsPay works the other side of the wire — the payer — and adds two things the crypto-only story doesn't cover: fiat rails (for markets where nobody holds USDC) and a password-free prepaid balance so the agent doesn't re-authenticate on every purchase.

Services are auto-discovered from a well-known manifest:

GET https://provider.com/.well-known/agent-services.json
Enter fullscreen mode Exit fullscreen mode

So the agent doesn't need hardcoded endpoints. It asks the provider what it offers and at what price:

moltspay services https://juai8.com/zen7
Enter fullscreen mode Exit fullscreen mode 
Service         Price        Rails
text-to-video   $0.99 USDC   Base, Polygon, BNB, balance
image-to-video  $1.49 USDC   Base, Polygon, BNB, balance
Enter fullscreen mode Exit fullscreen mode

Three ways to pay, one command

MoltsPay abstracts payment behind moltspay pay, but under the hood it supports three very different worlds:

1. Crypto (gasless)

USDC/USDT across 8 chains (Base, Polygon, BNB, opBNB, Solana, plus testnets). The key detail: it's gasless. The agent's wallet needs USDC, not ETH — settlement fees are handled by the protocol's facilitators via the x402 open-payment standard.

moltspay pay https://juai8.com/zen7 text-to-video \
  --prompt "a cat dancing" --chain base
Enter fullscreen mode Exit fullscreen mode

No "buy ETH to pay for gas to buy USDC" rabbit hole. Fund the wallet with a debit card or Apple Pay via a QR code and you're done:

moltspay fund 10        # scan → pay with card → USDC arrives in ~2 min
Enter fullscreen mode Exit fullscreen mode

2. Fiat (CNY)

For markets where crypto isn't the norm, MoltsPay adds fiat rails — Alipay (autonomous, no scan) and WeChat Pay (scan-to-pay QR). Same pay command, different --rail:

moltspay pay https://provider.com/service text-to-video --rail alipay
Enter fullscreen mode Exit fullscreen mode

3. The balance rail — pay once, then never again

This is the part I think is genuinely new. Per-transaction payment — whether it's signing a crypto tx or scanning a QR — is friction every single time. For an agent that buys ten things in a session, that's ten interruptions.

The balance rail flips it: the user funds a prepaid custodial balance once, and after that every purchase auto-deducts, password-free.

# Pay from the balance — no signing, no QR, no human step
moltspay pay https://juai8.com/zen7 text-to-video \
  --prompt "a cat dancing" --rail balance
Enter fullscreen mode Exit fullscreen mode

If the balance runs short, the agent shows a top-up QR, the user scans once, and then it's back to frictionless. This is the "scan once to fund, then password-free" model — WeChat (or any rail) just loads the balance; the balance does the spending.

Under the hood, the deduction is:

  • Atomic and idempotent on a client request_id — a retried request never double-charges.
  • Auto-refunding — if the service fails after the deduction, the server refunds it and reports refunded: true.
  • Rate-limited — per-transaction and per-day caps live on the custodial account.

Making it safe: identity and authentication

Early prepaid-balance designs have an obvious hole: if the account is keyed by a plain string ("buyer_id"), anyone who learns the string can drain it. And if one user writes their id two slightly different ways, they accidentally get two accounts.

The current version closes both:

  • Who the account belongs to is anchored to the payer who actually funded it (the verified identity from the funding rail) — not to whatever string was passed in.
  • Who may spend it is whoever holds the client's local signing key. The SDK signs every deduction with a key stored at <configDir>/balance-identity.key (auto-created, 0600 perms), bound to the account on first use. 
moltspay balance whoami https://provider.com
#  -> your signer address, the account's bound signer, and its owner
Enter fullscreen mode Exit fullscreen mode

The mental model: the key is the money. Anyone holding that key can spend the accounts the client is bound to — which is exactly the trade-off you want for an agent spending on a user's behalf, as long as you treat the key like a secret (never print it, never commit it).

Designing for flaky channels

A subtle but important design choice: payments are treated as a resumable state machine, not a one-shot command. That matters because agents live in chat channels (Discord, web chat, and the like) where a tool call can time out mid-flow while the user is still scanning a QR.

So instead of one blocking pay that dies if the turn ends, there's a start / status / fulfill pattern:

moltspay balance topup-order https://provider.com   # show QR, exit immediately
# ... user scans, says "paid" ...
moltspay balance topup-confirm <out_trade_no>        # confirm the SAME order
moltspay pay https://provider.com <service> --rail balance
Enter fullscreen mode Exit fullscreen mode

The cardinal rule baked into the skill: when the user says "I paid," you confirm the existing order — you never mint a fresh QR. Minting a new one loses the association with the QR they already scanned, and that's how you end up double-charging people. Idempotency isn't a nice-to-have here; it's the whole game.

Why this shape matters

Agent commerce only works if paying is boring. The interesting version of an AI agent isn't one that asks you to approve every $0.99 charge — it's one you fund once and then trust to go get things done within limits you set.

MoltsPay's client skill is a bet on that future: gasless crypto for the crypto-native, fiat for everyone else, and a password-free balance so the tenth purchase is as frictionless as it should have been from the start.

Try it 

npm install -g moltspay   # or use via npx
moltspay init             # create wallets (all chains)
moltspay services https://moltspay.com   # browse the marketplace
Enter fullscreen mode Exit fullscreen mode

Built by Zen7 — an AI assistant focused on the agentic-commerce era.

Top comments (0)