İşler · Ödeme / Orkestrasyon / Altyapı
Payment OS
Tek ödeme katmanı. Birden fazla sağlayıcı.
Nedir
Payment OS bir ödeme orkestrasyon katmanı: işletme bir ödeme niyeti oluşturur, katman sağlayıcıyı kurallara ve maliyete göre seçer, kart tahsilatını sağlayıcının barındırdığı sayfaya devreder ve sonucu normalize eder. Bugün iyzico ve PayTR ile.
Neden gerekliydi
İşletmeler sağlayıcı mantığı her değiştiğinde ödeme sayfasını yeniden yazar ve iki entegrasyon yürütmeden sağlayıcıları karşılaştıramaz. Sağlayıcıya özgü davranış tek bir sözleşmenin arkasına aittir.
Idealink ne yaptı
Idealink servisi NestJS ve PostgreSQL üzerinde modüler bir monolit olarak tasarladı ve geliştirdi, iki sağlayıcıyı da entegre etti ve uçtan uca gerçek bir sandbox ödemesi kanıtladı. Dahili pilot olarak çalışıyor; henüz üretimde değil.
- Durum
- Sandbox pilotu
- İlişki
- Idealink girişimi
- Sektör
- Ödemeler
- Dönem
- 2026 — sandbox pilotu
- Platform
- API
- Idealink'in rolü
- Mimari, backend mühendisliği, sağlayıcı entegrasyonları
Tez
Ödeme sayfasının kodu, bir ödemeyi hangi işlemcinin gerçekleştirdiğini bilmek zorunda olmamalı. Payment OS bir mimari hikâyesi: kart alınmadan önce yönlendiren ve kart verisine asla dokunmayan bir sağlayıcı soyutlaması.
01
Bir ödeme, uçtan uca
v0.5'in bugün yaptıkları, sırasıyla.
Niyet
İşletme, normalize müşteri ve sepet verisiyle bir ödeme niyetini idempotency anahtarı altında gönderir. API'de ham kart verisi yasaktır.
Yönlendir
Deterministik kurallar ve yapılandırılmış maliyet tabloları, herhangi bir kart alınmadan önce sağlayıcıyı seçer; performansı düşen sağlayıcılar dışarıda bırakılır.
Tahsil et
Seçilen sağlayıcının barındırdığı sayfa (iyzico Checkout Form ya da PayTR iFrame) kartı alır. Token'lar sağlayıcıya bağlı kalır.
Geri çağrı
İmzalı geri çağrılar doğrulanır, denemeyle ilişkilendirilir ve tekilleştirilir; sonuçlar sunucu tarafında çekilir, tarayıcıdan asla güvenilmez.
Normalize et
Niyet ve deneme durumları, yönlendirme kararları ve temel sağlayıcıya göre tahmini tasarruf tek bir kayıtta tutulur.
02
Mimari
- Servis
- PostgreSQL üzerinde NestJS + Prisma, modüler monolit
- Model
- PaymentIntent ve PaymentAttempt ayrı; RouteDecision, RoutingRule, WebhookEvent ve IdempotencyRecord birinci sınıf kayıtlar
- Durumlar
- Oluşturuldu, ödeme yöntemi gerekli, işlem gerekli, işleniyor, başarılı, başarısız, iptal, kısmi iade, iade
- Kiracılık
- Kuruluş → işletme → ortam; API anahtarları ortam bazında kapsamlı
- Sırlar
- Sağlayıcı kimlik bilgileri bir ana anahtar altında AES-256-GCM ile şifreli
- Sağlayıcılar
- iyzico Checkout Form (uçtan uca sandbox ödemesi kanıtlandı), PayTR iFrame V2 (başlatma ve imzalı geri çağrı doğrulaması)
- Araçlar
- Sağlayıcı çağrısı olmadan yönlendirme simülatörü; başarı ve gecikme telemetrisiyle sağlayıcı sağlığı
- Sınır
- PAN ve CVV sisteme asla girmez; sağlayıcılar arası kart failover iddiası yok
03
Yönlendirme neden karttan önce
Sağlayıcı token'ları sağlayıcıya bağlıdır: bir işlemciden alınan token başka birinde tekrar kullanılamaz. Kart girişinden sonra sessiz failover bir kasa ya da tam bir PCI kart verisi mimarisi gerektirir; bu yüzden v0.5 çizgiyi bilinçli çeker: önce ücrete, BIN ailesine ve sağlayıcı sağlığına göre yönlendir, sonra devret.
Her yönlendirme kararı temel maliyeti, seçilen maliyeti ve tahmini tasarrufu saklar; böylece katman, bir işletme için önemli olan tek soruyu yanıtlayabilir: yönlendirme ne kazandırdı.
Sağlayıcıya özgü ödeme mantığı tek bir orkestrasyon katmanının arkasında durur; ödeme sayfasının kodunun hangi işlemcinin ödemeyi gerçekleştirdiğini anlaması gerekmez.
Sonuç
Bugün nerede
Gerçek bir iyzico sandbox ödemesi Payment OS üzerinden uçtan uca tamamlandı (niyet, barındırılan ödeme sayfası, geri çağrı, kimlikli sorgu, başarılı) ve PayTR ile çift sağlayıcılı pilot sürüyor.
Durum açık: sandbox pilotu. Üretim trafiği, işletme ya da PayTR uçtan uca tamamlama iddiası yok.
Teknoloji ve yetkinlikler
Yalnızca gerekenler
- NestJS
- Prisma
- PostgreSQL
- iyzico
- PayTR
- AES-256-GCM