Kripto ödeme yaşam döngüsü ticari niyeti kullanılabilir bir operasyon kaydına dönüştürür
Kripto ödeme, blokzincirde bir işlem göründüğünde başlamaz. İşletmenin neyi, neden almayı beklediğini belirlemesiyle başlar. Ticari niyet bir siparişten, faturadan, abonelik yenilemesinden, hesap yüklemesinden, hizmet sözleşmesinden veya başka bir ticari olaydan doğabilir.
Blokzincir işlemi daha geniş sürecin yalnızca bir aşamasıdır. İşletme ödeme talebi oluşturmalı, doğru varlık ve ağ talimatlarını sunmalı, işlemi izlemeli ve taleple eşleşip eşleşmediğini belirlemelidir. Sonrasında kabul koşullarını değerlendirir, işletme eylemini gerçekleştirir, fonların mutabakatını yapar ve sonucu kayıtlarla uzlaştırır.
Döngü; ticari olay, zincir kanıtı, ödeme durumu, fonların aktarım sonucu ve iç kayıtlar çözümlenmemiş bir çelişki olmadan ilişkilendirildiğinde tamamlanır. Artık ödeme yalnızca zincirde görünmez; raporlama, destek ve muhasebe için operasyonel olarak kullanılabilir hâle gelir.
Ödeme döngüsü ticari, ağ, operasyonel ve finansal sistemler arasında ilerler
Ödemenin tamamı tek bir sistemin elinde değildir. E-ticaret platformu siparişi, ödeme platformu talep ile durumu, blokzincir işlemleri bilir. Hazine birimi fonun nerede tutulduğunu veya aktarıldığını izler; muhasebe ise sınıflandırılmış finansal kayıt ister.
Güvenilirlik bu sistemlerin bağlarının korunmasına dayanır. Sipariş referansı olmayan işlem kimliği işe yaramayabilir. Yeterli kanıt olmadan siparişi ödendi işaretlemek tehlikelidir. Kaynağı izlenemeyen bir aktarılmış bakiye finansal mutabakat riski doğurur.
- Ticari katman: sipariş, müşteri, ürün, fiyat, vergi bağlamı ve teslimat yükümlülüğü.
- Ödeme katmanı: talep, kabul edilen varlıklar, süre, durum ve istisnalar.
- Blokzincir katmanı: işlem, ağ, adres, tutar, bloğa dahil olma ve kesinleşme kanıtı.
- Finansal katman: varış hesabı, ücretler, dönüşüm, mutabakat ve kayıt.
İyi tasarım tüm sistemleri tek veritabanı yapmaz; bunlara ortak kimlikler, açık durumlar, kalıcı olaylar ve aynı ödemeyi açıklamaya yetecek kanıt sağlar.
Ticari niyet, geçerli ödemenin karşılaması gereken koşulları tanımlar
Müşteri cüzdanını açmadan önce satıcı en önemli yaşam döngüsü nesnesini, yani ödeme gerekçesini oluşturmuştur. Niyet siparişi veya yükümlülüğü, beklenen değeri, fiyatlama para birimini, müşteri bağlamını, geçerlilik süresini ve teslimat sonucunu tanımlamalıdır.
Ödeme platformu bunu ödeme talebine çevirir. OxaPay Generate Invoice belgeleri bir API isteğinin tutar, fiyatlama birimi ve geçerlilik süresiyle birlikte sipariş kimliği, callback adresi ve ödeme işleme seçeneklerini taşıyabileceğini gösterir. Bu alanlar biçimsel değildir; daha sonra uygulanacak ticari koşulları belirler.
| Niyet alanı | Yanıtladığı soru | Döngüye katkısı |
|---|---|---|
| Sipariş veya ödeme referansı | Bu ödeme hangi ticari olaya bağlı? | Kanıtı satıcı sistemlerine bağlar. |
| Beklenen tutar ve fiyat para birimi | Müşteri hangi değeri ödemeli? | Tutar kontrolü ve sonraki mutabakatı destekler. |
| Geçerlilik süresi | Teklif ve talimatlar ne zamana kadar geçerli? | Geç ödeme ve yeniden fiyatlamayı belirler. |
| Kabul politikası | Kısmi veya farklı tutarlar nasıl yönetilir? | Fon geldikten sonra doğaçlama kararları engeller. |
Bu yaklaşım kriptoya özgü değildir. Stripe Payment Intents de durumu süreç içinde değişen ödeme nesnesi kullanır. Kriptoda ağ, varlık, adres, işlem kanıtı ve onay davranışı ayrıca operasyonel değerlendirmeye katılır.
Bu bölümün kaynakları: OxaPay Docs · Stripe Docs
Ödeme talebi ticari koşulları uygulanabilir müşteri talimatlarına çevirir
Müşteri soyut bir niyeti doğrudan ödeyemez. Tutarı, varlığı, ağı, hedefi, süre sonunu ve mevcut durumu belirten somut bir talep gerekir. Bu; barındırılan fatura, white-label ödeme sayfası, ödeme bağlantısı, QR kodu veya iç müşteri referansıyla ilişkili sabit adres olabilir.
Varlık ve ağ ayrı alanlar olmalıdır. Aynı token sembolü farklı ağlarda bulunabilir; adres, ücret, onay politikası ve kurtarma seçenekleri değişebilir. Üretim entegrasyonu, OxaPay Supported Currencies gibi güncel kaynaktan seçenekleri almalı; kalıcı sabit listeye güvenmemelidir.
Talep kalıcı bir iç kimliğe de ihtiyaç duyar. Checkout sonrası ödeme sayfası bağlantısı kaybolsa bile işletmenin sipariş kimliği ile sağlayıcının ödeme kimliği arasındaki ilişki, durum sorgusu, destek ve finansal mutabakat için korunmalıdır.
Bu bölümün kaynakları: OxaPay Docs
Müşteri işletmenin sonucunu değil, ağ işlemini yetkilendirir
Müşteri cüzdanda onay verdiğinde cüzdan seçilen ağa özgü işlemi oluşturup imzalar. Yetkilendirilen şey o işlemin kesin verileridir; satıcının sipariş durumu, teslimat akışı veya muhasebe kaydı değildir.
İşlem ardından ağa girer. Bitcoin'in resmi ödeme işleme kılavuzu gönderici ve alıcının görevlerini ayırır. Ethereum işlemi bir hesabın başlattığı kriptografik imzalı talimat olarak açıklar. Bu protokol eylemleri, ödeme sisteminin yorumlayacağı kanıtı üretir.
Anlamlı bir kanıt ortaya çıkmadan da süreç başarısız olabilir: cüzdan isteği reddeder, müşteri sayfayı kapatır, işlem yayınlanmaz veya ağ kullanılamaz. Bu nedenle “talep gösterildi”, “cüzdan açıldı” ve “işlem gözlendi” aynı kilometre taşı değildir.
Bu bölümün kaynakları: Bitcoin Developer Guide
Tespit bir faaliyet olduğunu gösterir, ödemenin kabul edildiğini değil
İzleme altyapısı blokzincir faaliyetlerini gözlemler ve aday işlemleri bulur. Ağ, sağlayıcı ve risk politikasına göre pending aşamasında veya bloğa dahil olduktan sonra tespit yapılabilir. İşlem hash'i, adres, varlık, ağ, tutar, zaman, blok referansı ve onay bilgileri görülebilir.
Ardından aday işlem ödeme talebiyle eşleştirilir. Yalnız hedef adres yeterli olmayabilir; beklenen varlık, ağ, tutar, süre aralığı, memo/tag, benzersiz adres, müşteri referansı ve sağlayıcı ödeme kimliği de gerekebilir.
OxaPay Payment Information API birleştirilmiş kaydı örnekler: track ID, sipariş ID, durum, beklenen tutar, işlem listesi, ağ, adres ve hash aynı bağlamdadır. Bu, tek bir işlem kimliğinden çok daha kullanışlıdır.
Bu bölümün kaynakları: OxaPay Docs
Kabul, gözlemlenen ödemenin işletme politikasını karşılaması kararıdır
Tespit ve eşleştirmeden sonra sistem varlığı, ağı, tutarı, zamanı ve işlem kanıtını satıcının kurallarıyla karşılaştırır. Ödeme kullanılabilir sayılmadan önce ağa özgü güven eşiği de uygulanır.
Onay yalnızca bir girdidir. Solana RPC çağrıları ve abonelikleri commitment düzeyi belirlemeye izin verir; Bitcoin'de sıklıkla blok derinliği değerlendirilir; diğer ağlar checkpoint veya farklı kesinleşme sinyalleri kullanır.
Sağlayıcı durumları işletmenin iç durumlarına dikkatle eşlenmelidir. OxaPay tablosu New, Waiting, Paying, Paid, Underpaid, Expired, Refunding ve Refunded durumlarını ayırır. Satıcı hangisinin rezervasyon, teslimat, hesap etkinleştirme veya manuel incelemeye izin verdiğini belirler.
| Döngü sinyali | Kanıtladığı | Kanıtlamadığı |
|---|---|---|
| Talep oluşturuldu | Beklenen ödeme koşulları mevcut. | Müşterinin ödeme denediği. |
| İşlem tespit edildi | İlgili ağ faaliyeti görünür. | İşletme politikasına uyulduğu. |
| Ödeme kabul edildi | Mevcut kanıt kuralları karşılar. | Sonraki tüm eylemlerin tamamlandığı. |
| Döngü sonuçlandı | Operasyon ve kayıt devri bitti. | İleride iade veya destek yükümlülüğü olmayacağı. |
Bu bölümün kaynakları: OxaPay Docs
Kabul edilen ödeme olayları tekrarlı eylem oluşturmadan sistemlere ulaşmalıdır
Ödeme gerekli duruma geldiğinde sonraki servisler stok ayırabilir, hesabı etkinleştirebilir, dijital ürünü verebilir, makbuz gönderebilir, CRM güncelleyebilir veya mutabakat sürecini başlatabilir. Bunlar genelde blokzincir ve ödeme sayfası dışında gerçekleşir.
Webhook yaygın bir aktarımdır. OxaPay belgeleri JSON durum bildirimini, callback doğrulamasını, gerekli yanıtları ve yeniden denemeleri açıklar. Olay aktarımı eşzamansızdır; gecikebilir veya tekrarlanabilir. Alıcı doğrulamalı, kaydetmeli ve güvenli biçimde işlemelidir.
Stripe webhook ve idempotent request kılavuzları aynı dağıtık sistem ilkesini açıklar. İdempotent işleme ikinci teslimatı, iki kez bakiye yüklemeyi ve yinelenen muhasebe kaydını önler.
Bu bölümün kaynakları: OxaPay Docs · Stripe Docs
Fonların mutabakatı ekonomik değerin nerede kullanılabilir olacağını belirler
Kabul ve settlement ilişkili ama farklıdır. Kabul ödemenin satıcı politikasına uyup uymadığını belirler; settlement ise değerin nerede tutulduğunu, hesaba geçtiğini, dönüştürüldüğünü, zamanlandığını veya aktarıldığını açıklar.
İşletme alınan varlığı saklayabilir, başka desteklenen varlığa dönüştürebilir, iç bakiye alacaklandırabilir veya harici cüzdana gönderebilir. Her rota ücret, kur farkı, yeni zaman ve ek işlem kimlikleri doğurabilir; hepsi kaynak ödeme ile bağlantılı kalmalıdır.
Settlement ödeme kaydının üzerine yazmamalıdır. İlk ticari tutar, müşterinin gönderdiği miktar, alınan varlık, ağ kanıtı, sağlayıcı ücreti, dönüşüm sonucu ve hedef transferi farklı olgulardır. Ayrı tutulmaları inceleme ve mutabakatı kolaylaştırır.
Finansal mutabakat döngü kanıtını kalıcı bir kayda dönüştürür
Mutabakat, ödeme sürecindeki sistemleri karşılaştırır. Sipariş sistemi neyin ödenmesi gerektiğini, ödeme platformu hangi talebin oluşturulup hangi duruma ulaştığını, blokzincir işlem kanıtını, settlement sistemi değerin nerede kullanılabilir olduğunu söyler. Ücretler ve dönüşümler brüt/net farkını açıklar.
OxaPay Payment History API filtrelenebilir ödeme ve işlem düzeyi ayrıntılar sunar. Payment Statistics, operasyon raporları için ödeme para birimine göre sayı ve alınan tutarları toplar.
İyi bir kayıt beş soruya yanıt verir: ne istendi, ne ödendi, ağ neyi kanıtladı, işletme ne yaptı ve değer sonunda nereye ulaştı? Sıralamayı yeniden kuracak kimlikler ile zaman damgaları da saklanmalıdır.
- Ticari kanıt: sipariş ID, müşteri, ürün, beklenen tutar ve fiyat para birimi.
- Ödeme kanıtı: ödeme ID ve türü, durum geçmişi, süre ve kabul politikası.
- Ağ kanıtı: varlık, ağ, adres, işlem hash'i, blok ve güven verisi.
- Finansal kanıt: brüt değer, ücret, dönüşüm, net değer ve settlement hedefi.
Burada “finansal kayıt”, muhasebeyi besleyebilen tam ve izlenebilir ödeme dosyasıdır. Nihai yevmiye kaydı, değerleme, vergi ve saklama süresi işletmeye, muhasebe çerçevesine ve mevzuata bağlıdır.
Bu bölümün kaynakları: OxaPay Docs · OxaPay Docs
Olaylar değişimi, durumlar bugünü, kayıtlar kanıtı gösterir
Bu kavramlar sık karıştırılır. Olay işlem tespiti veya Paid durumuna geçiş gibi gelişmeyi bildirir. Durum ödemenin şu anki yorumunu özetler. Kayıt, bu yorumu açıklayan geçmişi ve olguları korur.
| Kavram | Örnek | Operasyonel kullanım |
|---|---|---|
| Olay | PaymentStatusChanged | Değerlendirme veya sonraki iş akışını tetikler. |
| Durum | Paid | Güncel ödeme yorumunu gösterir. |
| Kayıt | Sipariş, ödeme, işlem, ücret, settlement, zaman | Denetim, destek, mutabakat ve raporu destekler. |
Yalnızca son durumu saklayan sistem buraya nasıl geldiğini açıklayamayabilir; yalnızca olay saklayan sistemde sorgulama zor olabilir. Olgun tasarım olay geçmişini, güncel durumu ve kalıcı işletme kaydını birlikte korur.
Müşteri basit bir yolculuk, işletme ise eksiksiz döngü ister
Müşterinin gördüğü yol kısa olmalı: talebi açmak, varlık ve ağı doğrulamak, işlemi onaylamak ve açık durum görmek. Satıcının süreci daha uzundur; müşteri ayrıldıktan sonra da belirsizliği yönetir.
İyi deneyim bütün iç durumları göstermeyi gerektirmez. Bekleniyor, işlem tespit edildi, onaylanıyor, tamamlandı, süre doldu veya eylem gerekiyor gibi anlaşılır mesajlar sunar. Arkada ayrıntılı kanıtlar ve kesin politikalar gerekir.
Farklı ağlar farklı adaptörler ister; işletme döngüsü tutarlı kalmalıdır
Bitcoin, Ethereum, Solana, TON, TRON ve diğer ağların işlem, onay, ücret ve kesinleşme davranışları aynı değildir. Ödeme sistemi bu farkları ağ katmanında anlamalı, ama satıcı her zincir için ayrı sipariş süreci çalıştırmamalıdır.
Soyutlama sınırı yaşam döngüsüdür. Ağ adaptörleri işlem tespit edildi, güven güncellendi, ödeme kabul edildi veya başarısız oldu gibi ortak gözlemler üretir. İşletme katmanı ödeme kimliği ve satıcı politikasına göre tutarlı eylemler uygular.
Standartlaştırma önemli farkları silmemelidir. Bir ağdaki “tespit edildi” sinyali başka ağdakinden farklı risk taşır. Ortak durum adları kullanılabilir; altta ağa özgü kanıt ve kabul eşiği korunmalıdır.
İstisnalar yaşam döngüsünün dışı değil, alternatif dallarıdır
Ödeme eksik, fazla, geç veya yinelenmiş olabilir. Yanlış ağ kullanılabilir, yanlış taleple eşleşebilir veya beklenen süreden fazla gecikebilir. Bu durumlar döngüyü terk etmez; tanımlı karşılık gerektiren ayrı bir dala geçer.
Genel model istisnanın nerede belirlendiğini ve sonraki karardan kimin sorumlu olduğunu gösterir. Tutar veya eşleştirme sorunları karşılaştırmada, ağ güveni kabulde, mükerrer olaylar orkestrasyonda, settlement ve muhasebe farklılıkları finansal mutabakatta ortaya çıkar.
Ayrıntılı istisna politikaları özel operasyon tasarımına aittir. Döngü seviyesinde belirsizlik açık bir durum veya iş kuyruğu olmalı; günlüklerde, müşteri mesajlarında ya da elle destek görüşmelerinde gizlenmemelidir.
Güvenilir döngü her sistem devrinde ölçülebilir
İzleme yalnızca toplam ödeme hacmini ölçmemelidir. Faydalı metrikler müşterinin nerede ayrıldığını, ağ gecikmesini, işletme sistemindeki yanıt sorununu ve kayıtların nerede ayrıştığını gösterir.
- Dönüşüm: oluşturulan talepler, açılan cüzdanlar, görülen işlemler, kabul edilen ödemeler.
- Zaman: ödeme, tespit, kabul, teslimat ve settlement'a kadar süre.
- Güvenilirlik: webhook tekrarları, yinelenen olaylar, başarısız işlemler, bekleyen ödemeler, manuel inceleme.
- Kayıt: eşleşmeyen işlemler, uzlaştırılmayan ödemeler, ücret farkları, eksik kimlikler.
Her aşamanın sorumlusu ve kurtarma yolu olmalıdır. Ekip kayıp işlemi kimin araştıracağını, geç ödemeye kimin onay vereceğini, webhook'u nasıl kurtaracağını ve mutabakat farkını nasıl yükselteceğini bilmelidir.
OxaPay işletmenin kendi operasyonuna bağlayacağı ödeme nesneleri ve olayları sağlar
OxaPay fatura akışında işletme talebi oluşturur ve dönen ödeme referansını kendi sipariş kimliği yanında saklar. Müşteri barındırılan ödeme adımlarını tamamlar. İşletme webhook ile durum değişiklikleri alabilir ve doğrulama veya kurtarma gerektiğinde güncel ödeme ayrıntısını çekebilir.
OxaPay durumları doğrudan her callback'te teslimat yapmak yerine iç eylemlere eşlenmelidir. Callback gerçekliği doğrulanmalı, doğru yanıt verilmeli, sonraki işlemler idempotent yapılmalı ve işlem ayrıntıları sonraki analiz için saklanmalıdır.
Ödeme geçmişi ve istatistikleri operasyon ve raporu destekler; sipariş, settlement ve muhasebe kayıtlarının yerine geçmez. Sipariş ID, OxaPay ödeme ID, durum geçmişi, işlem verisi, ücret ve fon aktarımı arasındaki kalıcı ilişki faydalı kaydı oluşturur.
Döngünün her aşaması farklı belirsizliği azaltır
Ticari niyet işletmenin beklentisini açıklar; ödeme talebi müşteriye nasıl ödeyeceğini söyler; tespit ilgili ağ faaliyetinin varlığını gösterir; eşleştirme ve kabul bu faaliyetin satıcı politikasına uygunluğunu belirler.
Olay aktarımı iç sistemlerin sonucu öğrenip öğrenmediğini, settlement değerin nerede kullanılabildiğini, finansal mutabakat ise ticari, ödeme, ağ ve mali kayıtların aynı sonucu anlatıp anlatmadığını netleştirir.
Bu yüzden kripto ödeme platformu yalnızca adres üretmesi veya işlemi görmesiyle değerlendirilmemelidir. Asıl gereklilik sürekliliktir: her aşama bir sonrakinin güvenli, açıklanabilir ve kurtarılabilir karar vermesi için yeterli bağlamı saklamalıdır.
Bu yaşam döngüsü modelinde kullanılan birincil belgeler
Kaynaklar OxaPay Generate Invoice, Payment Information, Payment Status Table, Webhook ve Payment History belgeleri; Bitcoin ödeme işleme kılavuzu, Ethereum işlemleri, Solana RPC commitment seviyeleri ve Stripe Payment Intents, Webhooks ve Idempotent Requests açıklamalarıdır.
Bu bölümün kaynakları: OxaPay — Fatura oluşturma · OxaPay — Ödeme bilgileri · OxaPay — Ödeme durumları · OxaPay — Webhook · OxaPay — Ödeme geçmişi · Bitcoin — Ödeme işleme · Ethereum — İşlemler · Solana — RPC ve commitment · Stripe — Payment Intents · Stripe — Webhook · Stripe — İdempotent istekler