Aperture is an all-in-one payment gateway: merchants integrate once and route transactions across every major provider. No more juggling separate SDKs, credentials, or reconciliation dashboards per gateway — one API, one dashboard, one flow.
Merchants adding payments face a tax: one SDK per provider, one credential vault per environment, one reconciliation dashboard per gateway — and a fresh engineering project every time cost, coverage, or availability forces a new provider.
A provider-agnostic payment layer that exposes a unified REST API + merchant dashboard. Plug in once and route transactions by cost, coverage, success-rate, or regional availability. Built-in reconciliation rolls up every provider into one ledger.
Aperture is a payment orchestration layer: merchants integrate one REST API and dashboard, and Aperture routes each transaction across many payment providers by cost, coverage, success rate or region. It runs as a set of TypeScript services on Kubernetes with Kafka carrying every payment event, PostgreSQL as the ledger and Redis for idempotency and routing state. Splitting the API, routing engine, provider adapters, webhook dispatcher and reconciliation into separate services lets adapters fail or be added without touching the merchant-facing path.
Merchant systems call one API, and merchant teams operate everything from a single dashboard.
A single authenticated gateway normalises every provider's quirks behind one request and response contract.
Stateless TypeScript services on Node.js split the payment lifecycle into routing, execution, notification and reconciliation.
Every state change is an event on Kafka, projected into a PostgreSQL ledger and cached for fast routing and duplicate checks.
Each external payment provider sits behind its own adapter that speaks the provider's API and maps results to Aperture's model.
Docker images on Kubernetes in AWS let each service scale and deploy independently with full observability.
Merchant calls the unified API to create a payment with an idempotency key; the gateway authenticates and validates the request.
The routing engine scores eligible providers on cost, region, method coverage and recent success rate and picks a primary and fallbacks.
The chosen provider adapter translates the request, calls the provider, and emits the result as an event on Kafka.
On a soft failure or timeout, the retry orchestrator re-routes to the next provider within the same merchant-visible payment.
Provider callbacks arrive at webhook receivers, are verified and normalised, and update the ledger through the event stream.
The webhook dispatcher delivers signed status events to the merchant with retries; the dashboard shows the same timeline.
The reconciliation service matches ledger events with provider settlement records and surfaces mismatches in one view.
Every provider has its own payload, status codes and webhook shapes; isolating that in adapters is what lets merchants add or swap a provider without a new integration project.
Payments change state asynchronously across providers, webhooks and settlements; an append-only stream gives replayability and keeps the ledger, dashboard and reconciliation consistent.
Merchants retry, providers time out and networks duplicate; a key-checked fast path guarantees a payment is never charged twice regardless of how many times it is submitted.
Provider adapters change far more often than the merchant API; separate deployments let the team ship adapter fixes without redeploying or risking the core routing path.
“CodeLamda built the core payment-routing engine and merchant dashboard. Clean API surface, thoughtful reconciliation model, production-grade from sprint two.”
We ship MVPs, AI agents, and production systems in 8 weeks. Bring the rough spec — we'll scope the build inside a week with a fixed timeline and quote.
