Rozo Checkout

List the coins and chains you can pay an OpenRouter (Coinbase) invoice with through Rozo: USDC/USDT, native coins and BTC over Lightning, with token decimals. Static list, no network call; quote_invoice tells which native coins a given invoice accepts. Native coins (ETH on Ethereum, Base, Arbitrum; BNB on BNB Chain; POL on Polygon; SOL on Solana) are exact-out like Lightning: the order states the

Look up a Coinbase payment link (e.g. an OpenRouter top-up) and return the merchant, invoice amount, what the payer pays, the link expiry, whether it is still payable and supportedSources: the coins THIS invoice can be paid with. Offer a native coin (ETH, BNB, POL, SOL) only when it appears there. Creates nothing and moves no funds.

Creates a one-time deposit order; you pay from your own wallet. Returns the deposit address (or Lightning invoice), the exact amount to send (also in base units with the token decimals), any required memo, the expiry and the rozoPaymentId. This server holds no keys and sends nothing. Send exactly the amount, on exactly that chain and token, before expiresAt. An unfunded order simply expires at no

Check a Rozo order by rozoPaymentId: whether the deposit arrived, bridging/payout progress, and whether the Coinbase invoice settled. Read-only.

Fund a prepaid Rozo x402 balance with USDC or USDT, through a one-time deposit address you pay from your own wallet. Same fields as POST /v1/x402/topup: amount (USD), token, chain. Topup coins: USDC/USDT on Ethereum, BNB Chain, Polygon, Solana, Arbitrum; USDC on Base, Stellar. Native coins (ETH, BNB, SOL, ...) and BTC/Lightning are not accepted for top ups. Holding a native coin or sats? Use creat

Pay an x402 endpoint from the prepaid Rozo balance. You make the HTTP request yourself; when it answers 402, pass the payment requirement you chose from its "accepts" list here. Returns the value to send in the PAYMENT-SIGNATURE header (x402 v1: X-PAYMENT); replay the same request with it. Same fields as POST /v1/x402/sign: accepts, budget, idempotencyKey. The x402 payment leg is USDC on Base (eip

What the keyless ROZO Funding API supports right now: whether stellar_onboarding is on, the source chains and USDC assets, the Stellar USDC output, the usdGas options (XLM amounts) and per-order limits. Read-only, creates nothing. Fees come from the quote (fees and totals): never assume a fee. The receiving Stellar address signs ONE transaction (only when it is new or has no USDC trustline). The o

Price sending USDC/USDT from Base, Ethereum, Arbitrum or Polygon to USDC on a Stellar address. If the address is new or has no USDC trustline, the same plan opens the account, adds the trustline and (with usdGas) gives XLM, in one transaction the address signs once. Returns quoteId and planDigest (needed by stellar_wallet_create_order), the USDC and XLM amounts the receiver gets, every fee line an

Turn an approved quote into a payable order. Returns fundingId (keep it private: it is the only handle to the order), the one-time deposit address, the suggested amount and amountPolicy with minAcceptedAmount/maxPricedAmount when any_amount, payBefore and the accepted chains and tokens. orderId is your own reference: the server derives the upstream order id and Idempotency-Key from quoteId plus or

Read a funding order by fundingId: status, pendingActions (sign_stellar_onboarding means the receiver must sign), the deposit, and each leg (USDC, XLM) with its own status, delivered amount and tx hash. Read-only. Poll about every 15 seconds; completed only when every leg is confirmed.

When an order shows sign_stellar_onboarding, build the one transaction the receiving address must sign (creates the account if needed, adds the USDC trustline, claims the USDC, delivers XLM). Returns signingRequestId, the unsigned XDR, networkPassphrase, a readable operations list and expiresAt (at most 5 minutes). Sign it with the receiver wallet YOU control (Stellar SDK, Freighter, any wallet);

Submit the XDR your own wallet signed for a signing request. This is the claim: the account, trustline, USDC and XLM land in that one transaction. Submitting the same signed XDR again is safe (idempotent). Accepts only the signed transaction envelope, never a secret key. "submitted" is not delivery: poll stellar_wallet_order_status until completed. If it answers template_expired or failed, call st