İçeriğe geç

Ödeme · Orkestrasyon · Altyapı

Tek ödeme katmanı.Tüm ürünler.

Ürünler bir kez entegre olur. Idealink Payment OS; sağlayıcı yönlendirmesini, barındırılan ödeme akışlarını, callback ve webhook işlemlerini ve ödeme durumlarının normalleştirilmesini tek sözleşmenin arkasında yönetir.

Ödeme kuruluşları, banka sanal POS entegrasyonları ve ileride eklenecek ödeme kanalları için tasarlandı.

Nasıl çalıştığını görün
Idealink ile konuşun
Sandbox pilot

01

Ürün

Payment Intent oluştur

Normalleştirilmiş ödeme durumu

02

Idealink Payment OS

Yönlendir & devret

Webhook / callback

03

Ödeme kuruluşları & bankalar

Doğrulanmış sandbox akışı

Sandbox pilot
  1. iyzico
  2. Payment Intent · 100 TRY
  3. Barındırılan ödeme ekranı
  4. Callback
  5. Kimliği doğrulanmış sorgu
  6. SUCCEEDED

Payment OS üzerinden uçtan uca gerçek bir sandbox ödemesi. Kart bilgisi iyzico'nun barındırdığı ekranda girildi; Payment OS'a hiç girmedi.

01Sistem

Ürünler ödeme sağlayıcılarının dilini konuşmak zorunda değil.

Ürün tek bir sözleşmeyle konuşur. Sağlayıcı API'leri, kimlik doğrulama, callback biçimleri, durum adları ve ödeme ekranı davranışları bu sözleşmenin arkasında kalır.

01

Ürün

Ödeme alması gereken her ürün.

  • SaaS
  • Rezervasyon & ön ödeme
  • E-ticaret
  • Üyelikler
  • Pazar yerleri
  • Kurumsal platformlar

Payment Intent oluştur

Normalleştirilmiş ödeme durumu

02

Idealink Payment OS

Tek ödeme sınırı.

  • Yönlendirme
  • Barındırılan ödeme akışı
  • Sağlayıcı adaptörleri
  • Webhook / callback işleme
  • Idempotency
  • Durum normalleştirme

Yönlendir & devret

Webhook / callback

03

Ödeme kuruluşları & bankalar

Sağlayıcıya özgü karmaşıklık burada kalır.

  • Ödeme kuruluşlarıiyzico doğrulandı · PayTR pilotta
  • Barındırılan ödeme ekranlarıCheckout Form · iFrame
  • Banka sanal POSAdaptör hedefi
  • Gelecek ödeme kanallarıGenişletilebilir
02Uçtan uca bir ödeme

Bir ürün ödeme istediğinde neler olur?

  1. 01

    Niyet

    Ürün, normalleştirilmiş bir Payment Intent oluşturur: müşteri, sepet ve ödeme bağlamı bir idempotency anahtarıyla gönderilir. Kart numarası ve CVV isteğin hiçbir parçası değildir.

    • PaymentIntent
    • Idempotency-Key

  2. 02

    Yönlendirme

    Payment OS, kart bilgisi alınmadan önce sağlayıcıyı seçer: tanımlı komisyonlara, para birimi, tutar ve isteğe bağlı BIN önekine dayanan açık kurallara ve hangi sağlayıcı bağlantılarının aktif olduğuna bakarak. Her karar gerekçesiyle kaydedilir.

    • RouteDecision
    • RoutingRule

  3. 03

    Tahsilat

    Müşteri, seçilen sağlayıcının barındırdığı ödeme ekranına yönlendirilir. Kart bilgisini sağlayıcı alır; Payment OS hiçbir zaman kart kasasına dönüşmez.

    • Barındırılan ödeme ekranı
    • PAN yok · CVV yok

  4. 04

    Doğrulama

    Callback'ler ilgili ödeme denemesiyle eşleştirilir, sağlayıcı imzalıyorsa imzası kontrol edilir ve iki kez gelmesi sorun yaratmaz. Nihai durum, sağlayıcının izin verdiği yerde kimliği doğrulanmış sunucudan sunucuya bir sorguyla alınır; tarayıcı yönlendirmesine asla güvenilmez.

    • WebhookEvent
    • Sunucu tarafı sorgu

  5. 05

    Normalleştirme

    Sağlayıcıya özgü durumlar tek bir Payment OS durum modeline dönüşür. Ödemeyi hangi sağlayıcı almış olursa olsun ürün tek bir sözlük okur.

    • PaymentAttempt
    • SUCCEEDED
03Neden var

Ödemeyi her üründe yeniden kurmaktan yorulduk.

  • Bir SaaS ürününün ön ödemeye ihtiyacı var.
  • Bir diğerinin ödeme ekranına.
  • Bir pazar yerinin ödeme durumuna.
  • Bir kurumsal platformun başka bir sağlayıcıya.

Bir ödeme sınırı olmadan her ürün sağlayıcıya özgü API'leri, callback biçimlerini, gizli anahtarları ve hata senaryolarını yeniden öğrenmeye başlar. Payment OS bu karmaşıklığı tek bir sisteme taşır.

Payment OS olmadan

  • Ürün Aiyzico
  • Ürün BPayTR
  • Ürün CBanka A
  • Ürün DBanka B

Her ürün kendisi taşır

  • Kimlik bilgileri
  • Callback'ler
  • Sağlayıcı durumları
  • Yeniden denemeler
  • Güvenlik mantığı
  • Entegrasyon bakımı

Payment OS ile

  • Ürün A
  • Ürün B
  • Ürün C
  • Ürün D

Idealink Payment OS

Sağlayıcılar / bankalar

Tek sözleşme.Birden çok adaptör.

04Sağlayıcı katmanı

Sağlayıcılar adaptördür; ürün mimarisi değil.

Her sağlayıcı aynı adaptör arayüzünün arkasında durur. Her kart, o adaptörün bugün nerede olduğunu söyler.

  • Sandbox'ta doğrulandı

    iyzico

    • iyzico'nun barındırdığı Checkout Form
    • Callback işleme
    • Kimliği doğrulanmış sunucudan sunucuya sorgu
    • Uçtan uca sandbox ödemesi tamamlandı
  • Pilot · adaptör geliştiriliyor

    PayTR

    • iFrame başlatma
    • İmzalı callback doğrulaması
    • Sıradaki adım uçtan uca doğrulama
  • Adaptör hedefi

    Banka sanal POS

    Payment OS, doğrudan banka entegrasyonlarının da ürünlere dönük aynı sözleşmenin arkasında yaşayabileceği şekilde tasarlandı. Bugün entegre bir banka yok.

  • Genişletilebilir

    Diğer sağlayıcılar

    Sağlayıcıya özgü davranış adaptörlere aittir; ödeme alan her ürünün içine değil.

05Sınır

Yönlendirme karttan önce.

Sağlayıcıların ödeme token'ları o sağlayıcıya bağlıdır. Bir işlemcinin ürettiği token başka bir işlemcide öylece yeniden kullanılamaz.

Kart bilgisi girildikten sonra fark ettirmeden başka bir sağlayıcıya geçmek, bambaşka bir kart verisi ve PCI mimarisi gerektirir.

Bu yüzden Payment OS yönlendirme kararını kart bilgisi alınmadan önce verir, sonra kontrolü seçilen sağlayıcının barındırdığı ödeme deneyimine bırakır.

Bu sınır bilinçli.

  1. Yönlendirme kararı
  2. Kart girişi
  3. Yalnızca seçilen sağlayıcı
  4. Başka sağlayıcıda sessiz yeniden deneme yok
06Mimari

Ödeme ekranı değil, altyapı olarak kuruldu.

Sağlayıcı adaptör katmanına sahip modüler bir monolit; ödemenin gerektirdiği yerlerde bilerek sıkıcı.

Servis
Modüler monolit olarak NestJS, Prisma ve PostgreSQL
Arayüz
REST API ve sağlayıcılardan gelen webhook'lar
Adaptörler
Tek sağlayıcı arayüzü: iyzico ve PayTR adaptörleri, geliştirme için mock sağlayıcılar
Idempotency
Her yazma isteği bir Idempotency-Key taşır; istek özeti saklanır, çelişen tekrar kullanım reddedilir
Kimlik bilgileri
Sağlayıcı kimlik bilgileri bir ana anahtarla AES-256-GCM ile şifrelenir; API hiçbir zaman geri döndürmez
Erişim
API anahtarları tek bir satıcı ortamına bağlıdır ve özetlenmiş olarak saklanır
Telemetri
Gerçek denemelerden sağlayıcı sağlığı: başarı oranı ve gecikme, operatörler için
Araçlar
Sağlayıcıyı çağırmadan bir kararı açıklayan yönlendirme simülatörü

Alan kayıtları

  • PaymentIntent

    Ürünün tahsil etmek istediği ödeme

  • PaymentAttempt

    Tek bir sağlayıcıda tek bir deneme

  • RouteDecision

    Hangi sağlayıcı seçildi ve neden

  • RoutingRule

    Satıcı kuralları: para birimi, tutar, BIN öneki

  • WebhookEvent

    Gelen her callback, saklanmış

  • IdempotencyRecord

    Bir kez yaz, güvenle tekrarla

Çoklu kiracılık

  1. Organization
  2. Merchant
  3. Environment

Sandbox ve canlı ortam birbirinden ayrıdır. Sağlayıcı bağlantıları ve API anahtarları tek bir ortama aittir.

07Ödeme durumları

Ödemeyi hangi sağlayıcı alırsa alsın tek durum modeli.

Ürünler sağlayıcıya özgü terimlerle değil, Payment OS durumlarıyla düşünür.

Başarıya giden yol

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

Son ve sonraki durumlar

  • FAILED
  • CANCELLED
  • PARTIALLY_REFUNDED
  • REFUNDED

İade durumları bugün modelin parçası; iade işlemleri geliştiriliyor.

08Ürünler için

Tek katman. Farklı ürünler.

Bir ödeme sınırının nerelere oturduğu. Bu bölüm mimari uyumu anlatır; bugün kullanılabilen sağlayıcı özelliklerini değil.

  • Rezervasyon & ön ödeme

    Randevu ya da rezervasyon ön ödemeleri, ödeme kuruluşu mantığını dikey ürünün içine gömmeden.

  • SaaS

    Ürün modülleri arasında paylaşılan merkezi ödeme altyapısı.

  • E-ticaret

    E-ticaret ürününü tek bir sağlayıcıya sabitlemeyen ödeme akışları.

  • Pazar yerleri

    Karmaşık iş akışlarında tek bir ödeme durum modeli.

  • Üyelikler

    Sağlayıcı desteği geliştikçe tekrarlayan ya da tek seferlik ödeme akışları.

  • Kurumsal sistemler

    Operasyon yazılımlarının ve entegrasyonlarının arkasındaki ödeme altyapısı.

09Güncel durumSandbox pilot

Bugün nerede?

Şeffaflık ürünün parçası. Bu bir yol haritası slaytı değil, geliştirmenin bugünkü hâli.

  • Doğrulandı:Payment Intent ve Payment Attempt modelleri
  • Doğrulandı:Sağlayıcı soyutlaması
  • Doğrulandı:Karttan önce verilen kural ve maliyet tabanlı yönlendirme
  • Doğrulandı:Yönlendirme simülatörü
  • Doğrulandı:Idempotent API
  • Doğrulandı:Barındırılan ödeme ekranına devir
  • Doğrulandı:Şifrelenmiş sağlayıcı kimlik bilgileri
  • Doğrulandı:Normalleştirilmiş ödeme durumları
  • Doğrulandı:iyzico ile uçtan uca sandbox ödemesi
  • Doğrulandı:PayTR için imzalı callback doğrulaması
  • Geliştiriliyor:PayTR ile çift sağlayıcı pilotusırada uçtan uca doğrulama var
  • Geliştiriliyor:iyzico callback imza kontrolüsonuçlar zaten kimliği doğrulanmış sorgudan geliyor
  • Geliştiriliyor:İadeler ve ürünlere giden imzalı webhook'largeliştiriliyor
  • Planlandı / adaptör hedefi:Banka sanal POS adaptörleri
  • Planlandı / adaptör hedefi:Canlı satıcılar
10Idealink neden kurdu

Kendi ürünlerimiz ihtiyaç duyduğu için kurduk.

SaaS ürünleri, pazar yerleri, rezervasyon sistemleri ve kurumsal platformlar geliştiriyoruz. Ödeme her seferinde aynı problem olarak karşımıza çıktı; yalnızca sağlayıcı API'leri değişiyordu.

Onu her üründe yeniden çözmek yerine tek bir sınırın arkasına taşıdık. Payment OS, gerçek ürün işinden doğan bir altyapı.

Idealink'in görünmeyen tarafında çalışan diğer sistemler