Provider listesiyle değil operating model ile başlayın
Tek provider kullanan bir şirketin ödeme operasyonları karmaşık olabilir; birden fazla provider kullanan başka bir şirket ise akışlar dar ve stabilse basit kalabilir. Bu nedenle provider count tek başına zayıf bir architecture criterion'dır. Daha doğru sorular; payment state, routing policy, retry, credential, observability, settlement interpretation ve exit path'in kimin sorumluluğunda olduğudur.
Bu yüzden matristeki dört model ownership model olarak okunmalıdır. Tek PSP internal surface area'yı küçültür. Direct multi-PSP provider optionality sağlar fakat normalization yükünü kuruma taşır. Orchestration platform ortak payment logic'i ayrı bir katmanda toplar. In-house payment platform ise bu katmanı kalıcı internal capability'ye dönüştürür.
Complexity gerçekten düşükse Tek PSP geçerli bir mimaridir
Tek ana PSP kullanmak mimari hata değildir. Geographic coverage, payment method, reliability, commercial terms ve operational requirements tek provider tarafından yeterince karşılanıyorsa en verimli tercih olabilir. Connector maintenance azalır ve product requirement'tan production'a giden yol genellikle kısalır.
Sınır concentration'dır. Application state zamanla provider-specific semantics emebilir, token reference taşınması zorlaşabilir ve retry, reconciliation veya regional behavior tek API'ye sıkı bağlanabilir. Doğru kontrol ikinci provider'ı gereksiz yere eklemek değil, dependency pahalılaşmadan switching boundary'yi anlamaktır.
Doğrudan multi-PSP vendor concentration'ı internal complexity ile değiştirir
Direct integration, hangi provider'ın payment execute edeceği üzerinde kuruma kontrol verir ve regional veya method coverage'ı artırabilir. Ayrıca traffic'i bağımsız yönlendirme ve pazarlık esnekliği sağlar. Ancak her provider farklı authentication, state model, idempotency behavior, webhook semantics, reporting structure ve settlement evidence getirir.
Bilinçli common model yoksa application orchestration layer'a kazara dönüşür. Routing rule checkout code'a sızar, recovery branch connector'a göre değişir ve finance operations birden fazla uyumsuz transaction vocabulary ile uğraşır. Direct multi-PSP, ekip provider abstraction'ı gerçekten sahipleniyorsa iyi çalışır.
Orchestration platformu ortak payment sorumluluklarını merkezileştirir
Ayrı orchestration layer; provider selection, routing policy, normalized payment state, retry behavior ve observability'yi tek tek kanallardan çıkarabilir. Böylece checkout, mobile, marketplace veya dealer flow'larında duplicate logic azalır ve yeni provider eklenirken her upstream system'e yeni API öğretilmez.
Trade-off, orchestration layer'ın kendisinin infrastructure olmasıdır. Data model, token strategy, credentials, event model, reliability ve commercial terms önem taşır. Değerlendirme yalnız connector sayısına değil; payment identity portability, raw provider evidence erişimi, failure explainability ve credible exit path'e bakmalıdır.
Kurum içi payment platformu proje değil product commitment'tır
Internal payment platform; payment behavior anlamlı bir differentiation kaynağıysa, scale dedicated team'i haklı çıkarıyorsa veya external platformların sağlayamadığı kontrol gerekiyorsa rasyonel olabilir. Capability; provider abstraction, routing, policy execution, token strategy, recovery, telemetry, reconciliation interface ve operational tooling içerebilir.
Kritik kelime kalıcıdır. Diğer ürünler platforma bağlandığında versioning, provider change, on-call, security, observability, certification ve financial-operations support sürekli sorumluluğa dönüşür. Build kararı ilk iki connector'ı çıkarmanın maliyetiyle değil yıllarca ownership ile değerlendirilmelidir.
Routing control ancak gerçek feedback loop varsa değer yaratır
Routing engine cost, geography, payment method, risk signal veya provider health kullanabilir. Fakat rule'un değeri outcome data ile ölçüldüğü kadardır. Authorization success tek başına yeterli değildir; seçilen route daha fazla retry, fee, kötü settlement economics veya operational exception yaratabilir.
Hangi architecture seçilirse seçilsin mature routing eventually realized feedback ister: provider execution, recovery, settlement, fee, dispute ve reconciliation outcome. Bu nedenle orchestration ve financial operations ayrı feature listeleri değil bağlı domain'ler olarak tasarlanmalıdır.
Recovery semantics modeller arasındaki gizli farktır
Timeout ve ambiguous provider response mimariyi hızla test eder. Single-provider modelde ekip tek provider'ın idempotency ve lookup semantiğini izler. Birden fazla provider'da bu semantik değişir ve aynıymış gibi davranmadan normalize edilmelidir. Generic HTTP retry yeterli değildir çünkü financial side effect zaten gerçekleşmiş olabilir.
Orchestration veya in-house platform recovery'yi ancak stable business identity altında provider-aware behavior'ı korursa merkezileştirebilir. Ana soru sistemin unknown state'i temsil edip edemediği, provider state'i güvenle recover edip edemediği ve ilk response kayboldu diye ikinci financial action yaratıp yaratmadığıdır.
Execution'ın parçası olmasa da reconciliation karara dahildir
Payment execution ile financial truth farklı domain'lerdir ancak architecture choice bunları bağlamanın maliyetini değiştirir. Tek provider daha az external report formatı demektir. Direct multi-PSP settlement ve fee model sayısını artırır. Orchestration layer payment identity'yi normalize edebilir fakat finance'ın reconciliation için ihtiyaç duyduğu underlying evidence'i silmemelidir.
Bu nedenle decision matrix reconciliation'ı operating-model dimension olarak ele alır. Soru payment layer'ın accounting yapıp yapmadığı değil; her execution attempt'in provider record, settlement, payout ve internal financial record'a manuel reconstruction olmadan bağlanıp bağlanamadığıdır.
Security scope'u checkbox değil boundary olarak değerlendirin
Provider architecture credential, token ve potansiyel sensitive payment data'nın nerede dolaştığını değiştirir. PCI Security Standards Council guidance, segmentation ve connected-system scope'u doğrudan architectural concern haline getirir. Internal abstraction layer kontrolü artırabilir; fakat provider-managed component içinde kalan veriyi işlemeye başlarsa security responsibility de büyüyebilir.
Her seçenek için data flow ve trust boundary çizilmelidir. Hosted collection, tokenization ve provider-managed surface entegrasyon modeline göre exposure'ı azaltabilir; deeply owned platform ise daha fazla kontrol karşılığında daha yüksek operational responsibility getirir.
Son karar testi olarak reversibility kullanın
Model seçmeden önce kurumun modelden nasıl çıkacağını tarif edin. Tek PSP'de token, recurring mandate, historical transaction ve business logic migration'ını sorun. Direct multi-PSP'de abstraction'ın gerçek olup olmadığını test edin. Orchestration platformunda credential, token reference, event history ve routing configuration ownership'ını sorun.
Internal platformda reversibility farklıdır: capability dependent product'ları dondurmadan evrilebilir mi ve tek tek provider'lar business semantics değişmeden replace edilebilir mi? Güçlü mimari switching cost'u yok etmez; görünür kılar ve maliyeti yapılan değişiklikle orantılı tutar.
Connector count veya feature listesi karşılaştırmadan önce payment operating model'i seçin.
Complexity gerçekten düşükse single PSP verimlidir; kontrol ihtiyacı yokken provider eklemek gereksiz infrastructure yaratır.
Direct multi-PSP optionality'yi artırır fakat provider abstraction, recovery ve reconciliation'ı internal responsibility yapar.
Orchestration platformu infrastructure'dır; connector kadar portability, evidence access ve exit path ile değerlendirilmelidir.
In-house payment platform ancak kalıcı ownership stratejik değer yaratıyorsa anlamlıdır.
Her modeli reversibility, recovery, financial operations ve security boundary açısından değerlendirin.