Routing Strategy Derinlemesine
Confirm sırasında sağlayıcı seçimi, aday sıralaması ve fallback davranışı.
Confirm çağrısında hangi sağlayıcının deneneceğini routing_strategy (isteğe bağlı API alanı) ve hesap ayarlarınız birlikte belirler. Bu alan ayrı bir "Strategy Execution" ürün adımı değildir; routing plan oluşturulduktan sonra her aday için provider adapter çalışır. Amaç tek bir if-else değil; denemelerin sıralı, izlenebilir ve gerektiğinde yedeklenebilir olmasıdır.
Strateji nasıl gönderilir?
Confirm gövdesinde routing_strategy şu iki formdan birini alır:
| Alan | Anlam |
|---|---|
payment_provider_config_id | Tek config ile net yönlendirme, veya en az iki config ile sıralı aday listesi |
provider_identifier | Tek sağlayıcı kimliği, veya en az iki kimlik ile sıralı aday listesi |
Strateji göndermezseniz hesabın varsayılan havuzu ve fallback kuralları devreye girer.
Çoklu ID verdiğinizde sıra önemlidir: adaylar genelde verdiğiniz sırayla işlenir.
Aday listesi nasıl oluşur?
Özet akış:
- Ödeme ve ödeme yöntemi ile uyumlu sağlayıcı havuzu çıkarılır.
- Uyumsuz adaylar elenir.
- İstekte dar bir liste yoksa hesap fallback politikası geniş havuza bakabilir.
- Sonuç, confirm sırasında oluşan routing plan kaydına yansır.
Plan; hangi adayın kaçıncı sırada denendiğini operasyon ve dashboard tarafında takip etmenizi sağlar.
Tek aday ve çoklu aday
- Tek config veya tek provider: Doğrudan o yolu hedeflersiniz; uygunluk yoksa confirm hata veya
REQUIRES_PAYMENT_METHODile dönebilir. - Birden fazla config veya provider: Sıralı deneme modeli; ilk deneme başarısız veya “yumuşak” decline ise sıradaki adaya geçilebilir (kurallar aday havuzuna bağlıdır).
Dashboard’da routing_origin alanı son confirm’in merchant-direct mi, autopilot benzeri çoklu aday mı olduğunu özetler.
Fallback ne zaman devreye girer?
Confirm’te verdiğiniz dar liste boş kalırsa veya hiç strateji göndermemişseniz, hesap seviyesindeki uygun config havuzu devreye girebilir. Bu, kesinti anında ödeme almayı sürdürmeye yardımcı olur; raporlamada fallback kullanımını ayrı izlemeniz iyi olur.
Operasyonel öneriler
- Routing plan ve charge attempt’leri birlikte okuyun; tek payment altında birden fazla deneme normaldir.
- Başarı oranı ve gecikmeyi sağlayıcı bazında takip edin.
- Fallback oranını ayrı metrik yapın; sürekli fallback konfigürasyon sorununa işaret edebilir.