Skip to content

Payments · Orchestration · Infrastructure

One payment layer.Every product.

Products integrate once. Idealink Payment OS handles provider routing, hosted payment flows, callbacks and state normalisation behind one contract.

Designed for payment providers, bank virtual POS integrations and the payment rails that come next.

See how it works
Talk to Idealink
Sandbox pilot

01

Product

Create payment intent

Normalised payment state

02

Idealink Payment OS

Route & hand off

Webhook / callback

03

Payment providers & banks

Verified sandbox flow

Sandbox pilot
  1. iyzico
  2. Payment Intent · 100 TRY
  3. Hosted checkout
  4. Callback
  5. Authenticated retrieve
  6. SUCCEEDED

A real end-to-end sandbox payment through Payment OS. The card was entered on iyzico's hosted page, never in Payment OS.

01The system

Products shouldn't speak payment-provider APIs.

A product talks to one contract. Provider APIs, authentication, callback formats, status names and checkout behaviour all stay behind it.

01

Product

Any product that needs payments.

  • SaaS
  • Reservations & deposits
  • Commerce
  • Memberships
  • Marketplaces
  • Enterprise platforms

Create payment intent

Normalised payment state

02

Idealink Payment OS

One payment boundary.

  • Routing
  • Hosted payment flow
  • Provider adapters
  • Webhook handling
  • Idempotency
  • State normalisation

Route & hand off

Webhook / callback

03

Payment providers & banks

Provider-specific complexity stays here.

  • Payment service providersiyzico verified · PayTR in pilot
  • Hosted checkout providersCheckout Form · iFrame
  • Bank virtual POSAdapter target
  • Future payment railsExtensible
02One payment, end to end

What happens after a product asks to get paid.

  1. 01

    Intent

    The product creates a normalised payment intent: customer, basket and payment context, sent under an idempotency key. Card numbers and CVV are never part of the request.

    • PaymentIntent
    • Idempotency-Key

  2. 02

    Route

    Payment OS chooses the provider before any card is collected, using configured fees, explicit rules on currency, amount and an optional BIN prefix, and which provider connections are active. Every decision is stored with its reason.

    • RouteDecision
    • RoutingRule

  3. 03

    Collect

    The customer is sent to the selected provider's hosted payment page. The provider collects the card details; Payment OS never becomes the card vault.

    • Hosted checkout
    • No PAN · no CVV

  4. 04

    Verify

    Callbacks are matched to the payment attempt, checked against the provider's signature where the provider signs them, and safe to receive twice. The final state comes from an authenticated server-to-server retrieve where the provider allows it, never from the browser redirect.

    • WebhookEvent
    • Server-side retrieve

  5. 05

    Normalise

    Provider-specific statuses become one Payment OS state model. The product reads one vocabulary, whichever provider took the payment.

    • PaymentAttempt
    • SUCCEEDED
03Why this exists

We got tired of rebuilding payments inside every product.

  • A SaaS product needs a deposit.
  • Another product needs checkout.
  • A marketplace needs payment status.
  • An enterprise platform needs another provider.

Without a payment boundary, every product starts learning provider-specific APIs, callback formats, secrets and failure modes. Payment OS moves that complexity into one system.

Without Payment OS

  • Product Aiyzico
  • Product BPayTR
  • Product CBank A
  • Product DBank B

Each product owns

  • Credentials
  • Callbacks
  • Provider states
  • Retries
  • Security logic
  • Integration maintenance

With Payment OS

  • Product A
  • Product B
  • Product C
  • Product D

Idealink Payment OS

Providers / banks

One contract.Multiple adapters.

04The provider layer

Providers are adapters, not product architecture.

Every provider sits behind the same adapter interface. Each card states where that adapter is today.

  • Sandbox verified

    iyzico

    • Checkout Form, hosted by iyzico
    • Callback handling
    • Authenticated server-to-server retrieve
    • End-to-end sandbox payment completed
  • Pilot · adapter in progress

    PayTR

    • iFrame initialisation
    • Signed callback verification
    • End-to-end validation is the next step
  • Adapter target

    Bank virtual POS

    Payment OS is designed so direct bank integrations can live behind the same product-facing contract. No bank is integrated today.

  • Extensible

    More providers

    Provider-specific behaviour belongs in adapters, not inside every product that needs payments.

05The boundary

Route before the card.

Provider payment tokens are provider-bound. A token created by one processor cannot simply be replayed at another.

Silent cross-provider failover after card entry would need a different card-data and PCI architecture.

So Payment OS makes the routing decision before card collection, then hands control to the selected provider's hosted experience.

The boundary is deliberate.

  1. Routing decision
  2. Card entry
  3. Selected provider only
  4. No silent retry at another provider
06Architecture

Built as infrastructure, not checkout UI.

A modular monolith with a provider adapter layer, deliberately boring where payments need it to be.

Service
NestJS, Prisma and PostgreSQL in a modular monolith
Interface
REST API and inbound provider webhooks
Adapters
One provider interface: iyzico and PayTR adapters, plus mock providers for development
Idempotency
Every write carries an Idempotency-Key; the request hash is stored and a conflicting reuse is rejected
Credentials
Provider credentials encrypted with AES-256-GCM under a master key, never returned by the API
Access
API keys scoped to one merchant environment and stored hashed
Telemetry
Provider health from real attempts: success rate and latency, for operators
Tooling
A routing simulator that explains a decision without calling a provider

Domain records

  • PaymentIntent

    What the product wants to get paid

  • PaymentAttempt

    One try, at one provider

  • RouteDecision

    Which provider was chosen, and why

  • RoutingRule

    Merchant rules: currency, amount, BIN prefix

  • WebhookEvent

    Every inbound callback, stored

  • IdempotencyRecord

    Write once, replay safely

Tenancy

  1. Organization
  2. Merchant
  3. Environment

Sandbox and production are separate environments. Provider connections and API keys belong to one environment.

07Payment states

One state model, whichever provider took the payment.

Products reason about Payment OS states, not provider-specific vocabulary.

Path to success

  1. CREATED
  2. REQUIRES_PAYMENT_METHOD
  3. REQUIRES_ACTION
  4. PROCESSING
  5. SUCCEEDED

Terminal and later states

  • FAILED
  • CANCELLED
  • PARTIALLY_REFUNDED
  • REFUNDED

Refund states are part of the model today; refund execution is in development.

08Built for products

One layer. Different products.

Where a payment boundary fits. This describes architectural fit, not provider features available today.

  • Reservations & deposits

    Appointment or booking deposits without embedding payment-provider logic in the vertical product.

  • SaaS

    Central payment infrastructure shared across product modules.

  • Commerce

    Checkout flows without hard-coding the commerce product to a single provider.

  • Marketplaces

    One payment state model across complex workflows.

  • Memberships

    Recurring or one-off payment flows, as provider support evolves.

  • Enterprise systems

    Payment infrastructure behind operational software and its integrations.

09Current statusSandbox pilot

Where it stands today.

Transparency is part of the product. This is the state of the build, not a roadmap slide.

  • Verified:Payment intent and payment attempt models
  • Verified:Provider abstraction
  • Verified:Rule- and cost-based routing, decided before the card
  • Verified:Routing simulator
  • Verified:Idempotent API
  • Verified:Hosted payment handoff
  • Verified:Encrypted provider credentials
  • Verified:Normalised payment states
  • Verified:iyzico end-to-end sandbox payment
  • Verified:Signed callback verification for PayTR
  • In progress:PayTR dual-provider pilotend-to-end validation next
  • In progress:iyzico callback signature checkresults already come from an authenticated retrieve
  • In progress:Refunds and signed webhooks to productsin development
  • Planned / adapter target:Bank virtual POS adapters
  • Planned / adapter target:Production merchants
10Why Idealink built it

Built because our products needed it.

We build SaaS products, marketplaces, reservation systems and enterprise platforms. Payments kept appearing as the same problem with different provider APIs.

Instead of solving it again inside every product, we moved it behind one boundary. Payment OS is infrastructure we built from real product work.

See what else runs underneath Idealink