MagicPay tarafından hazırlanan bu rehber, ödeme altyapısı seçen işletmelerin bağlantı ile karar ve operasyon katmanlarını ayırmasına yardımcı olur. Tek bir ödemenin sağlayıcıya ulaşmasından kesin sonucunun sipariş ve finans kayıtlarına işlenmesine kadar sorulması gereken soruları ele alır. MagicPay'in teknoloji sağlayıcı bakışını yansıtır; ürün seçimi için bir karar çerçevesidir.
1. Bağlantı ile koordinasyonu işlev üzerinden ayırın
Payment gateway, işletmenin ödeme isteğini sağlayıcının anlayacağı biçime dönüştüren, ileten ve yanıtı geri taşıyan bağlantı katmanıdır. Ödeme orkestrasyonu ise hangi uygun bağlantının kullanılacağını, sonuca göre ne yapılacağını ve sürecin nasıl izleneceğini koordine eder. Bunlar birbirini dışlayan ürün sınıfları değildir: bir gateway yönlendirme ve operasyon işlevleri de sunabilir. Sınırı ürün adından değil, her adımın sorumlusundan okuyun.
- Bağlantı sorusu: İstek hangi sözleşmeyle, hangi sağlayıcıya iletiliyor?
- Orkestrasyon sorusu: Bu seçim neden yapıldı ve sonraki adımı hangi sonuç belirliyor?
2. Bir siparişin ödeme yolculuğunu çizin
Önce sipariş ve ödeme referansı oluşturulur; ardından uygun bağlantı seçilir ve istek iletilir. Akışa göre müşteri kimlik doğrulamasına yönlendirilebilir; sonuç hemen gelebilir veya beklemede kalabilir. Müşterinin dönüş sayfasına ulaşması tek başına kesin ödeme sonucu sayılmaz. Sağlayıcının doğrulanmış sunucu bildirimi veya belgelenmiş durum sorgusu ödeme durumuna işlenir. Yetkilendirme, tahsilatın kesinleşmesi ve paranın hesaba aktarılması ayrı aşamalar olabilir; sipariş teslim kuralını doğru aşamaya bağlayın.
3. Routing kararına uygunluk koşullarıyla başlayın
Routing, deneme başlamadan önce hangi sağlayıcının kullanılacağını belirler. Para birimi, ödeme yöntemi, üye işyeri hesabı ve sağlayıcı sözleşmesi önce uygun seçenekleri sınırlar; öncelik veya maliyet kuralı bu seçenekler içinde uygulanır. Birden fazla bağlantının bulunması tek başına kullanılabilir yedek olduğu anlamına gelmez. Bir yönlendirme kuralını değerlendirirken hangi koşullarda çalıştığını, kararı nerede göreceğinizi ve hatalı kuralı kimin geri alacağını sorun.
4. Retry öncesinde belirsiz sonucu çözün
Zaman aşımı, sağlayıcının isteği işlemediğini kanıtlamaz. Önce mevcut denemeyi kaydedin; sağlayıcı referansıyla durum sorgulayın veya doğrulanmış bildirimi bekleyin. Sonuç belirsizken başka sağlayıcıya yeni tahsilat göndermek iki başarılı ödemeye yol açabilir. Aynı isteğin teknik tekrarında sağlayıcının idempotency sözleşmesine uyun: aynı işlem anahtarı ve aynı parametreler, yalnız desteklenen kapsam ve süre içinde kullanılmalıdır. Bir sağlayıcıdaki anahtar diğer sağlayıcıdaki işlemi tekilleştirmez.
- Geçici iletişim hatası ile kesin ret sonucunu ayrı ele alın; her ret tekrar denenebilir değildir.
- Yeni denemeyi ancak önceki sonucun ve sağlayıcı kurallarının izin verdiği durumda başlatın; deneme sayısı ve bekleme sınırını belirleyin.
- Belirsizlik sürüyorsa işlemi inceleme kuyruğuna alın; yeni anahtar üretmek sonucu çözmez.
5. Operasyon kaydını tahsilat yanıtından ayrı tasarlayın
Sipariş referansı, her denemenin kimliği, sağlayıcı referansı, tutar, para birimi, karar nedeni ve durum geçişleri birlikte izlenebilmelidir. Bildirimlerin doğruluğunu sağlayıcının yöntemine göre kontrol edin; yinelenen veya sırası değişen bildirimlerin siparişi ikinci kez kapatmasını önleyin. Bu izleme kaydı muhasebe defterinin veya banka mutabakatının yerine geçmez. İade talebi ile tamamlanmış iadeyi, başarılı tahsilat ile hesaba geçen tutarı ayrı izleyin; sipariş, sağlayıcı ve finans kayıtları arasındaki farklara sorumlu atayın.
6. İhtiyacınız olan katmanı iş yüküne göre seçin
Tek sağlayıcılı, açık durum akışı olan bir işletmede bağlantı ve temel durum takibi yeterli olabilir. Birden fazla sağlayıcı, değişen yönlendirme kuralları, belirsiz işlem kuyruğu veya dağınık iade takibi varsa orkestrasyon sorumluluklarını ayrıca değerlendirin. Daha fazla katman her zaman daha iyi çözüm değildir; kural yönetimi ve yeni hata noktaları da getirir. Kararı ürün etiketine değil, ekibin bugün elle yürüttüğü işe ve sahiplenebileceği operasyon yüküne bağlayın.
- Hangi kararlar bugün elle veriliyor ve hangi veriye dayanıyor?
- Bir işlem beklemede kaldığında ekip nereden başlayıp kime başvuruyor?
- Sağlayıcı eklenmesi sipariş ve finans süreçlerinde neyi değiştiriyor?
7. Geçişi yeni bağlantıdan önce mevcut işlemlerle sınayın
Mevcut referansları, açık ödemeleri, iade akışlarını ve kayıtların dışa aktarımını envanterleyin. Saklanan ödeme araçlarının taşınabilirliğini varsaymayın; token kapsamını ve gerekli izinleri ilgili sağlayıcıyla doğrulayın. Önce aynı test siparişinde başarı, kesin ret, zaman aşımı, geç bildirim ve yinelenen bildirim senaryolarını çalıştırın. Geri dönüşte açık denemelerin kimde izleneceğini belirleyin. Gölge değerlendirme yalnız kararları karşılaştırmalı; aynı canlı sipariş için iki ayrı tahsilat başlatmamalıdır.
- Eski sistemde kalan ödemelerin sorgu, iade ve mutabakat sorumlusu kim?
- Hangi ölçüt geçişi durduracak ve kuralı veya bağlantıyı geri aldıracak?
- Operasyon ekibi örnek bir işlemi siparişten finans kaydına kadar izleyebiliyor mu?
8. MagicGate'i bu çerçevede değerlendirin
MagicPay'in B2B teknoloji altyapısı MagicGate, sağlayıcı bağlantısı ile ödeme orkestrasyonunu birlikte kapsar. Bu nedenle burada anlatılan genel ayrım, MagicGate'i yalnız bağlantı yapan bir ürün olarak sınırlamaz. Projenizi değerlendirirken kullanılacak bağlantıları, yönlendirme ve retry koşullarını, sorgu akışını ve operasyon kaydını somut bir sipariş üzerinde netleştirin. Para hareketini yürüten yetkili kuruluşun rolü, hesaplar ve sözleşmeler ayrıca belirlenmelidir; teknoloji katmanını bu rolün yerine koymayın.