Design a Crypto Payment Gateway for E-Commerce

Hard45 min
1 / 30
understanding•10 min read

Problem Statement: Turning Probabilistic Finality into a Deterministic Business Fact

Frames the gateway as a custody-and-finality bridge between irreversible bearer chains and reversible commerce workflows.

Problem statement

Design a crypto payment gateway that lets e-commerce merchants accept Bitcoin, Ethereum, and stablecoins at checkout, optionally auto-converting proceeds to fiat or a stablecoin. The product must integrate with merchant checkout, quote a crypto amount against a local currency in real time, generate a payment address, detect and confirm the on-chain payment, handle partial, over, and late payments, settle the merchant, emit signed webhooks and receipts, and satisfy AML, sanctions, and tax obligations.

This is not a card authorization problem. A card auth is a reversible promise settled later; a chain payment is an irreversible bearer transfer whose acceptance is probabilistic until confirmations accumulate. The gateway's core job is therefore to convert a probabilistic chain event into a deterministic, auditable business fact exactly once, while absorbing volatility between the moment a price is shown and the moment value arrives.

Why the problem is distinctive

Three forces dominate. First, finality: Bitcoin produces about 144 blocks per day [[62]] and Ethereum about 7,200 at a ~12-second slot [[55]], so 'payment approved' is a policy over depth, not a synchronous response. Second, volatility: Stripe ended Bitcoin support on 23 April 2018 precisely because confirmation delay plus price movement produced wrong-amount payments [[26]]. Third, custody: holding merchant or shopper funds triggers licensing, key-management, and compliance obligations that a normal checkout backend never faces.

Public operating baseline

BitPay locks the invoice exchange rate for 15 minutes and settles merchants in fiat the next business day [[7]]. Coinbase Commerce notifies merchants through signed lifecycle webhooks [[14]]. BTCPay Server proves a self-hosted, non-custodial model using NBXplorer as an HD-wallet UTXO tracker [[19]]. Stripe and Shopify enabled USDC acceptance for millions of merchants across 34 countries on 12 June 2025 [[41]], and USDC circulated above $75B with daily volumes regularly topping $10B during 2025 [[47]]. These are cited public facts, not our design targets.

The four architectural planes

  1. Checkout plane: plugins, hosted checkout, merchant APIs, quotes, webhooks, receipts.
  2. FX plane: rate aggregation, spread, lock window, hedging, slippage accounting.
  3. Chain plane: address derivation, indexing, confirmation policy, reorg handling, fee estimation.
  4. Settlement plane: conversion, treasury wallets, payouts, double-entry ledger, compliance, reconciliation.

A strong answer keeps these planes separate: the chain plane may lag without corrupting the ledger, and the FX plane may halt new quotes without invalidating locked ones.

Key Highlights

  • •Crypto acceptance converts probabilistic chain finality into an exactly-once business fact.
  • •Stripe's 2018 Bitcoin exit was caused by confirmation delay plus volatility, which rate locks and hedging directly address [[26]].
  • •BitPay's public model locks the rate for 15 minutes and settles fiat next business day [[7]].
  • •Four planes: checkout, FX, chain custody, settlement and compliance.
  • •Assumed scale: 2M checkout sessions/day, 8% crypto selection, 160K charges/day, 5x peak.
Lead With Finality, Not Authorization
State in the first two minutes that chain payment acceptance is probabilistic and policy-driven, so the design centers on confirmation policy, reorg handling, and exactly-once crediting. This instantly separates you from candidates who draw a card auth box.
Do Not Draw a Card Authorization Analogy
Cards are reversible and settle through a network with chargebacks. Chain payments are irreversible bearer transfers; refunds are new payments, and 'approved' means depth-plus-policy, not a synchronous 200 from an issuer.

Section Rescue Kit

Buzzwords to use:

Probabilistic FinalityRate Lock Window

Safe statements:

  • "Let me separate what the chain guarantees from what the commerce workflow needs, because the gap is exactly where this design lives."
  • "Before choosing components, I will state the confirmation policy and rate lock policy, since both drive consistency and risk."
Design a Crypto Payment Gateway for E-Commerce - System Design | WinJob | WinJob