Stripe MPP, Tempo, and x402 on Solana: which rail for Australia

Australian teams building agents now get sold three overlapping stories: Stripe MPP, Tempo, and x402. They all start from HTTP 402. They do not settle the same way, they do not report the same way, and they do not treat the Australian dollar the same way.

This is the rail choice, not another protocol explainer. If you want the protocol internals, read x402 vs MPP first.

What each name actually is

x402 is an open HTTP payment protocol. The server returns 402 with payment requirements. The client (usually an agent) signs a stablecoin payment, retries, and gets the body. Coinbase originated it; the x402 Foundation now sits under the Linux Foundation. Settlement is onchain. On our stack that means Solana, with AUDD / AUDM / dAUD plus USDC/USDT.

MPP (Machine Payments Protocol) is an open HTTP 402 protocol co-authored by Stripe and Tempo. Challenges travel in WWW-Authenticate: Payment. Credentials come back in Authorization: Payment. Methods are pluggable: Tempo stablecoins, Stripe Shared Payment Tokens (cards), Lightning, custom rails.

Tempo is a payments chain. MPP can run without Tempo, but a lot of the early MPP energy, Stripe's machine-payments docs, and "session then stream usage" demos assume Tempo as the native stablecoin path.

Stripe in this context is not Checkout. It is MPP on top of PaymentIntents: agent pays, you still get a Stripe object, AUD (or your default currency) in the balance, familiar payouts, tax, and refunds.

Same status code. Different books.

Why Australia makes the split sharper

If you sell into the US, USDC-on-whatever is often "close enough." If you sell Australian data, AU software, or AU services, the money has to land in a story your accountant and your bank understand.

The trap is treating "we speak 402" as the product. Finance cares where the dollars sit on Tuesday.

Stripe MPP: when it is the honest default

Use Stripe MPP when the buyer is an agent and the seller already lives in Stripe.

Typical Australian case: a SaaS that already takes cards, already does BAS-friendly payouts, and now wants agents to hit the same API without a checkout page. Stripe's machine-payments docs are explicit: MPP charges can land as PaymentIntents. Cards via SPTs. Stablecoins can offramp into the Stripe balance.

You are buying:

• a credential model that can session (authorize a cap, stream usage)
• method breadth (card + chain)
• the ops stack you already trained the company on

You are not buying:

• a permissionless Solana catalog
• AUD onchain as the unit of account
• the "no vendor, just a wallet" seller story

If your CFO's question is "does this show up next to the other Stripe charges?", MPP is the answer.

Tempo: when the session is the point

Tempo is the chain Stripe and MPP authors keep pointing at for high-frequency, low-value charges. Sub-second finality, streaming sessions, not one broadcast per weather-API call.

Use Tempo when:

• the agent will hammer an endpoint thousands of times
• you want MPP sessions, not one signature per GET
• you are fine with Tempo as a settlement venue, then you move value out

Do not pick Tempo because the landing page said "internet native." Pick it because per-request Solana x402 would be too chatty for your QPS, and you actually measured that.

For Australian payroll-adjacent or invoice-adjacent money, Tempo still leaves you an FX and off-ramp problem. It is a rail, not an AU bank.

x402 on Solana: when the agent should just pay

x402 on Solana is what we shipped as Milypay default: ABN, ASIC, address, BSB, postage, weather. Agent hits HTTP, gets 402, pays AUD stablecoin (or USDC), retries, gets JSON. CLI, MCP, SDK. No Stripe account on the buyer side.

Use it when:

• the caller is an agent with a wallet, not a Stripe customer object
• the price is per call, not a monthly seat
• you want AUD-denominated onchain settlement without inventing an account graph
• other agents should discover you from OpenAPI / MCP / llms.txt, not from a Stripe dashboard

Limits we do not hide: naive one-tx-per-request at silly QPS is still a design smell. Solana fees make sub-cent calls realistic. They do not make unbounded chatty loops free. And "AUD stablecoin in a wallet" is not "AUD in NAB." Funding still exists. We wrote about MoneyGram as a fund step, not 402 settlement.

How we run both without lying

Milypay's default rail is x402 on Solana.

MPP on Tempo is opt-in:

GET https://api.milypay.xyz/au-business/abn/51824753556?rail=mpp

That is dual-rail: x402 on Solana plus an MPP charge path on Tempo. It is not "x402 settled on Tempo as the default facilitator path." If a sales deck says otherwise, it is wrong.

We will speak Stripe-shaped MPP for teams that already have Stripe. We will not pretend a Solana pay-per-call feed is a Stripe product.

A boring decision rule

1. Existing Stripe business, agents as a new client type → Stripe MPP. Keep AUD in Stripe. Add Tempo if you need session throughput.
2. Agent-native API, wallets, AUD stablecoins, Solana catalog → x402. That is Milypay.
3. Measured high QPS where per-request chain txs hurt → MPP sessions on Tempo (or batch/cache on x402). Measure first.
4. Need cards in the 402 itself → MPP + Stripe SPTs, not x402.
5. Need permissionless AU data for agents with no merchant account → x402 on Solana.

If you are still stuck, the question is usually "who is the merchant of record?" not "which logo is newer."

Related

• x402 vs MPP: how AI agents actually pay
• x402 on Solana
• Milypay case study
• Stablecoins in Australia 2026

Stripe docs: MPP Frontier. MPP FAQ: mpp.dev/faq. x402: x402.org.