Send sandbox money
SandboxFund a payer phone from this page. The settlement server opens a new allowance on Solana devnet for the same phone key, paid from its own sandbox send wallet, and signs a certificate the phone can carry with no signal.
No login, no wallet. Sandbox only: test tokens on Solana devnet with no value. No real money moves.
Send
Server reports the routeServer status from api.zerobars.us/api/health, read by this site's server (kept up to 30 s).
How it works
- You enter the payer phone's allowance id and an amount, at most 1.00 sandbox USDC.
- Your browser sends those two values, and nothing else, to the settlement server at api.zerobars.us. While the server answers "pending", the page sends the same request again, starting no new request more than 30 seconds after the first.
- The server reads that allowance on devnet to find the phone's public key, opens a new allowance for the same key from its sandbox send wallet, and waits for devnet to confirm it.
- It signs a certificate for the new allowance. This page checks that signature against the server key in config/pins.json before it draws the certificate as a code.
Limits
- At most 1.00 sandbox USDC per send. The server refuses more.
- One live send per recipient allowance: sending again returns the first send's terms until it expires.
- The send wallet has a daily budget (days are UTC). When it is spent, sending stops until the next day.
- The server limits bursts of new sends from one network.
- Which merchants the new allowance can pay (its earmarks) is set by the server, not by this form.
What works today
- This page checks what you type, sends the request, waits on a pending send, checks the returned certificate's signature in your browser, and draws it as a QR code.
- The settlement server's health check lists POST /v1/remittances as running.
- The iPhone app shows its allowance id on the Pay screen and imports a scanned certificate in builds that include the allowance import change (merged Oct 10); an older build does neither.