Servis topolojisi
İlk adımda Identity’denclient_credentials akışıyla bir access token alırsınız; sonraki tüm istekleri ürün servislerine Authorization: Bearer <access_token> header’ı ile yaparsınız. Aynı token Sanal POS ve Para Transferi servislerinin ikisinde de geçerlidir.
Tüm ürün servisleri aynı Bearer access token’ı kabul eder; servis başına ayrı kimlik akışı yoktur. Fraud servisinin endpoint’leri (kural CRUD, manuel inceleme) Sanal POS API’siyle birlikte sunulur.
Yol haritasında: Fatura Ödeme ve Açık Bankacılık modülleri geliştirme aşamasındadır. Bu servisler henüz canlı API’ye dahil değildir. Yol haritası.
Organizasyon ve merchant modeli
Payven üç katmanlı bir hesap yapısı kullanır:- Organizasyon (Tenant): Payven’i kullanan firma. Tipik olarak ödeme kuruluşu, banka veya büyük platform olur — lisans zorunluluğu yoktur. Tüm API anahtarları ve banka konfigürasyonları bu seviyede yönetilir.
- Merchant: Organizasyona bağlı bayi veya alt müşteri. Her ödeme bir merchant adına gerçekleştirilir.
- Alt Merchant: İsteğe bağlı olarak merchant ağacında ek seviye (örneğin marketplace satıcıları).
İstek yaşam döngüsü
Aşağıda kart ödeme isteğinin Sanal POS servisinden geçişi gösterilmiştir; Para Transferi ve Fraud için de mantık aynıdır.Ortam URL’leri
Her servis kendi alt-domain’i üzerinden hizmet verir. Tüm path’ler/api/v1 ile başlar.
Fraud kontrolü Sanal POS akışlarının içinde otomatik çalışır — sizin tarafınızdan ayrı bir API çağrısı gerekmez. Kural yönetimi konsoldan yapılır.
Sandbox ortamı, organizasyonunuzun konnektör konfigürasyonuna göre ya simülasyonla yanıt üretir ya da bankanın test ortamına gerçek çağrı atar — bkz. Sandbox Ortamı. Production geçişi öncesinde Go-live kontrol listesini tamamlayın.