A storefront that takes stablecoins and keeps no model in the loop.

Spending stablecoins on everyday things is awkward. Most merchants do not accept them, and the services that bridge the gap often have slow or opaque delivery. PomPay sits between a customer's wallet and the gift card and eSIM suppliers and does the parts that are hard to do well: confirming the payment, checking where it came from, deciding whether this customer may make this purchase today, fulfilling with the supplier, and keeping books that tie out.

The storefront has to be simple because the customer is only there for a minute. The system behind it has to be careful because it is handling money, customer identity, and codes that are as good as cash, under an anti-money-laundering programme that a Canadian regulator can ask to see.

1. 01A customer picks a brand and denomination for their country.
2. 02They sign in and pay from their wallet. The payment provider reports the crypto payment as it confirms on chain.
3. 03The payment is recorded as a held balance and the wallet it came from is screened.
4. 04When screening passes, the balance is released and the order is fulfilled with the supplier.
5. 05The code is emailed to the customer and kept in their account.

Customers can also hold a balance and apply it to orders, so a payment that covers several purchases does not need to be re-confirmed each time. Order status pages work from the order's own identifier, which is what lets a customer land back on the right order after a payment-provider redirect or an email link.

Four systems make decisions on their own, continuously, without a person in the loop. Each is a set of rules, each decision is recorded, and each exception stops and waits for a person.

• Wallet screening

  When a crypto payment settles, the funds land as a held balance, not an available one. A background poller starts a check on the paying wallet with a blockchain analytics provider, polls for the result with backoff, and on a pass releases the held balance to available and lets the order fund. A fail leaves the money held and raises an alert for compliance review. A customer with a clean wallet never notices.

• Identity verification

  KYC runs through an embedded verification provider. The provider's decision arrives by webhook, is verified against the exact bytes it signed, and is deduplicated on the payload digest so a retried or replayed delivery cannot change a status twice. A green result lets the customer transact at the next level.

• Transaction limits

  Every checkout and deposit is evaluated against the compliance manual before any balance is applied or any invoice is created: a single-transaction cap, a rolling 24-hour total that triggers mandatory identity verification, a country check, an age check, and an account-freeze check. The caps are kept in Canadian dollars at the Bank of Canada rate because that is what the regulator reads, shown to customers as round US dollar limits, and the stricter of the two wins. If the exchange rate is unavailable, the check fails closed.

• Payment reconciliation

  Crypto payments arrive in several webhook events as they confirm. Each event is reconciled by computing the difference from what the ledger has already recorded, so a late or repeated event adds exactly what is new. Supplier fulfillment webhooks are stored first, keyed on event id and type, and processed once.

Every one of those decisions is a regulatory one. Whether funds from a wallet may be released, whether a customer has to verify their identity before this purchase, whether a transaction is over the cap, whether a replayed webhook has already been counted. When a regulator asks why the system did what it did, the answer has to be a rule and a record, not a probability.

A language model would make those decisions less predictable and harder to explain, and it would add nothing, because the inputs are already structured: an amount, a timestamp, a screening result, a verification status, a country. Rules handle that exactly, every time, and the ledger and audit log show what was decided and why.

This is the same judgement the conversation on this site makes about your work. Where the inputs are structured and the decision has to be defensible, software and rules belong and a model does not. Where the work is reading unstructured documents or forming a view, a model earns its place, with gates around it. The lending platform in the next case study is the other side of that line.

Every amount in the system is stored as an integer in micro-units, one millionth of a dollar, so there is no floating-point arithmetic on money anywhere in the database. Customer balances, held funds, order totals, compliance thresholds, and provider settlements all use the same base. Provider APIs disagree about units, so each boundary converts explicitly and the preflight checks before fulfillment are written against the provider's units rather than the internal ones.

Behind the balances is a double-entry ledger. Journal entries are posted atomically and rejected if they do not balance. A reconciliation script checks the books against the balances, which is how the gaps between the two were found and closed.

• Signature verification on every provider webhook
• Idempotent webhook handling, so replayed events cannot double-credit a customer
• Role-based admin access behind the same authentication as customers
• An audit log of critical operations alongside the ledger
• Each provider's raw responses kept in their own tables for support and audit

These were built because a business that accepts crypto for products that are as good as cash is a target for abuse, and because the business is in Canada and has to be able to show what it checked. None of them are visible to a customer who is simply buying a card, which is the point.

Everything on the happy path is automated: catalogue sync from the supplier, checkout, the compliance checks, payment confirmation, holding and releasing balances around wallet screening, fulfilment, delivery of the code by email, and the ledger entries for each step. A customer who pays cleanly and stays under the thresholds never waits on a person.

Exceptions stay with a person. A wallet that fails screening, an identity check that needs review, a frozen account, a supplier order that fails after payment, or a ledger reconciliation that does not tie out all land with an operator through the admin surface, with the provider's raw responses kept alongside so the decision can be made from evidence rather than from a status word.

The build was de-risked by treating every provider as a boundary: signatures verified, units converted explicitly, events made idempotent, and integration tests that replay real webhook shapes against a database branch before anything ships.

• TypeScript throughout
• Next.js storefront on Vercel
• Express and Prisma API on Cloud Run
• PostgreSQL on Neon
• Clerk authentication with signed tokens between storefront and API
• Zod validation on every API input
• Unit tests for the compliance policy and payment deltas, integration tests that exercise checkout, webhooks, and screening against a database branch