iyzico, PayTR, Param ve global ödeme sağlayıcısını aynı SaaS'ta nasıl konumlandırırım?

Türkiye ve global pazarı aynı üründe hedeflediğinizde ödeme mimarisi hızla karışabilir. En tehlikeli yaklaşım her sağlayıcının ürün ID'sini uygulamanın her yerine yaymaktır.

Domain'in para sağlayıcısını bilmesine gerek yok

Uygulamanın gerçek sorusu "bu kullanıcı Pro mu?" olmalıdır; "iyzico'da hangi paket ID'sini aldı?" değil. Sağlayıcı verisini billing katmanında normalize ederim.

Önerilen katmanlar

1. Checkout router: ülke, para birimi ve satış kanalına göre uygun checkout'u seçer. 2. Provider adapter: iyzico, PayTR, Param veya global sağlayıcının API/webhook farklarını izole eder. 3. Billing event store: ödeme, yenileme, iptal, refund gibi olayları canonical formata çevirir. 4. Entitlement service: kullanıcı hangi özelliklere erişebilir sorusunun tek kaynak doğrusudur. 5. Reconciliation job: sağlayıcı ile iç kayıtların uyuşup uyuşmadığını düzenli kontrol eder.

Webhook idempotency zorunlu

Aynı ödeme olayı iki kez gelebilir. Webhook'u "geldiyse uygula" mantığıyla yazmak duplicate entitlement veya yanlış muhasebe kaydı doğurabilir. Provider event ID + işlem tipi ile idempotent kayıt tutmak gerekir.

Yerel ve global checkout'u ayır, hesabı ayırma

Türkiye kullanıcısı yerel sağlayıcıdan TL ödeyebilir; global kullanıcı Merchant of Record üzerinden USD/EUR ödeyebilir. Fakat ikisi de aynı account_id ve aynı entitlement modeline bağlanmalıdır.

Sağlayıcı değiştirme testi

Yeni bir ödeme sağlayıcısı eklemek için ürün kodunun büyük bölümünü değiştirmek gerekiyorsa ödeme sınırı yanlış yerde demektir.

Çoklu ödeme mimarisinin amacı daha fazla sağlayıcı kullanmak değil, ödeme kanalının ürün erişim mantığını ele geçirmesini önlemektir.