← Blog
9 min read

Shipping agentic payments in Japan: the compliance line every team hits

AI agents can now pay for things on their own. x402 turns an HTTP 402 Payment Required into a real settlement handshake. Google's AP2 and the ACK-Pay receipt standard give agents a mandate-and-proof layer. MCP servers expose paid tools that a model calls without a human in the loop. The plumbing works today.

Then a team tries to launch in Japan, routes stablecoins the obvious way, and discovers they've quietly become an unlicensed money transmitter.

This post is the line we wish someone had drawn for us: what makes an agentic-payment flow a regulated activity in Japan, and how to design so it isn't. It's how we built LemonCake and what we tell teams in consulting. It is not legal advice — when money moves, get a Japanese lawyer — but it will save you the first three wrong turns.

The three regimes you can trip over

Japan doesn't have one "crypto law." A stablecoin-settled agent payment can fall under any of three different registrations, each with its own regulator expectations:

USDC is treated as an electronic payment instrument. The trap is that you can stumble into all three with a single careless design decision: holding a user's USDC to "make payments smoother."

The one word that decides everything: custody

Here is the whole article in one sentence:

The moment your platform can move a user's stablecoin on its own initiative, you are "managing" it — and management is the regulated act.

Not holding the keys for safekeeping. Not "we never touch the money." The test regulators reach for is control: if your system can initiate a transfer of someone else's USDC, you are managing it, and you need registration. Whether you actually move it is beside the point.

This is why the naive architecture fails. The obvious agent-wallet design looks like:

  1. User funds a balance on your platform (you now hold their USDC).
  2. Agent calls a paid API; you debit their balance and pay the seller.

Step 1 is custody. Step 2 is your platform initiating transfers of a user's funds. You've hit all three regimes at once.

Staying on the legal side: who is the subject of the transfer?

The design that stays clear keeps the buyer or their agent as the sole party that can move the USDC. Your platform orchestrates and proves — it never holds, and it never has unilateral transfer authority.

Concretely, the rules we hold ourselves to:

The mental model: you are the rails and the receipt, never the wallet. The agent holds the key and the spending mandate; your job is to present the 402, verify the payment, and hand back a signed receipt.

The fiat path is cleaner than the crypto path

Counter-intuitively, taking a card is easier to keep compliant than routing stablecoins — if you structure it right.

A Stripe Connect Direct Charge sends the buyer's card payment to the seller's connected account, with your platform taking an application fee. You never hold the principal; Stripe and the seller's account do. Pair that with a virtual balance — an accounting figure that grants the agent prepaid API calls, with no pooled fiat or stablecoin treasury behind it — and you've sidestepped custody entirely while still giving agents a "prepay once, spend down" experience.

That's the asymmetry worth internalizing: the regulated risk lives in pooling and moving other people's value, not in charging a card. Design so value is either (a) on a card rail handled by a licensed processor, or (b) on a stablecoin rail where the user's own key is the mover. Anything in between — a balance you hold and can move — is the expensive middle.

A checklist before you launch in Japan

If you're bringing an x402 / AP2 / ACK-Pay flow to Japanese users, walk these before you write the press release:

  1. Can our system move a user's USDC without their key signing? If yes → you're managing it. Re-architect.
  2. Do we ever hold a user balance of USDC or JPY? If yes → custody. Re-architect or get registered.
  3. Who is the conversion venue for off-ramp? It must be a licensed Electronic Payment Instruments dealer, not a crypto exchanger you've wired in as the converter.
  4. Is our "balance" a real pooled treasury, or an accounting figure with no pooled funds behind it? Only the latter avoids the funds-transfer regime.
  5. On the card path, does the principal ever land in our account? With Direct Charge it shouldn't — application fee only.

Clear all five and the autonomous loop — agent hits a paywall, pays from a capped mandate, gets a verifiable receipt — runs without you becoming a financial institution.

Why this is a moat, not a chore

Most teams building agent-payment infrastructure are outside Japan and treat its rules as a "later" problem. The teams inside Japan mostly aren't building at the protocol layer. The intersection — fluent in x402 / AP2 / ACK-Pay interop and the Japanese line between orchestration and custody — is nearly empty.

If you're shipping agentic payments and you've hit this wall, that's exactly the work we do. The protocols are the easy part. The line is the product.