Entegrasyonu uzatan şey teknik değil
eKYC entegrasyonları çoğu zaman zor oldukları için değil, kapsamı belirsiz olduğu için uzar. "Doğrulama ekleyeceğiz" cümlesi bir sprint planına dönüşmez; hangi adımın kimde olduğu netleşmeden tahmin de yapılamaz.
Bu yüzden entegrasyona kod yazarak değil, sorumluluk sınırını çizerek başlamak gerekir.
Sizin tarafınızda ne var
Üç şey — üçü de ilk gün hazırlanabilir ve hiçbiri altyapı değişikliği gerektirmez:
- API anahtarı. Test ve canlı ortam için ayrı anahtarlar alırsınız; test trafiği gerçek trafiğe karışmaz.
- SDK yerleşimi. Paket yöneticinizle kurulur ve kayıt ekranınızdan doğrulama akışını başlatır.
- Webhook ucu. Sonucun düşeceği bir uç tanımlarsınız. Akışınızı yanıt beklerken bloke etmezsiniz.
Bunlara bir karar daha eklenir: kabul eşikleri. Hangi skorun üstü otomatik onaylanacak, hangi bant manuel incelemeye düşecek? Bu karar sizde kalır ve kalmalıdır — risk iştahı ürün bilgisidir.
Sağlayıcı tarafında ne var
Doğrulama modelleri, belge formatlarının güncellenmesi, yaptırım ve PEP listelerinin takibi, trafik artışında ölçeklenme.
Bunun pratik anlamı şudur: yeni bir belge formatı yayımlandığında ya da bir liste güncellendiğinde entegrasyonunuz bozulmaz. Sözleşme yüzeyi sabit kalır, arkasındaki modeller değişir.
Üç adımda canlıya
Anahtarı alın. İlk çağrıyı aynı gün atabilirsiniz; aşağıdaki istek başlangıç noktasını verir:
curl -X POST https://api.osvoy.com/api/v1/verifications \
-H "Authorization: Bearer $OSVOY_SANDBOX_KEY" \
-H "Content-Type: application/json" \
-d '{
"reference_id": "user_10428",
"document_type": "passport",
"callback_url": "https://ornek-sirket.com/webhooks/osvoy"
}'
Yanıtta dönen verification_id oturumun kimliğidir; reference_id ise sizin kendi kullanıcı kaydınızla eşleştirdiğiniz alandır. İkincisini göndermezseniz sonucu kendi tarafınızda bağlayacak bir anahtarınız olmaz.
Akışı test ortamında kurun. SDK'yı yerleştirin, webhook ucunuzu bağlayın ve hem başarılı hem başarısız senaryoları simüle edin. Eşiklerinizi gerçek trafiğe açmadan belirlemenin tek yolu budur.
Doğrulama bittiğinde webhook ucunuza düşen gövde şu şekildedir:
{
"verification_id": "vrf_7kq2ha91",
"reference_id": "user_10428",
"status": "approved",
"score": 0.96,
"checks": {
"document": "pass",
"face_match": "pass",
"liveness": "pass",
"aml": "clear"
},
"completed_at": "2026-06-16T09:41:22Z"
}
Kabul eşikleri dediğimiz karar tam olarak burada kodlanır — ve bu üç satır sizin tarafınızda kalır:
if (result.score >= 0.90) return approve(result.reference_id);
if (result.score >= 0.70) return queueForManualReview(result.reference_id);
return reject(result.reference_id);
Canlıya geçin. Aynı kodu canlı anahtarla çalıştırırsınız. Geçişi ayrı bir proje hâline getirmeyin.
Test ederken neyi atlamayın
Mutlu yolu test etmek kolaydır. Asıl değerli olan diğerleridir: reddedilen doğrulama, zaman aşımına uğrayan istek, ulaşılamayan webhook ucu. Bu üçünün davranışını canlıya çıkmadan görmek, canlıda öğrenmekten ucuzdur.
