How to accept crypto and fiat payments in one checkout

The architecture in one paragraph

Your checkout presents payment methods; the customer picks; your backend creates either a card charge or a crypto payment request; both paths converge on the same order record via webhooks. The design goal is that everything downstream of 'payment confirmed' is rail-agnostic: fulfillment, receipts, analytics, and support tooling should not know or care which rail paid the order. Merchants who build two parallel order pipelines regret it within a quarter.

Integration options, by engineering budget

No-code: add a hosted checkout link as a payment option next to your card button. On Shopify or WooCommerce this is a manual payment method with a link; on a custom cart it's an anchor tag. Real stores run meaningful volume this way, and it's the right first step because it validates demand before you write code.

API integration: your backend creates a payment request per order via the Flint API, redirects the customer to hosted checkout, and listens for webhooks. This is a day of work for most teams and gets you per-order references, automatic reconciliation, and a native-feeling flow. Full custom is rarely worth it beyond this; the hosted checkout already handles coin selection, QR codes, amount locking, and confirmation states you'd otherwise rebuild.

The webhook layer: where correctness lives

Both rails speak webhooks, so unify them. Practical rules that prevent real incidents: verify signatures on every event, card and crypto alike, because unverified webhook endpoints eventually get spoofed. Make handlers idempotent, since both rails can deliver an event twice. And model payment states explicitly: crypto payments have a detected state (seconds, seen on network) and a confirmed state (minutes, final on-chain). Show 'payment received, confirming' on detection; fulfill on confirmation. Mapping both rails into one state machine (pending, confirmed, failed, refunded) keeps every downstream system rail-blind.

Checkout presentation decisions

Three decisions matter, and each has a sensible default. Ordering: put cards first for general audiences, crypto first for crypto-native verticals like trading tools or gaming. Incentives: a 5 to 10% crypto discount shifts real volume, and the economics fund it, since crypto sales carry no dispute risk and settle same-day. Labeling: 'Pay with crypto (BTC, ETH, USDT, USDC)' outperforms vague 'alternative payment' phrasing because holders scan for the coins they own.

Price everything in fiat everywhere. The crypto amount is computed and locked at payment time; your catalog, cart, and receipts stay in dollars. Customers see $49 plus the exact coin amount that settles it.

Settlement, refunds, and books

Settlement differs per rail and your finance flow should embrace it rather than hide it: card revenue arrives T+2 to T+7 minus reserve; crypto revenue is final in minutes. Treasury rule for the crypto side: accept stablecoins by default and revenue stays dollar-denominated with no conversion decision to make. Refunds also differ. Card refunds reverse through the processor; crypto refunds are payments you send to an address the customer provides, so collect that address in the refund request flow, not over support back-and-forth. Record every order at its fiat value with a rail tag and per-rail fees, and your P&L reads normally while showing you exactly what each rail costs.

Rollout order that works

Add the hosted checkout link first and watch a week of orders. Wire the API and webhooks second, unifying the order model. Then add the crypto discount and measure the shift. Most merchants land at 10 to 30% crypto share depending on vertical, and that share is the point: it settles same-day, can't be disputed, and keeps revenue alive if the card rail has an incident. Flint is built to be exactly this second rail, live the same afternoon you start.