Milypay + MoneyGram: Funding the Wallet Before the 402

Agent payments die in a boring place: no balance.

Milypay sells Australian data over x402 — ABN lookups, energy, transit, ABS, and more. The API answers unpaid calls with HTTP 402 and a structured challenge. The agent is supposed to settle with stablecoins on Solana and retry.

That only works if the wallet already holds USDC (or another accepted mint). Most “I just created this agent” wallets do not.

MoneyGram Ramps is how we close that gap — without pretending cash-in is the same as pay-per-call.

Live fund UI: milypay.xyz/fund
Product: milypay.xyz

---

The problem (two layers)

1) Discovery without a seat

Traditional AU data vendors want accounts, API keys, and monthly minimums. Agents hate that. x402 fixes discovery and settlement for each call: no key, pay the price on the challenge, get the body.

2) Value still has to enter the machine

x402 assumes a funded wallet. In the real world:

• A builder spins up a throwaway key for a demo
• An agent spends down to dust mid-job
• Finance will fund fiat rails they recognise, not “please wire USDC to this base58”
• Support tickets become “402 forever” with no path to top up

If you only ship the payment protocol, you ship half a product. The other half is cash → stablecoin → retry.

That is the problem MoneyGram is wired for on Milypay.

---

What MoneyGram is (and is not) in this stack

MoneyGram is

• A wallet funding path (on-ramp, and off-ramp where the session allows)
• A session + widget flow (MoneyGram Ramps / xRamps)
• A way to land USDC on Solana so a subsequent x402 settle can succeed

MoneyGram is not

• The x402 settlement rail
• A replacement for PayAI / PAYMENT-SIGNATURE
• A free pass around AUD/USDC mint allowlists
• “Pay the ABN lookup with cash at a kiosk” as the HTTP credential

We encode that explicitly in the funding hint:

MoneyGram does not settle x402. On-ramp USDC into your Solana wallet, then retry with PAYMENT-SIGNATURE.

Keep those two steps separate and the architecture stays honest.

---

The integration (how it works today)

A. Fund UI

milypay.xyz/fund walks a human (or a careful agent operator) through:

1. Why the wallet needs USDC before retrying a paid call
2. Starting a MoneyGram session (on-ramp or off-ramp)
3. Opening the MoneyGram widget with the session token
4. Returning to a paid Milypay endpoint once the balance shows up

B. Session API

POST https://milypay.xyz/api/ramp/moneygram/session
POST https://api.milypay.xyz/ramp/moneygram/session
Body: { "mode": "on-ramp" }   // or "off-ramp"

Response shape (simplified):

• sessionId / sessionToken
• widgetUrl (mode stamped on the URL)
• sdkUrl
• env: sandbox or production
• source: local keys or proxy
• demo: true when sandbox / proxy path

Local keys (when configured): Milypay talks to MoneyGram Ramps session API with the merchant secret.
Fallback proxy: https://sol.new/api/moneygram/session keeps demo resilient when local keys are missing or fail — so /fund is not a brick during sandbox onboarding.

C. 402 funding hint

Paid challenges on api.milypay.xyz carry a funding block (see live 402 JSON), including:

• Role: fund_wallet_before_x402
• Session endpoint
• Demo UI: https://milypay.xyz/fund
• Suggested fiat (USD), minimums, shortfall hint
• Assets after ramp: USDC on Solana mainnet

Agents and UIs can branch:

if payment_required and balance_too_low:
  open funding.moneygram.demoUi
  # or POST funding.moneygram.session
  wait for USDC
  retry original request with PAYMENT-SIGNATURE

D. Then x402 settles as usual

Default rail remains Solana x402 (AUDD / AUDM / dAUD / USDC / USDT as configured). Optional MPP via ?rail=mpp is a separate story — see x402 vs MPP. MoneyGram sits before either rail, not inside them.

---

End-to-end loop

1. Agent calls GET https://api.milypay.xyz/au-business/abn/51824753556
2. Server returns 402 + accepts + funding.moneygram
3. Wallet USDC is below price (or zero)
4. Operator/agent starts MoneyGram on-ramp session → funds USDC on Solana
5. Agent retries with payment proof
6. Facilitator verifies/settles → body + receipt (sol.new/receipt/…)

Sandbox sessions are for integration and demos. Production keys flip the env when you are ready for live cash.

---

Why this pairing matters in Australia

Australian agent products still collide with USD mental models and empty-wallet demos.

• Milypay prices many surfaces for AUD-native settlement when liquidity allows
• MoneyGram’s ramp path is a practical fiat front door builders already understand
• Together: “fund like a normal person, spend like an agent”

We are not claiming MoneyGram invents x402. We are claiming funded agents finish the job.

For the broader stablecoin map: Stablecoins in Australia 2026.

---

What we are careful not to over-claim

• Sandbox ≠ production cash. Demo/proxy sessions can succeed while live KYC and limits still apply in production.
• USDC in ≠ AUD mint out. After ramp you may still swap or hold USDC depending on which accept the challenge lists.
• Off-ramp is optional. On-ramp is the critical path for “agent can’t pay.”
• No API key theatre returns. Funding does not reintroduce vendor seats for the data call itself.

---

Try it

CLI / MCP still default to demo where appropriate; paid host needs a funded key — see Milypay case study.

---

Build with Milysec

Milypay is a Milysec product: agent rails, Australian data, and the boring plumbing that makes demos become production.

If you need the same pattern on your API — 402 settle + fiat funding path that does not lie about what settles — contact the studio or start at milypay.xyz.