Portal — Genel Bakış
- Taban yol
/api/portal/v1/wallet- Kimlik
- Publishable key (
pk_live_…) → OTP → müşteri oturumu. Oturum son kullanıcıya aittir, merchant'a değil; yalnız o kullanıcının kendi verisine erişir. - Yetki
- Oturumun kendisi yetkidir; kullanıcı yalnız kendi kaydına erişir.Step-up: para çıkaran işlemlerde oturum tek başına yetmez; OTP kodu ya da güvenilir aksiyon token'ı istenir.
- Çapraz yüzey
- Bu yüzey son kullanıcı içindir; merchant sunucunuz bu uçları çağırmaz. Sunucu tarafı için s2s API'ye bakın.
Portal, son kullanıcının cüzdanıyla etkileşime girdiği yüzeydir: mobil uygulamanız, web uygulamanız ya da gömülü cüzdan ekranınız. Kendi markanız altında çalışır; kullanıcı bir Lunixi arayüzü görmez.
Son kullanıcının cihazı asla imza anahtarı taşımaz. Taşısaydı, uygulamayı kuran herkes tenant'ınızın tüm cüzdanlarına erişebilirdi. Portal yüzeyi tam olarak bunu engellemek için ayrı bir kimlik modeliyle çalışır.
Yetki genişliği
Aynı iş yeteneği s2s ve portal yüzeyinde farklı kapsamla açılır:
| Yetenek | s2s (/api/v1/wallet/*) | Portal (/api/portal/v1/wallet/*) |
|---|---|---|
| İşlem listesi | Tenant'ın tüm işlemleri | Yalnız oturum sahibinin işlemleri |
| Bakiye | Herhangi bir kullanıcının | Yalnız kendi bakiyesi |
| Transfer | Herhangi bir hesaptan | Yalnız kendi hesabından |
| Kullanıcı oluşturma | Var | Yok (kayıt akışı ayrıdır) |
Bunlar ayrı controller'lardır — tek bir uç üç farklı kimlikle paylaşılmaz. Bu, yanlış bir kapsam kontrolünün tüm yüzeyi açmasını engelleyen yapısal bir tercihtir.
Publishable key
Uygulamanız kendini bir publishable key (pk_live_…) ile tanıtır. Bu anahtar uygulamaya gömülebilir; tek başına hiçbir veriye erişmez, yalnız "hangi tenant ve hangi program" sorusunu cevaplar.
Publishable key oluştururken izin verilen origin'leri (allowedOrigins) tanımlamak zorunludur ve joker (*) kabul edilmez. Anahtar yalnız listelediğiniz origin'lerden çalışır — sızsa bile başka bir sitede kullanılamaz.
Oturum modeli
publishable key → kayıt/giriş → OTP doğrulama → müşteri oturumu (access + refresh)
│
hassas işlemde → step-up (OTP / trusted token)- Access token kısa ömürlüdür; her
/me/*çağrısında taşınır. - Refresh token oturumu uzatır.
- Step-up, para çıkaran işlemlerde ek doğrulamadır — oturum tek başına yetmez.
Ayrıntı: Portal — Kimlik & Oturum.
Cihaz farkındalığı
Kayıt, giriş ve OTP doğrulama isteklerinde bir cihaz tanımı taşıyabilirsiniz (parmak izi, platform, kurulum kimliği, cihaz adı). Bu, kullanıcının "hangi cihazlarım bağlı" ekranını ve şüpheli cihaz tespitini besler.
Kullanıcıya cihaz listesini ve oturumu sonlandırma imkânını verin. Cüzdan uygulamalarında "telefonumu kaybettim" senaryosunun tek çözümü budur.
Ne yapabilirsiniz
| Alan | Uçlar |
|---|---|
| Kimlik | kayıt, giriş, OTP, oturum, cihaz, şifre |
| Hesap | bakiye, cüzdan/hesap açma, limit, KYC seviyesi |
| Para | yükleme, transfer, çekim, QR ödeme, fatura |
| Sadakat | cashback, puan, seviye, rozet |
| Yardımcı | kişi rehberi, ücret quote, yetkilendirme (mandate) |
Mimari öneriler
- Oturumu cihazda güvenli saklayın. Access/refresh token'ları güvenli depoda tutun; log'a yazmayın.
- Step-up'ı ürün akışına gömün. OTP ekranını her para çıkışında hazır tutun; sonradan eklemek akışı bozar.
- Kilitli yetenekleri gösterin. KYC seviyesi yetmeyen işlemleri gizlemeyin, şartıyla birlikte kilitli gösterin.
- Ücreti canlı gösterin. Tutar yazıldıkça quote çağırıp toplamı gösterin.
- Belirsiz durumları doğru anlatın.
HELDveAWAITING_RECON"başarısız" değildir.