Kripto ödeme mutabakatı modelleri: varlık, konum ve zaman
Kripto ödeme mutabakatı, müşterinin gönderdiği transferle aynı işlem değildir. Müşteri ödeme sırasında varlığı ve ağı seçer; işletmenin ise belirli bir varlıkta, bilinen bir hesapta ve öngörülen zamanda kullanılabilir fonlara ihtiyacı vardır.
Model dört soruyu yanıtlar: İşletme hangi varlığı tutacak? Fonlar ödeme hesabında mı kalacak, dış cüzdana mı aktarılacak? Transfer ne zaman yapılacak? Ücretler, kurlar ve kayıtlar net tutarı nasıl belirleyecek? BTC ödemesi içeride BTC olarak tutulabilir veya USDT'ye çevrilerek günlük çekilebilir. İki yolun likidite, piyasa riski ve muhasebe sonuçları farklıdır.
Mutabakat tek seçenek değil; varlık, hedef, zaman ve transfer politikasının birleşimidir.
Ödeme kabulü, blokzincir kesinliği ve mutabakat farklı aşamalardır
Bir işlemin ağda görünmesi, bloğa alınması, onaylanması, sipariş için kabul edilmesi ve bakiyenin işletmenin kullanımına açılması farklı aşamalardır. Müşteri ödemesi kabul edilmiş olsa bile dönüşüm, dahili alacak kaydı veya dış transfer başarısız olabilir.
BIS ödeme terminolojisindeki mutabakat riski, fonların beklendiği gibi aktarılmamasıyla ilgilidir. Hukuki kesinlik de protokol kesinliğiyle aynı değildir: mevzuattaki geri döndürülemezlik anı bir blok onayına eşit olmayabilir. İşletme fonların ne zaman fiilen kullanılabilir olduğunu tanımlamalıdır.
Ağ, onay politikası, ödeme sistemi ve hazine birimi farklı sorumluluklar üstlenir.
| Aşama | Yanıtladığı soru | Asıl sorumlu |
|---|---|---|
| Blokzincire ekleme | İşlem ağ geçmişine dahil edildi mi? | Blokzincir ağı |
| Onay veya kesinlik | İşlemin kalıcı olacağına dair güven ne kadar güçlü? | Mutabakat ve onay politikası |
| Ödeme kabulü | İşlem ticari talebi karşılıyor mu? | Ödeme sistemi ve satıcı politikası |
| Satıcı mutabakatı | Hangi fonlar, nerede ve ne zaman kullanılabilir? | Mutabakat ve hazine katmanı |
Kaynaklar ve belgeler: BIS — ödeme ve mutabakat · BIS — dağıtık defter
Mutabakat tasarımının üç bağımsız boyutu
İlk boyut varlıktır: müşterinin ödediği kriptoyu korumak veya hedef varlığa dönüştürmek. İkinci boyut konumdur: platform içi hesap bakiyesine alacak kaydetmek veya işletmenin kontrolündeki dış cüzdana taşımak. Üçüncü boyut zamandır: anında, elle, bakiyenin eşiğe ulaşmasıyla veya belirli aralıklarla yapmak.
Boyutlar birlikte kullanılır. Örneğin BTC ile alınan ödeme USDT'ye çevrilir, iç hesapta biriktirilir ve her gün hazine cüzdanına gönderilir. Modelin adı üç tercihi de belirtmelidir.
Aynı varlıkla mutabakat müşterinin ödediği kriptoyu korur
Aynı varlık modelinde BTC ödemesi BTC, USDT ödemesi de desteklenen ağdaki USDT bakiyesiyle sonuçlanır. Dönüşüm adımı yoktur; ancak işletme alınan varlığın piyasa fiyatındaki değişime maruz kalır.
Bu model ilgili varlıkla gider ödeyen, uzun süre elinde tutmak isteyen veya her ödemeyi dönüştürmeyi tercih etmeyen işletmelere uygundur. Gelirin değeri kabul, raporlama, kullanma ve daha sonraki dönüşüm arasında değişebilir.
Farklı ağlardaki aynı token sembolü eşdeğer operasyonel likidite anlamına gelmez. Ağ bazında bakiye, çekim ücreti, adres kuralı ve hazine hedefi izlenmelidir.
Dönüştürülmüş mutabakat müşteri tercihini hazine varlığından ayırır
Müşteri BTC, ETH veya desteklenen başka bir varlıkla ödeme yaparken işletme stablecoin ya da tercih ettiği başka bir kripto alabilir. Sektörde itibari para ile biten çözümler de vardır; ancak bu her sağlayıcının özelliği değildir.
Dönüşüm kabul anında, bakiye eşiğine gelince veya sonradan manuel gerçekleştirilebilir. Seçilen an, kur oynaklığı ve likidite riskini değiştirir. Kabule yakın sabitlenmiş fiyat açık riskleri azaltabilir fakat yeterli likidite ve şeffaf fiyatlama gerektirir.
Stablecoin'ler de ihraççı, itfa, ağ, likidite ve sabit değerden sapma riski taşır. Başlamadan hedef varlık, işlem zamanı, fiyat kaynağı, ücretler ve başarısız dönüşüm prosedürünü tanımlayın.
Kaynaklar ve belgeler: Circle Mint — stablecoin ihraç ve itfa
Dahili mutabakat her ödeme için dış transfer gerektirmez
Dahili mutabakatta kabul edilmiş ödeme sağlayıcının hesap sisteminde işletme bakiyesini artırır. Her sipariş için ayrı bir blokzincir çekimi yapılmaz; küçük tutarlar birikerek daha sonra toplu aktarılabilir.
Bu yaklaşım ağ masraflarını düşürebilir ve dönüşüm, iade, ödeme veya hazine tahsisi için esneklik sağlar. Karşılığında işletme sağlayıcının defter kayıtlarına, hesap erişimine ve para çekme kontrollerine bağımlı olur.
Bakiye görünürlüğü, personel yetkileri ve dahili alacağın ne zaman kullanılabilir olduğu açık olmalıdır. OxaPay Account Balance API, dış transferden önce varlık durumunu kontrol etmeyi sağlar.
Kaynaklar ve belgeler: OxaPay — hesap bakiyesi
Harici mutabakat fonları onaylı bir cüzdana taşır
Harici mutabakat ödeme hesabından öz saklamalı cüzdana, kurumsal saklama hizmetine, borsa hesabına veya başka bir onaylı hazine adresine transfer yapar. Daha doğrudan kontrol sağlar; fakat istek, doğrulama, yayım, onay ve mutabakat içeren yeni bir transfer süreci oluşturur.
İzin verilen adres listesi hedef değiştirme riskini azaltır. Varlık-ağ doğrulaması uyumsuz çekimleri engeller. Büyük veya olağandışı tutarlar için onay kuralları ve durum takibi gereklidir.
OxaPay, ödeme çıkışı oluşturma, bilgi sorgulama, geçmiş ve durum tabloları sunar. Başarısız çekim, daha önce kabul edilen müşteri ödemesini ödenmemiş hâle getirmez; bir mutabakat istisnasıdır.
| Harici kontrol | Neden gerekli |
|---|---|
| İzin verilen hedefler | Adres değiştirme ve izinsiz yönlendirme riskini azaltır |
| Varlık-ağ doğrulama | Tokenın uyumsuz ağa gönderilmesini önler |
| Onay politikası | Büyük veya alışılmadık transferlerde inceleme sağlar |
| Durum takibi | İstenen, işlenen, onaylanan, başarısız ve iptal edilen durumlarını ayırır |
Kaynaklar ve belgeler: OxaPay — ödeme çıkışı oluşturma · OxaPay — çekim bilgisi · OxaPay — çekim geçmişi · OxaPay — çekim durumları
Zamanlanmış mutabakat biriken fonların hareketini yönetir
Dış çekim günlük veya haftalık zamanlarda, minimum bakiye eşiğinde, maksimum hesap bakiyesine ulaşınca ya da manuel hazine onayıyla yapılabilir. İşlemleri gruplamak ağ transferi sayısını ve maliyetini azaltırken nakit planlamasını iyileştirir.
Bunun karşılığında platform hesabında daha fazla fon daha uzun süre tutulur ve dış erişim gecikir. Likidite ihtiyacı, saklama riski, ücretler ve operasyon yükü dengelenmelidir.
Politikada kesim zamanı, çekime uygun bakiye, ücretler, hata yolu, yeniden deneme kuralı ve sonraki çekim tarihi bulunmalıdır. Kripto çekimlerinde ağ masrafları ve doğrulama süreçleri de hesaba katılır.
Kaynaklar ve belgeler: Stripe — ödeme takvimleri
Karma modeller farklı mutabakat yollarını birleştirir
Gerçek sistemler çoğu zaman tek bir seçenek kullanmaz. İşletme işletme sermayesi için stablecoin'leri dahili tutabilir, BTC'yi uzun süreli saklamaya taşıyabilir ve oynak varlıkları günlük çekimden önce dönüştürebilir.
Oynaklık kontrolü modeli varlıkları stablecoin'e çevirip planlı çeker. Varlığı koruma modeli alınan varlığı değiştirmez ve seçili bakiyeleri ayrı cüzdanlara aktarır. Operasyonel likidite modeli iadeler ve ödemeler için rezerv bırakır, fazlasını dışarı gönderir. Eşik modeli ancak işlem maliyetini karşılayan tutarı çeker.
Politikayı varlık-ağ düzeyinde tanımlayın; ağ ücretleri, onaylar ve likidite koşulları farklıdır.
Mutabakat ekonomisi kullanılabilir net tutarla ölçülür
Ödeme ekranındaki brüt değer, işletmenin kullanabileceği para değildir. Net tutar; ödeme işlem ücreti, dönüşüm, ağ ve çekim maliyetleri ile düzeltmeler düşüldükten sonra kalan değerdir.
Anında dış transfer varlık kontrolünü artırır ama zincir üstü işlem sayısını yükseltir. Dahili veya planlı mutabakat transfer masrafını azaltırken sağlayıcı bakiyesine maruz kalmayı artırır. Dönüşüm hazine değerini sadeleştirir ancak fiyat gerçekleşmesi ve likiditeye bağımlılık getirir.
Sıkışık ağ, yüksek ücret, stablecoin itfa kısıtları ve banka çalışma saatlerini stres senaryolarında inceleyin. OxaPay'in güncel fiyatlandırmasını kontrol edin ve tüm rotalarda aynı maliyet olduğunu varsaymayın.
Kaynaklar ve belgeler: OxaPay — fiyatlandırma
Mutabakat kayıtları paranın tüm yolunu açıklamalıdır
Transfer tamamlanmış olsa bile finans ekibi hareketi açıklayamıyorsa operasyonel kayıt eksiktir. Ödeme ve mutabakat kimliklerini, alınan varlık/ağ/tutarı, hedef varlığı, net değeri, kuru ve tarihini, ücretleri, hedef adresi, ağ işlemini ve başlangıç, bitiş, hata zamanlarını saklayın.
Mutabakat durumu ödeme durumundan ayrıdır. Dış çekim başarısız olduğunda müşterinin ödemesi tekrar ödenmemiş sayılmaz; olay yeniden deneme, rota değiştirme, dahili bakiyeye dönüş veya inceleme gerektirir.
Yeniden denemeler idempotent olmalı, tekrarlanan talep ikinci transfer üretmemelidir. Dönüşüm hatası için varlığı koruma veya manuel inceleme seçeneği belirleyin. OxaPay Swap ve Payout geçmişleri delil sağlar.
| Kayıt alanı | Operasyonel amaç |
|---|---|
| Ödeme ve mutabakat kimlikleri | Siparişi mutabakat adımlarıyla ilişkilendirir |
| Kabul edilen varlık, ağ ve tutar | Müşterinin gerçekten ödediği değeri korur |
| Mutabakat varlığı ve net tutar | Satıcının kullanabileceği değeri gösterir |
| Kur, zaman ve dönüşüm kimliği | Dönüşümü ve fiyat farklarını açıklar |
| Hedef ve ağ işlem kimliği | Harici transfer rotasını ve uygulamasını kanıtlar |
| Başlama, bitiş ve hata zamanları | İzleme, inceleme ve mutabakata yardım eder |
Kaynaklar ve belgeler: OxaPay — takas isteği · OxaPay — takas geçmişi
SaaS, pazar yeri ve yüksek tutarlı B2B senaryoları
Küresel SaaS birden fazla varlık kabul edip oynak olanları stablecoin'e çevirebilir, operasyonel rezervi dahili tutabilir ve planlı çekim yapabilir. Dijital varlık şirketi gelecekteki ödemeler veya hazine için aynı varlığı tutmayı seçebilir.
Pazar yerinde satıcılara olan yükümlülükler hesaplanana kadar fonlar dahili kalabilir; ardından onaylı alıcılara ödeme yapılır. Yüksek tutarlı B2B için varlık bazlı onay, izinli adresler ve ayrıntılı denetim izi önemlidir.
Müşteri tercihi ödeme yolunu belirler; işletmenin hazine gereksinimi mutabakat modelini belirler.
OxaPay bileşenleri farklı mutabakat modellerini destekler
OxaPay ödeme toplama, dahili bakiye, varlık dönüşümü ve ödeme çıkışını ayrı özellikler olarak sunar. Böylece işletme sipariş kabulünü dış çekimle karıştırmadan karma bir politika kurabilir.
Account Balance hesap içi varlıkları gösterir; Swap desteklenen varlıkları dönüştürür; Payout iç veya dış alıcılara transfer yapar. Günlük veya eşik bazlı programlar bakiyeler ve ödemeler çevresinde işletmenin otomasyonu ile uygulanabilir. Swap ve Payout geçmişi finansal inceleme için gerekli kayıtları sağlar.
Hedef varlık, rezerv, adres kuralları, zamanlama ve onay sınırlarını belirlemek yine işletmenin sorumluluğudur.
| İhtiyaç | OxaPay özelliği | Operasyonel görev |
|---|---|---|
| Dahili kullanılabilirlik | Hesap bakiyesi | Dış transfer öncesi varlıkları gösterir |
| Dönüştürülmüş mutabakat | Swap hizmeti | Desteklenen varlığı başka varlığa dönüştürür |
| Harici mutabakat | Payout hizmeti | İç veya dış alıcılara fon yollar |
| Takvim ya da eşik | Bakiye ve çekim otomasyonu | Uygun bakiyenin ne zaman taşınacağını belirler |
| Mutabakat kanıtı | Swap ve Payout geçmişleri | İşlemleri finansal kayıtlara bağlar |
Kaynaklar ve belgeler: OxaPay — takas · OxaPay — ödeme çıkışı
Mutabakat modelini seçmeden önce yedi soru
Giderler, rezervler, iadeler ve çıkış ödemeleri için hangi varlıklar gerekir? Ödeme kabul edildikten sonra ne kadar fiyat oynaklığı kabul edilir? Hangi bakiye dahili kalmalı, hangisi dış saklamaya taşınmalı? Fonlar ne kadar çabuk dışarıda kullanılabilir olmalı?
Hangi tutar çekim maliyetini makul kılar? Hangi onaylar, izinli adresler ve tekrar-deneme kontrolleri uygulanır? Hangi kayıtlar kabul edilen tutarı, dönüşümü, ücretleri, hedefi ve nihai net bakiyeyi kanıtlar?
İyi politika varlık, saklama, zaman ve ücret risklerini saklamadan öngörülebilir likidite yaratır.
Birincil kaynaklar ve uygulama belgeleri
BIS ödeme ve mutabakat sözlüğü ile dağıtık defter raporu, Bitcoin ödeme işleme rehberi, Circle Mint stablecoin ihraç ve itfa belgeleri ve Stripe ödeme takvimi dokümantasyonu bu ayrımları anlamaya yardımcı olur.
OxaPay üzerinden uygulama için güncel Account Balance, Swap ve Payout API belgelerini kontrol edin. Üretime geçmeden önce ağ desteği, ücretler ve kullanılabilirlik gibi değişken özellikleri doğrulayın.
Kaynaklar ve belgeler: BIS — ödeme ve mutabakat · BIS — dağıtık defter · Bitcoin — Bitcoin ödeme işleme · Circle Mint — stablecoin ihraç ve itfa · Stripe — ödeme takvimleri · OxaPay — hesap bakiyesi · OxaPay — takas · OxaPay — API