Two rails. One checkout. We never hold the money.

Cards settle into your own Stripe account. USDC settles into your own wallet, on-chain. onePay only orchestrates the checkout — there is no balance with our name on it, because there is no account with our name on it.

See pricing See both rails

Your Stripe account
Your wallet address
Machine-payable via x402
Non-custodial

The idea

An aggregator that never becomes a middleman.

Every payment aggregator eventually asks to hold your funds. This one cannot: it has no Connect account, no receiving key, and nothing to hold them in.

Funds settle to you, directly

Card payments run through your own Stripe account in plain payment mode — no Connect, no application fee. USDC goes payer-to-you on-chain, to the wallet address you configured.

One integration, two rails

A single checkout link lets the payer choose card or USDC, and a cross-rail mutex makes sure the same order cannot be paid twice. Refunds run through Stripe; on-chain settlements are final by design.

An agent can pay it

The pay endpoint speaks x402 — the open HTTP 402 standard. A human GET gets a checkout page; an agent POST settles the quote and gets the resource. Same URL, no special SDK.

Where the money goes

The money routes around us.

onePay issues the quote, holds the mutex, and writes the ledger row. The funds themselves never enter an account we control.

Card rail

Stripe Checkout on your own account. Payments land in your Stripe balance; refunds, full or partial, run back through it.

USDC rail

The payer signs an EIP-3009 transfer to your wallet address on Base. Settlement is on-chain and final — onePay only records that it happened.

funds never touch SaaSFlare

Signed outbound webhooks tell your backend the moment either rail settles, with durable retries.

Taking a payment

Ask for a quote. Hand over the link.

Your backend requests a charge and gets back a pay URL. Point a browser at it and a human checks out; point an agent at it and it settles over x402.

terminal

# ask for a charge — the payer picks the rail
curl -X POST https://onepay-dev.saasflare.dev/charge \
  -H "Authorization: Bearer $ONEPAY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"amount":"9.90","currency":"usd","rail":"any"}'

# -> { "quoteId": "...", "payUrl": "https://.../pay/..." }
#
# a human opens payUrl and picks card or USDC.
# an agent POSTs to it and settles the quote over x402.

What it unblocks

Payments that do not need a person.

Cards and stablecoin, one checkout

Stop choosing. Give the payer both rails behind a single link, and settle each one into an account you already own.

Machine-payable endpoints

Price an API route in USDC and let an autonomous agent pay for the call itself — no card on file, no invoice, no human in the loop.

Digital goods and downloads

A quote, a pay URL, a signed webhook when it settles. Everything you need to unlock a file and nothing you do not.

Selling across borders

Take a card where cards work, and take USDC where they do not — without opening a second payment provider account.

onePay is in development and the name is provisional. The card rail is live on a dev deployment and has been run end-to-end with test cards; the USDC rail works on Base Sepolia testnet, with the mainnet switch still gated. It is single-tenant. There is no MCP server, no agent spend budgets, and no payout or payroll feature — those are roadmap, not code.

SAASFLARE NEWSLETTER

Follow what we’re building.

We’ll only email you when we have a product update or industry news genuinely worth your attention. No inbox noise—only content that’s useful to you.