Case Study - A crypto-native storefront for gift cards, travel eSIMs, and digital goods

Overview

The Crypto Shop is a digital goods platform where checkout debits an account balance instead of routing each purchase through a wallet signature. Users deposit cryptocurrency; when they buy a gift card or eSIM, the platform posts a ledger debit, calls the relevant fulfillment provider, and attaches the redemption code to the order record.

Toshi Labs built the full stack: Next.js storefront, double-entry ledger, crypto deposit crediting, Temporal-backed fulfillment and reconciliation, and provider adapters for each product category.

Double-entry ledger

Account balances are not updated in place. Every movement of funds - a crypto deposit credited after confirmation, a checkout debit, a failed-fulfillment refund, or an operator adjustment - posts as a journal entry with matching debit and credit legs. User-facing balances are derived from that ledger, not stored as a standalone number that can drift out of sync with order and deposit records.

Deposits credit the user's liability account once an incoming transfer is confirmed on-chain; checkout debits that account when an order is accepted and posts the offset to clearing accounts pending provider settlement. Refunds and reversals post the inverse entries, so any balance can be traced back to a specific deposit, order, or adjustment. Posting is idempotent on external references (transaction hash, order ID) so webhook retries and workflow replays cannot double-credit or double-charge.

Supported assets include Bitcoin, Ethereum, USDC, USDT, and additional networks in the funding flow. Multi-asset balances use per-asset ledger accounts, with display conversion kept separate from the underlying postings.

Temporal for background work

Checkout and balance reads stay on the synchronous request path. Work that spans minutes, survives process restarts, or needs structured retries runs as Temporal workflows:

• Deposit confirmation - watch for incoming transfers, wait for required confirmations, then post the ledger credit. Replays safely if a worker restarts mid-confirmation.
• Order fulfillment - submit to the relevant provider API, poll or wait for a redemption code, retry transient failures with backoff, and on hard failure post a compensating ledger refund and terminal order state.
• Reconciliation - compare provider settlement reports against ledger clearing entries and fulfilled orders, flagging mismatches for operators.

Temporal gives each workflow a durable execution history: the same instance resumes after deploys, retry policy lives in one place, and crediting and fulfillment logic stays out of fire-and-forget handlers that lose state on crash.

Fulfillment adapters

Upstream providers do not share a common API shape. Retail gift cards, travel eSIMs, and custom partner catalogs each expose different product schemas, order endpoints, and failure modes. The platform routes every checkout through the same debit → fulfill → attach code sequence, but the fulfillment step dispatches to a category-specific adapter that speaks the provider's protocol.

Adapters handle the differences that matter at runtime: denomination validation against provider constraints, async vs synchronous code delivery, and mapping provider error codes to retryable vs terminal failures - the latter triggering a ledger reversal via the fulfillment workflow rather than leaving the user charged with no code.

What we did