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.
- Your Stripe account
- Your wallet address
- Machine-payable via x402
- Non-custodial
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.
The money routes around us.
onePay creates the payment options, 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.
Signed outbound webhooks tell your backend the moment either rail settles, with durable retries.
Create one Payment Intent. Hand over the link.
Your backend creates an idempotent Payment Intent for its own order and gets back one pay URL. The payer chooses card or USDC on that page.
# create once; retry safely with the same orderId
curl -X POST https://onepay-dev.saasflare.dev/v1/payment-intents \
-H "Authorization: Bearer $ONEPAY_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"orderId":"order_123","amount":"9.90","currency":"USD","usdcAmount":"9.90","successUrl":"https://shop.example/success","cancelUrl":"https://shop.example/cart"}'
# -> { "intentId": "...", "status": "unpaid", "payUrl": "https://.../pay/..." }
#
# Open payUrl. Signed payment_intent.updated webhooks are the source
# of truth; query the Intent only when webhook versions have a gap.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.
COMING SOON · the OnePay 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.
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.