Güvenlik

Paymos saklamalı (custodial) bir sanal pos'tur — paranızı zincir üzerinde hareket ettiren anahtarları biz tutarız. Bu, her satıcının önüne haklı bir soru koyar: Paymos'un paramı almasını ne engeller ve bir şey ters giderse ne olur?

Bu sayfa iki soruyu da yanıtlar — önce kısa bir taahhüt listesi, sonra her birinin arkasındaki mantıkla birlikte sade bir dille. Platformun size verdiği garantileri ve her birinin size ne kazandırdığını anlatır; iç mimarinin planını değil. Bir ayrıntı herkese açık API'nin parçasıysa (isteği nasıl imzaladığınız, webhook'u nasıl doğruladığınız), onu tam olarak belgeliyoruz; çünkü entegrasyon için buna ihtiyacınız var.

---

Paranız neden güvende

Kontrollü hedefler ve yalıtılmış imzalama

• Yalıtılmış imzalama altyapısı. Paymos, saklama ve imzalama yolunu herkese açık web yüzeyinden ayrı işletir. Bu, yönetilen saklamadır; doğrudan satıcı anahtar kontrolü değildir.
• Zorunlu beyaz liste. Para yalnızca önceden onayladığınız hedeflere çıkabilir. API kimlik bilgilerinizin tamamen ele geçirilmesi bile yeni bir çekim adresi icat edemez.
• Varsayılan olarak sahip kontrollü. Çekim yapma yetkisi ve beyaz listeyi düzenleme yetkisi, açıkça devretmediğiniz sürece hesap sahibine aittir — ve her yetki kayıt altına alınır.
• Kendi takviminizde çekersiniz. Bakiyeniz, ödeme kesinliğe ulaştığı anda sizindir. Parayı kilitlemeyiz. Saatlik, günlük çekin ya da hiç çekmeyin: talep ile gönderilen işlem arasında ne toplu pencere ne bekleme sırası vardır, sonrasında ne kadar süreceğini ise zincirin kendisi belirler.
• Ayrılmış bakiyeler. Her satıcının bakiyesi ayrı izlenir. Satıcı fonlarını havuzlamayız; ödünç vermeyiz veya rehypothecation yapmayız.

Paranız sessizce kaybolmaz

• Ağa ve tutara göre seçtiğimiz bir derinlikte hesaba geçeriz — bir reorg'u nadir kılacak kadar derin, imkânsız diyecek kadar değil.
• Geri alma (clawback) yok. Bir ödemenin onaylandığını size bildirdikten sonra asla geri almayız. Onaylanmış bir ödeme daha sonra bir reorg ile zincirden düşerse, zararı Paymos üstlenir — siz değil.
• Ödeme çıkışları çift gönderemez. Her çekim kendi idempotency anahtarınızı taşır.
• Katmanlı dondurma kontrolleri, zincir üstü gerçeklik defterden saparsa tek bir varlığı otomatik olarak durdurabilir.
• Likidite önceden kontrol edilir, böylece bir çekim takılmak yerine hızlıca başarısız olur.
• Kurcalanmaya karşı kanıtlı kayıtlar: her ayrıcalıklı işlem denetim kaydına girer; sırlar ve imzalar kayıt yazılmadan önce temizlenir.

Sayfanın geri kalanı bunların her birini sade terimlerle açıklar. HMAC veya SSRF kelimelerini görüp ne anlama geldiğini merak ettiyseniz — okumaya devam edin.

---

Tehdit modeli

Şunlara karşı tasarım yaparız:

• Bekleyen fonlar — bakiyeleri zincir üzerinde hareket ettirebilecek anahtarlar
• Hareket halindeki fonlar — çekim yetkilendirmesi ve hedef kurcalama
• API erişimi — kimlik bilgisi hırsızlığı, istek tekrarı (replay), kapsam yükseltme
• Webhook teslimatı — sahte yükler ve altyapımızın sizin ağınıza SSRF köprüsü olarak kullanılması
• Operasyonel risk — kazara yıkıcı işlemler, çok sunuculu yarış koşulları, denetim boşlukları

Açıkça kapsam dışı: müşterinizin cüzdan güvenliği (kendi anahtarlarını kendileri tutar), çekim imzalandıktan sonra alıcı tarafı riski (zincir üstü işlemler kesindir), Paymos'un yanında çalıştırdığınız üçüncü taraf hizmetler ve ekibinize yönelik sosyal mühendislik.

---

Çekim imzalama ve hedef kontrolleri

Sorun. Blockchain üzerindeki fonlar imzalama anahtarlarıyla kontrol edilir. Çalınan bir kimlik, değiştirilmiş bir hedef veya imzalama sunucusunun ele geçirilmesi, çevredeki kontroller kapalı konumda başarısız olmadıkça para kaybına dönüşebilir.

Paymos'un yaptığı. Giden işlemler yalıtılmış altyapıda imzalanır. Bir çekim yalnızca satıcının beyaz listesinde bulunan bir adrese gidebilir; liste boşsa çekim tümden kapalıdır. Listeyi değiştirmek ayrı bir işlemdir ve kayda geçer. Değişikliği yapan kullanıcıda ikinci faktör tanımlıysa işlem ayrıca taze bir ek doğrulama (step-up) ister. İkinci faktör yoksa sorulacak bir şey de yoktur: bu katman, siz kurduğunuz gün başlar.

Operatörler, bir olay araştırılırken tüm giden transferleri durdurabilir veya tek bir varlık-ağ çiftini dondurabilir. Her çekim ayrıca bir idempotency anahtarı taşır; aynı isteğin tekrarı ikinci bir çekim oluşturmaz.

Bu hâlâ saklamalı bir altyapıdır: imzalama yolunu Paymos işletir. Hedef kontrolleri, dondurmalar, denetim kayıtları ve defter mutabakatı saklama etrafındaki riski azaltır; onu saklamasız veya eşikli (threshold) saklamaya dönüştürmez.

Her fatura kendi benzersiz yatırma adresini alır, böylece mutabakat tartışmasızdır. Sandbox ödemeleri ve çekimleri canlı paraya dokunmaz; entegrasyonu üretim transferi oluşturmadan test edebilirsiniz.

---

HMAC — API bir isteğin gerçekten sizden geldiğini nasıl bilir

HMAC, Hash-based Message Authentication Code anlamına gelir. Korkutucu isim, basit fikir.

Sorun. Sunucunuz bize "1.000 $ çekim oluştur" gönderiyor. İki sorumuz var: bu gerçekten siz misiniz, yoksa bir sahtekâr mı? Ve istek yolda kurcalandı mı — tutar veya adres değiştirildi mi? İsteğin içine bir parola koyarsanız, trafiği yakalayan herkes onu çalar ve sizin adınıza istek gönderir.

HMAC'in yaptığı. Siz ve biz bir sır paylaşırız (API secret'ınız). Her istek için bir "parmak izi" (imza) hesaplarsınız — istek içeriğinin sır ile birlikte hash'i. İsteği ve parmak izini gönderirsiniz, ama sırrı göndermezsiniz. Aynı parmak izini kendi sır kopyamızla yeniden hesaplarız. Eşleşirlerse gerçekten sizsiniz ve hiçbir şey değiştirilmemiştir — tek bir karakteri değiştirin, parmak izi tutmaz.

Benzetme. Bir mektuptaki mum mührü. Sır, size özel damganızdır. Herkes mührü görebilir, ama damga olmadan taklit edemez. Mektup açılıp yeniden yazılırsa mühür içerikle uyuşmaz.

Kilit nokta: sırrın kendisi asla ağ üzerinden geçmez. Tüm trafiğinizi kaydetse bile saldırgan sırrı çıkaramaz veya yeni istek üretemez — elinde yalnızca zaten gönderdiğiniz isteklerin imzaları olur. (SHA-256, herhangi bir girdiyi geri döndürülemez sabit uzunluklu bir parmak izine öğüten özel "değirmendir".)

Tam biçim (entegrasyonunuz için)

Kimliği doğrulanmış her istek iki başlık taşır:

Authorization: HMAC-SHA256 {api_key_id}:{base64(signature)}
X-Request-Timestamp: {unix_seconds}

İmza, kanonik bir dize üzerinde HMAC-SHA256'dır:

{timestamp}\n{METHOD}\n{path}\n{query}\n{sha256_hex_lower(body)}

Boş gövde o yuvaya boş dize koyar — hash'lenmez; sorgu parametreleri URL'de göründükleri gibi imzalanır. Tüm ayrıntılar Kimlik Doğrulama sayfasında.

Tekrar (replay) koruması

Saldırgan kaydettiği eski bir isteği yeniden gönderebilir mi — "çekim oluştur"u yüz kez tekrarlayabilir mi? Zaman damgası imzanın parçasıdır ve X-Request-Timestamp değeri sunucu saatinden ±5 dakikadan fazla sapan her isteği reddederiz (401 ile reddedilir). Kaydedilmiş bir istek beş dakika yaşar, sonra ölür. Aşağıdaki idempotency ile birlikte, bu pencere içinde bile tekrarlanan bir "çekim oluştur" parayı iki kez göndermez.

Benzetme. Beş dakikalık giriş penceresi olan bir bilet — dünün bileti işe yaramaz.

Sabit zamanlı karşılaştırma

İki imzayı karşılaştırırken naif bir karşılaştırma ilk yanlış karakterde durur — ve yanıt süresi kaç karakterin doğru olduğunu ele verir; saldırganın bayt bayt tahmin etmesine izin verir. Sabit zamanlı karşılaştırırız: ne kadar doğru tahmin ederseniz edin "hayır" tam olarak aynı süreyi alır.

Benzetme. Bir hane doğru da beş hane doğru da olsa "hayır"ı aynı sürede söyleyen bir şifreli kilit. "Isındığınızı" anlayamazsınız.

Anahtar türleri ve rotasyon

Her biri sabit bir kapsama sabitlenmiş ve her çağrıda sunucuda uygulanan iki anahtar türü:

• Payment anahtarı — paranın girdiği her şey: fatura oluşturur ve okur, ödeme kanallarını yönetir ve yatırmalarını okur. Bakiye okuyamaz veya çekim oluşturamaz.
• Payout anahtarı — çekim oluşturur, okur ve iptal eder; bakiyeleri okur. Fatura oluşturamaz, ödeme kanalına da erişemez.

Sırlar kesintisiz rotasyona girer: önceki sır previous_secret_expires_at değerine kadar geçerli kalırken yeni bir sır üretirsiniz. Bu değer rotasyondan tam 24 saat sonrasıdır; süre sabittir, parametreyle verilmez. Pencere açık kaldığı sürece ikisi de kabul edilir, sonra yalnızca yenisi çalışır.

---

Webhook güvenliği — aynı HMAC, ters yönde

Yukarıdaki HMAC bize gönderdiğiniz istekleri korur. Webhook ise bizim kapınızı çalmamızdır ("fatura ödendi"). Aynı numara, ters yön: her webhook'u uç noktanızın sırrıyla imzalarız ve siz güvenmeden önce imzayı doğrularsınız. Aksi takdirde webhook URL'nizi öğrenen herkes sahte bir "ödendi" olayı gönderip sizi mal göndermeye kandırabilir.

X-Webhook-Signature: t={unix_seconds},v1={hex_hmac}

İmzalanan yük {timestamp}.{request_body} şeklindedir. Şema Stripe'ınkiyle aynıdır; Stripe webhook'larını doğrulayan kütüphaneler burada neredeyse hiç değişiklik olmadan çalışır. Sır rotasyonu sırasında aynı başlıkta iki imza birden göndeririz. Bkz. Webhook'ları Doğrulama.

SSRF koruması

SSRF, Server-Side Request Forgery anlamına gelir. Bir webhook URL'si ayarlarsınız ve sunucularımız ona istek yapar. Kurnaz bir saldırgan URL'yi dışarıya değil ağımızın içine — bir bulut metadata adresine veya dahili bir panele — yönlendirir; böylece sunucumuz onun adına istek yapar ve Paymos, yalnızca ağımızın görebildiği şeylere proxy olur.

Bunu engelleriz: webhook hedefi herkese açık bir adrese çözümlenecek şekilde doğrulanır — loopback, özel, dahili ve bulut metadata aralıkları reddedilir — ve bağlantı doğrulanmış adrese sabitlenir, böylece DNS-rebinding penceresi kalmaz. Yönlendirmeler reddedilir. Doğrulamayı geçemeyen hedef anında düşürülür; sondaj teslimat bütçesini tüketemez.

Benzetme. Yalnızca gerçek dış adreslere teslimat yapan, "bu binanın kendi sunucu odasına" hiçbir şey taşımayı reddeden, yola çıkmadan adresi kontrol eden ve "aslında şuraya bırak" notunu yok sayan bir kurye.

Teslimat anlambilimi

Webhook URL'leri HTTPS kullanmalıdır (uç noktayı kaydederken zorunlu kılınır). Teslimat at-least-once'tır — kendi tarafınızda olay kimliğiyle tekilleştirin (Stripe, GitHub ve PayPal'ın kullandığı kural). Başarısız teslimatlar, yaklaşık 16 saate yayılan 11 denemede üstel geri çekilmeyle yeniden denenir — tam takvim Teslimat ve yeniden denemeler sayfasındadır — sonra başarısız işaretlenir ve Panel'den tekrar gönderilebilir. Her denemenin kendi zaman aşımı vardır.

---

Çekim koruması — arka arkaya birkaç kilit

Para çıkarmak, saklamalı bir sanal posun var olup yıkıldığı yerdir; bu yüzden en çok katmana sahiptir:

• Beyaz liste (zorunlu). Çekim yalnızca önceden onayladığınız adreslere gider. Bir ağ ailesinin beyaz listesi boşsa hiçbir çekim oluşturulamaz — "ilk çekim adresi belirler" kısayolu yoktur. Anahtarlar çalınsa bile para yalnızca kendi cüzdanlarınıza gidebilir; anahtar çalmanın getirisi ortadan kalkar. Benzetme: yalnızca önceden kayıtlı alıcı listesine havale yapabilen bir hesap — parolanızı çalan hırsız yeni alıcı ekleyemez.
• Yalnızca sahip. Çekim oluşturma ve beyaz listeyi düzenleme, standart yönetici rolüne değil hesap sahibine aittir. Sahip olmayana açıkça yetki vermelisiniz ve bu yetki denetlenebilir.
• İki faktör (2FA). Kimlik doğrulama uygulamasından her 30 saniyede değişen altı haneli kod; tanımlı bir passkey de ikinci faktör sayılır. Hazır açık gelmez, siz kurarsınız — ve ek doğrulamayı kuran şey tam olarak budur: hesapta ikinci faktör varken çekim beyaz listesini değiştirmek, bir API anahtarının IP listesini düzenlemek ya da ikinci faktörü kapatmak, çalıştığı anda taze bir kod ister.
• Dondurma kontrolleri (devre kesiciler). Her şeyi aynı anda, tek bir ağdaki tek bir token'ı veya tek bir satıcıyı dondurabiliriz. Varlık bazlı dondurma, zincir üstü bakiyeler defterden güvenli sınırın ötesine saparsa otomatik devreye girebilir.
• Önceden likidite kontrolü. Çekim kabul edilmeden önce kullanılabilir fonlara (komisyonlar dahil) karşı kontrol edilir; takılmak yerine net bir hatayla anında başarısız olur.
• Idempotency. Sipariş kimliğiniz idempotency anahtarıdır — iki kez gönderin, aynı tek çekimi geri alırsınız; asla ikinci bir transfer olmaz. Benzetme: vestiyer fişi; aynı fişi iki kez verseniz de aynı tek paltoyu geri alırsınız.
• Yarışa karşı güvenli oluşturma. Aynı hesap için eşzamanlı çekim istekleri sunucu tarafında sıralanır; iki paralel çağrı aynı bakiye kontrolünü atlatamaz.

---

Yetkilendirme ve yalıtım

• Her istek sunucu tarafında kontrol edilir — bir şey yapmadan önce: ortam eşleşmelidir (sandbox ve üretim), çağıran türüne izin verilmelidir, kimliğin kapsamı işlemi kapsamalıdır ve kaynak çağırana ait olmalıdır. Bu kontroller gerçek sınırdır — arayüz kontrolleri yalnızca ipucudur.
• 403 değil, 404. Bir kaynak yoksa veya var ama sizin değilse 404 alırsınız. Böylece saldırgan "bu ID gerçek ama senin değil" ile "bu ID yok" arasındaki farkı anlayamaz. Benzetme: kişi orada yaşasa da yukarı çıkmanıza izin yoksa da "öyle biri yok" diyen bir kapıcı.
• Kimliğiniz kimlik bilginizden gelir, asla istek gövdesinden değil. İsteğe başkasının kimliğini koymak hiçbir şey yapmaz — bir ID taklit ederek başka bir satıcı adına hareket edemezsiniz.
• Ayrıntılı izinler. Erişim, her biri bağımsız verilebilen ince taneli rol tabanlı izinlerle yönetilir (ör. çekim, bakiye görüntüleme, webhook yönetimi). Sunucu tarafı kontrol sınırdır; Panel onu yansıtır.

---

Hız sınırlama

Her satıcının kendi hız limitleri vardır. Birini aştığınızda Retry-After başlığıyla 429 Too Many Requests alırsınız; böylece hatalı davranan tek bir entegrasyon yalnızca kendi iş hacmini etkiler, platformu veya diğer satıcıları değil.

---

Zincir üstü kesinlik — paranız neden kaybolmaz

Blockchain'de bir işlem bir blokta hızlıca "görünür", ama zincir yakın geçmişi hâlâ yeniden yazabilir (bir "reorg") — ve onaylanmış görünen şey kaybolabilir. Islak mürekkep gibi: yazılmış, ama hâlâ bulaşabilir.

Kesinlik (finality), işlem geri alınamayacak kadar derine gömülene kadar beklemek demektir. Mürekkep kurudu. Bakiyenizi hareket ettirmeden önce her ağın kendine uygun kesinliğini bekleriz. Kesinliğin onay derinliği meselesi olduğu zincirlerde bu derinlik tutara göre ölçeklenir — küçük tutarlar hızlı onaylanır, büyükler daha uzun bekler; yerel anlık kesinliği olan zincirler blok kesinleşir kesinleşmez sonuçlanır. Bu eşikler ağ koşullarına göre ayarlanır, sabit değildir.

Ana taahhüt: zaten onayladığımız bir ödeme daha sonra bir reorg ile zincirden düşerse (çok nadir), zararı Paymos üstlenir, siz değil. Bir onay webhook'u tetiklendiğinde derhal harekete geçebilirsiniz. Bonus olarak ters ibraz (chargeback) yoktur (alıcının satıştan aylar sonra geri çevirebildiği kartların aksine) ve geç ödemeler tasarım gereği imkânsızdır — süresi dolmuş bir faturadan sonra onaylanan ödeme o faturaya yansıtılmaz.

---

Veri koruması

Aktarımda: tüm trafik TLS 1.2+ üzerindedir, üretimde HSTS etkindir ve şifrelenmemiş istekler HTTPS'e yönlendirilir.

Beklemede: oturum çerezleri HttpOnly, Secure, SameSite=Strict'tir; giriş bağlantıları tek kullanımlıktır, hızlı süresi dolar ve beklemede şifrelidir.

Sahtecilik karşıtı: durum değiştiren Panel işlemleri bir sahtecilik karşıtı token taşır; bu, SameSite=Strict çerezleriyle birlikte siteler arası istek sahteciliğini (CSRF) engeller.

Denetim kaydı: her ayrıcalıklı işlem; kimin yaptığını, ne çalıştığını, sonucu ve ne zaman olduğunu kaydeder. Hassas değerler — sırlar, parolalar, tokenlar, hash'ler, imzalar — kayıt saklanmadan önce maskelenir; yazma anında zorunlu kılınır.

---

Operasyonel dayanıklılık

• Çok sunuculu güvenlik. Birkaç sunucuda çalışmak bir ödemeyi, çekimi veya webhook'u asla iki kez işlemez — aynı öğe üzerindeki eşzamanlı iş tam olarak bir kez gerçekleşecek şekilde koordine edilir. Varsayılmaz, otomatik testlerle doğrulanır.
• Gizliliğe uygun hata raporlama. Çökme raporları, sistemlerimizden çıkmadan önce kişisel verilerden ve istek içeriklerinden arındırılır.
• Kendini iyileştiren altyapı. Otomatik sağlık kontrolleri sağlıksız bir örneği rotasyondan çıkarır.
• Güvenli şema değişiklikleri. Veritabanı geçişleri bir kez, sırayla ve yalnızca ileri yönde uygulanır — üretim verisine karşı asla yıkıcı geri alma çalıştırmayız.

---

Uyumluluk ve veri işleme

Başlamak için KYC yok. Kimlik, adres veya hak sahibi belgeleri göndermeden kaydolup teste başlayabilirsiniz ve Paymos bu belgeleri müşterilerinizden toplamaz. Paymos işinizi incelemez, lisans kontrolü yapmaz, satıcı kategorilerini elemekten veya müşterilerinize yaptırım taraması uygulamaktan kaçınır; bu yükümlülükler satıcıda kalır. Etkinlik manuel inceleme gerektirirse, hesap limitleri aşılırsa veya yetkili bir merci gerektirirse daha sonra KYC/KYB talep edebiliriz; AML/KYC politikamızda açıklandığı gibi.

Müşteri tarafı verisi. Tasarım gereği Paymos, ödeme sayfasında müşterilerinizden kişisel veri toplamaz — e-posta, telefon, isim veya kart verisi yok. Akış: fatura → ödeme sayfası → cüzdan öder → bitti. Kimlikler değil cüzdan adresleri ve tutarlar görürüz; böylece Paymos üzerinden GDPR/KVKK maruziyetiniz pratikte sıfırdır.

Satıcı tarafı verisi. Hesabınız için işletme adı, iletişim e-postası, ülke ve proje metalarını (webhook URL'leri, API anahtar kimlikleri) tutarız. Bir GDPR silme talebi, 30 günlük yumuşak silmeyi ve ardından kalıcı temizlemeyi tetikler; denetim izi yalnızca silinen kaydın hash'ini tutar.

Veri yerleşimi. Birincil veri AB'de saklanır. Kurumsal sözleşmeler belirli bir bölgeyi sabitleyebilir — bize ulaşın.

---

Yapmadıklarımız

• Kurmadığımız şeyleri iddia etmeyiz. Bu sayfa sistemi dağıtıldığı haliyle anlatır. Yol haritası öğeleri yayınlanana kadar listelenmez.
• Gereğinden uzun saklamayız. Fonlar, ödeme onaylandığı anda bakiyenize ulaşır; çekim zamanlaması sizin seçiminizdir.
• Satıcı bakiyelerini havuzlamayız. Her bakiye ayrıdır. Bir satıcının iflası veya anlaşmazlığı diğerinin fonlarına dokunamaz. Ortak bir havuzu paylaşmak tam olarak FTX gibi borsaları batıran şeydir.
• Alıcı tarafı güvenliği vaat etmeyiz. Çekim imzalandığında işlem zincir üzerindedir ve kesindir. Beyaz liste yazım hatalarını ve anahtar hırsızlığını önler — onayladığınız bir hedefin düzgün davranacağını doğrulayamaz.

---

Güvenlik açığı bildirme

Bildirimleri [email protected] adresine gönderin.

• Alındı onayı: eksiksiz bir bildirimden sonra iki iş günü içinde
• Kapsam: üretim paymos.io ve *.paymos.io, üretim REST API'si ve Paymos tarafından yayınlanan SDK'lar ile CMS eklentileri
• Kapsam dışı: hız limiti tabanlı hizmet reddi, sosyal mühendislik, üçüncü taraf hizmetler (CDN'iniz, barındırma sağlayıcınız vb.)
• Bug bounty: şu anda herkese açık program yok; önemli bulguların gizli bildirimi duruma göre ödüllendirilir ve talep üzerine teşekkür edilir.

Lütfen diğer satıcıların hesaplarına karşı test yapmayın, üretime karşı yıkıcı test uygulamayın veya düzeltme şansı bulmadan önce kamuya açıklamayın. Eksiksiz bir bildirimi iki iş günü içinde aldığımızı onaylamayı, düzeltme hakkında sizi bilgilendirmeyi, yayınlandığında (izninizle) size teşekkür etmeyi ve kapsam dahilindeki iyi niyetli araştırmaya karşı yasal yola başvurmamayı taahhüt ederiz.