Work · Payments / Orchestration / Infrastructure
Payment OS
One payment layer. Multiple providers.
What it is
Payment OS is a payment orchestration layer: merchants create a payment intent, the layer chooses the provider by rules and cost, hands off to the provider's hosted card collection, and normalises the result — across iyzico and PayTR today.
Why it needed to exist
Businesses rebuild checkout every time provider logic changes, and they cannot compare providers without running two integrations. Provider-specific behaviour belongs behind one contract.
What Idealink did
Idealink designed and built the service as a NestJS and PostgreSQL modular monolith, integrated both providers, and proved a real end-to-end sandbox payment. It runs as an internal pilot, not yet in production.
- Status
- Sandbox pilot
- Relationship
- Idealink venture
- Industry
- Payments
- Period
- 2026 — sandbox pilot
- Platform
- API
- Idealink role
- Architecture, backend engineering, provider integrations
Thesis
Checkout code should not have to understand which processor executes a payment. Payment OS is the architecture story: a provider abstraction that routes before card collection and never touches card data.
01
A payment, end to end
What v0.5 does today, in order.
Intent
The merchant posts a payment intent with normalised customer and basket data under an idempotency key. Raw card data is forbidden at the API.
Route
Deterministic rules plus configured cost tables choose the provider before any card is collected; degraded providers are excluded.
Collect
The chosen provider's hosted page — iyzico Checkout Form or PayTR iFrame — collects the card. Tokens stay provider-bound.
Callback
Signed callbacks are verified, correlated to the attempt and de-duplicated; results are retrieved server-side, never trusted from the browser.
Normalise
Intent and attempt states, route decisions and estimated savings versus the baseline provider are stored on one record.
02
Architecture
- Service
- NestJS + Prisma on PostgreSQL, modular monolith
- Model
- PaymentIntent and PaymentAttempt separated; RouteDecision, RoutingRule, WebhookEvent and IdempotencyRecord as first-class records
- States
- Created, requires payment method, requires action, processing, succeeded, failed, cancelled, partially refunded, refunded
- Tenancy
- Organisation → merchant → environment; API keys scoped per environment
- Secrets
- Provider credentials encrypted with AES-256-GCM under a master key
- Providers
- iyzico Checkout Form (end-to-end sandbox payment proven), PayTR iFrame V2 (initialisation and signed callback verification)
- Tooling
- Routing simulator without a provider call; provider health with success and latency telemetry
- Boundary
- PAN and CVV never enter the system; no cross-provider card failover is claimed
03
Why routing happens before the card
Provider tokens are provider-bound: a token from one processor cannot be replayed at another. Silent failover after card entry would require a vault or a full PCI card-data architecture, so v0.5 draws the line deliberately — route by fee, BIN family and provider health first, then hand off.
Every routing decision stores the baseline cost, the selected cost and the estimated saving, so the layer can answer the only question that matters to a merchant: what did routing save.
Provider-specific payment logic sits behind one orchestration layer, so checkout code does not need to understand which processor executes the payment.
Outcome
Where it stands
A real iyzico sandbox payment completed end to end through Payment OS — intent, hosted checkout, callback, authenticated retrieve, succeeded — and the dual-provider pilot with PayTR is under way.
Status is explicit: sandbox pilot. No production traffic, no merchants and no PayTR end-to-end completion are claimed.
Stack and capabilities
Only what mattered
- NestJS
- Prisma
- PostgreSQL
- iyzico
- PayTR
- AES-256-GCM