03
TL;DRPSP-specific code scattered across every store → one payment API with adapters, idempotent webhooks and daily reconciliation → provider outages get rerouted instead of losing sales.
- Role
- Full-Stack Engineer, contract
- Client
- E-commerce studio · Latvia
- Year
- 2023—now
- Stack
- Node.js, TypeScript, PostgreSQL, Stripe
In one paragraph
Provider-agnostic charges, refunds and webhooks with daily reconciliation. Provider outages are handled by rerouting instead of lost sales, and finance gets a daily mismatch report instead of a monthly surprise.
Context
A Latvian studio runs several storefronts in verticals where one payment provider is a liability: accounts get frozen, cards decline by region, every PSP speaks its own dialect.
Problem
Provider-specific code was scattered through every product. Switching a PSP meant touching checkout, webhooks and admin in each store.
What I did
- 01
One internal contract
Products call a single payment API for charges, refunds, webhooks and payouts — never a PSP directly.
- 02
Adapters and routing
Adapters for Stripe, PayPal, Spoynt, Transfermit and SmartCore, with per-region and per-BIN routing rules.
- 03
Idempotent by construction
Webhook signatures verified, events stored with a unique key; a replayed event can never credit an order twice.
- 04
Reconciliation
A daily job compares provider settlement reports against the internal ledger and flags every mismatch.
Results
5
PSPs behind one contract
2+ yrs
in production across multiple storefronts
1 file
to add a new provider — an adapter, not a rewrite
Stack
- Node.js
- TypeScript
- PostgreSQL
- Stripe
- PayPal
- Spoynt
- Transfermit