HSRC Pay Genel Bakış
HSRC Pay'i payment orchestration platform olarak konumlandıran mimari ve ürün özeti.
Bu sayfa HSRC Pay'in neyi çözdüğünü, hangi domain parçalarını bir araya getirdiğini ve neden yalnızca tek provider'a bağlanan basit bir ödeme formu gibi düşünülmemesi gerektiğini açıklar.
HSRC Pay, provider karmaşasını tek bir payment lifecycle altında yönetilebilir hale getirir. Payment Method, Provider, Provider Config, Routing Plan, Provider Adapter, Confirm Orchestrator, Checkout Session, Sandbox Network ve Event/Webhook Delivery aynı orchestration modelinin parçalarıdır.
HSRC Pay nedir?
HSRC Pay; payment method'ları, provider'ları, routing stratejilerini, checkout session akışlarını, payment lifecycle'ı, charge attempt'lerini, sandbox/production separation'ı ve merchant operasyonlarını tek ödeme orkestrasyon katmanında birleştiren fintech infrastructure ürünüdür.
Bu ürünün ana fikri şudur: Merchant tek bir ödeme niyeti oluşturur; HSRC Pay bu niyeti doğru payment method, routing planı, provider adapter çağrısı, normalized result ve event/webhook disipliniyle çalıştırır.
Neyi çözmeye çalışır?
Klasik payment entegrasyonunda ekipler her provider için ayrı auth modeli, ayrı endpoint formatı, ayrı error dili, ayrı status mapping ve ayrı 3DS davranışıyla uğraşır. Bu yaklaşım büyüdükçe provider-specific execution karmaşasına dönüşür.
HSRC Pay bu problemi üç katmanda ele alır:
- Provider davranışını core ödeme mantığından ayırır.
- Provider sonuçlarını normalized result modeline çevirir.
- Merchant'a tek lifecycle, tek API yüzeyi ve tek event/webhook disiplini sağlar.
Klasik entegrasyon problemi
| Problem | Sonuç |
|---|---|
| Her provider farklı request/response modeli ister | Entegrasyon kodu hızla parçalanır |
| Error ve status mapping provider'a göre değişir | Merchant UI ve operasyon ekipleri tutarsız sonuç görür |
| 3DS/redirect flow'ları provider-specific çalışır | Frontend ve backend sorumlulukları belirsizleşir |
| Fallback ve retry sonradan eklenir | Payment ve charge attempt takibi zorlaşır |
| Sandbox yalnızca success kartından ibaret kalır | Production'da decline, timeout ve webhook sürprizi yaşanır |
HSRC Pay'in yaklaşımı
HSRC Pay ödeme davranışını confirm orchestrator ile yönetir: routing plan adayları seçilir, her aday için charge oluşturulur, provider adapter pay veya 3DS sonrası resume çalışır; sonuç confirmResult ve Payment/Charge status'e yazılır.
Core building blocks
| Parça | Sorumluluk |
|---|---|
| Payment | Merchant'ın iş seviyesindeki ödeme niyeti |
| Charge | Provider/rail seviyesindeki işlem denemesi |
| Payment Method | Kullanıcının ödeme yaptığı yöntem veya kanal |
| Provider | Ödemeyi işleyen banka, PSP, wallet provider, sandbox provider veya simulated provider |
| Provider config | Hesaba bağlı sağlayıcı ayarı; confirm'te routing_strategy veya hesap policy ile aday havuzuna girer |
| Provider adapter | Sağlayıcıya özel pay, capture, refund, 3DS resume implementasyonu |
| Confirm orchestrator | Routing adaylarını sırayla dener, adapter sonucunu confirmResult ve lifecycle status'e map eder |
routing_strategy | Confirm body'deki isteğe bağlı alan: payment_provider_config_id veya provider_identifier ile aday daraltma |
| Routing | Provider seçimi, fallback, failover, capability matching ve rule evaluation |
| Checkout Session | Hosted veya semi-hosted ödeme deneyimini yöneten oturum |
| Event/Webhook Delivery | State değişikliklerini merchant sistemine güvenilir şekilde ileten katman |
Payment orchestration lifecycle
- Merchant Payment oluşturur.
- Payment Method seçilir veya Checkout Session içinde toplanır.
- Confirm çağrısı execution'ı başlatır.
- Routing uygun provider candidate'larını üretir.
- Orchestrator seçilen aday için provider adapter'ı çalıştırır.
- Sonuç normalized modele çevrilir.
- Payment ve Charge state güncellenir.
- Event/webhook merchant sistemine iletilir.
Sandbox ve production ayrımı
Sandbox gerçek para hareketi oluşturmaz. Sandbox Network, production öncesi payment lifecycle, provider behavior, issuer/BIN resolution, 3DS, decline ve routing fallback davranışlarını test etmek için tasarlanır.
Production ise gerçek provider credential'ları, gerçek merchant ayarları, gerçek payment intent ve gerçek finansal sonuçlar ile ilgilidir. Bu iki ortamın credential, test data, logging ve operasyon sınırları ayrı ele alınmalıdır.
Developer experience
Developer için hedef; provider-specific karmaşaya değil, HSRC Pay'in canonical payment lifecycle'ına entegrasyon yapmaktır.
- Payment oluştur (
CREATED). - Confirm ile execution başlat; yanıtta
data.paymentvedata.confirmResultoku. - Adapter
kind(success,requires_action,declined,error) ilepayment.status(SUCCEEDED,REQUIRES_ACTION,REQUIRES_PAYMENT_METHOD,AUTHORIZED, vb.) ayrımını handle et. - Webhook/event ile nihai state'i doğrula.
- Sandbox'ta success dışındaki davranışları da test et.
Merchant operations
Merchant için değer yalnızca ödeme kabul etmek değildir. Operasyon tarafında şu soruların cevaplanması gerekir:
- Hangi provider denendi?
- Hangi charge attempt başarısız oldu?
- Fallback devreye girdi mi?
- Kullanıcı 3DS challenge'ı tamamladı mı?
- Refund veya void hangi işlem üzerinden yürüdü?
- Webhook teslimi başarılı mı?
HSRC Pay, bu soruları payment/charge/routing/event modeliyle izlenebilir hale getirmeyi hedefler.
Ne değildir?
- HSRC Pay her durumda bankanın veya PSP'nin yerine geçmez.
- HSRC Pay gerçek card network değildir.
- Sandbox providerlar ve çözülen sandbox issuer label’ları gerçek finansal kuruluş değildir.
- HSRC Pay provider eklemenin yalnızca JSON/YAML definition ile çözüldüğünü iddia etmez.
- HSRC Pay provider karmaşasını ortadan kaldırmaz; yönetilebilir, test edilebilir ve izlenebilir hale getirir.
Sonraki adımlar
- Ödeme akış haritası için Ödeme Akışları
- Domain model için Business Flow - Payments & Charges
- Confirm davranışı için Ödeme Yaşam Döngüsü ve Confirm
- Sağlayıcı modeli için Sağlayıcı ve Adapter Modeli
- Sandbox yaklaşımı için Sandbox Network
- Canlıya hazırlık için Integration Readiness