Kripto Ödeme Sistemi Mimarisi: Blokzincirden Gerçek Ödemelere

Kripto ödemeler yalnızca bir blokzincir üzerinde işlem göndermekten ibaret değildir.

Bir işletme için kripto ödeme, blokzincirden önce, blokzincir üzerinde ve blokzincirden sonra doğru şekilde çalışması gereken çok katmanlı bir sistemdir.

Gerçek bir ödeme sistemi şu sorulara cevap verebilmelidir:

• Ne için ödeme yapılıyor?
• Ödeme nasıl alınmalı?
• Nasıl yorumlanmalı?
• Ne zaman kabul edilebilir?
• Ve nasıl gerçek bir iş aksiyonuna dönüştürülmeli?

Blokzincir tek başına bu kavramların hiçbirini anlamaz.
Blokzincir yalnızca değer transferini kaydeder, ticari ödemeyi değil.

OxaPay bu gerçeği en başından fark etti ve sistemini basit bir cüzdan veya araç olarak değil, eksiksiz bir ödeme altyapısı olarak tasarladı.

Bu sayfada bu mimariyi adım adım açıklıyoruz.

Bu mimari, birden fazla blokzincir ağı üzerinde kripto ödeme sistemleri kurma ve işletme konusundaki gerçek dünya deneyimlerinden türetilmiştir. Ağ yoğunluğu, zincir yeniden düzenlemeleri, kısmi ödemeler ve gecikmeli onaylar gibi zorlu koşullar, ödeme durumu yönetimi ve iş mantığına yaklaşımımızı doğrudan şekillendirmiştir.

“Ödeme” Tanımı Neden Bir İşlemin Ötesine Geçer

Ödeme yalnızca bir işlem göndermek olarak görülürse, iş mantığıyla olan bağlantısı ortadan kalkar.

Bir işletmenin, işlemin ne için yapıldığını, hangi zaman aralığında geçerli olduğunu ve kabul koşullarını karşılayıp karşılamadığını bilmesi gerekir.

Bu bilgiler olmadan rastgele bir transfer ile geçerli bir ödeme arasında fark yoktur.

Bu ayrım, çalışan her ödeme sisteminin en temel gereksinimidir.

Kripto Ödemeler Neden Doğası Gereği Karmaşıktır?

Banka sistemlerinin aksine, blokzincirler ticari ödemeler için tasarlanmamıştır.

Blokzincir protokol katmanında:

• Fatura yoktur
• Sipariş yoktur
• Son kullanma süresi yoktur
• Eksik veya fazla ödemenin bir anlamı yoktur
• “Ödeme kabulü” kavramı yoktur

Blokzincirin kaydettiği tek şey şudur: değer transferi.

Beklenen tutar, zaman geçerliliği, ödeme durumu, sipariş eşleştirmesi ve yanlış ağ tespiti gibi gerçek bir ödeme için gerekli tüm kavramlar, blokzincir protokolü içinde değil uygulama katmanında inşa edilmelidir.

Süreç Olarak Bir Kripto Ödeme Sisteminin Zihinsel Modeli

Sağlıklı bir kripto ödeme sistemi tek bir olay olarak değil, bir süreç olarak anlaşılmalıdır.

Pratikte bu süreç iki ayrı bölüm etrafında yapılandırılır.

Kavramsal ön koşul (akıştan önce):

• Ödeme beklentisinin tanımlanması

Ödeme akışı (işleme aşamaları):

• İşlem tespiti
• İşlem yorumlama
• Ödeme durumuna dönüştürme
• Olay üretimi
• İş aksiyonlarının yürütülmesi
• Mutabakat ve finansal operasyonlar

Blokzincir bu akışın yalnızca bir bileşenidir, tüm sistem değildir.

Her işleme aşaması bir önceki aşamanın doğrulanmış sonuçlarına bağlı olduğundan, ödeme kararları tek bir anda verilemez. Gecikmeleri, kısmi ödemeleri ve ağ istikrarsızlığını, ham blokzincir verisini nihai ödeme gerçeği olarak kabul etmeden yönetmek için süreç odaklı bir model gereklidir.

Blokzincirden Önce Ne Olur?

Bir işlem blokzincir üzerinde oluşturulmadan önce ödeme sistemi zaten şunları bilmelidir:

• Ne için ödeme yapıldığı
• Tam tutar
• Ödemenin hangi sipariş veya hizmete ait olduğu
• Hangi kripto paraların ve ağların izinli olduğu
• Ödemenin ne zamana kadar geçerli olduğu

Bu aşamada ödeme beklentisi oluşturulur.

Ödeme beklentisi soyut bir kavram değildir. Gelecekteki blokzincir işlemlerinin doğru şekilde eşleştirilmesini ve yorumlanmasını sağlayan somut bir kimliğe sahip olmalıdır.

Ödeme yöntemine ve kullanım senaryosuna bağlı olarak bu kimlik farklı biçimler alabilir:

• Belirli bir fatura için üretilmiş benzersiz bir blokzincir adresi
• Bir referans veya dahili eşleme mantığıyla birleştirilmiş statik adres
• Önceden tanımlı bir beklentiye bağlı ödeme linki oturum kimliği

Biçimi ne olursa olsun amaç aynıdır: Sisteme gelen işlemleri beklenen bir ödemeyle deterministik biçimde eşleştirmek.

Açıkça tanımlanmış bir beklenti olmadan işlemler bağlamdan yoksun şekilde gelir ve fonlar blokzincirde alınmış olsa bile güvenilir biçimde yorumlanamaz.

Ödeme Karar Referansı Olarak Fatura

Kripto ödeme sisteminde fatura bir makbuz değildir. Herhangi bir blokzincir işlemi gerçekleşmeden önce oluşturulan bir ödeme sözleşmesidir.

Bir fatura oluşturulduğunda, sistemin blokzincirin anlamadığı verileri tanımlaması gerekir:

• Referans ödeme tutarı
• Referans para birimi (USD veya EUR gibi)
• İzinli kripto paralar ve ağlar
• Ödeme son kullanma zamanı
• Sipariş veya hizmet tanımlayıcısı
• Ödeme kabul kuralları

Bu bilgiler gelen işlemlere anlam kazandırır ve hangi ödemelerin geçerli, reddedilmiş veya iş açısından uygulanabilir olduğunu belirler. Onaydan mutabakata kadar tüm sonraki kararlar fatura tanımına dayandığı için, ödeme yaşam döngüsünün birincil karar referansı haline gelir. Açıkça tanımlanmış bir fatura olmadan, blokzincir işlemleri iş mantığıyla güvenilir bir bağ kuramayan izole değer transferleri olarak kalır.

Ödeme Adresi Üretimi ve Bağlam Kaybı Riski

Bir kripto ödeme sisteminde ödeme adresi üretmek, basitçe bir blokzincir adresi kullanmaktan farklıdır. Doğru bir ödeme mimarisinde adres yalnızca bir hedef değil, bir yorumlama noktasıdır.

Sistem bir ödeme adresi ürettiğinde, bu adresi belirli bir ödeme beklentisi ve kabul kurallarıyla ilişkilendirir. Bu bağlantı, gelen işlemlerin bir sipariş veya hizmetle doğru şekilde eşleştirilmesini ve geçerlilik açısından değerlendirilmesini sağlar.

Bu bağlamsal bağlantı olmadan bir adres tehlikelidir. Fonlar alınsa bile sistem nasıl tepki vereceğini bilemez; bu da hatalara, yanlış sınıflandırmalara ve finansal anlaşmazlıklara yol açar.

Katman Bir: Blokzincir ve Gerçekleri

En alt katmanda blokzincir yer alır.

Bu katmanda:

• İşlemler geri döndürülemez
• Onay zaman alır
• Ağ yoğunluğu gecikmelere neden olur
• Nihailik ağlara göre farklılık gösterir

Ortalama bir kullanıcı için bu katman tüm ödeme gibi görünür.

Ancak bir ödeme sistemi için blokzincir yalnızca ham veri kaynağıdır.

Blokzincir bir ödeme sistemi değildir. Yalnızca değer transferi katmanıdır.

Ödemelerde Blokzincirin Doğal Sınırlamaları

Blokzincir, kesin nihai zamanlama veya durum istikrarı garantisi vermez.

Bu nedenle, kararları doğrudan blokzincir verisine dayandırmak risklidir.

Bir ödeme sistemi, blokzincir verisini nihai sonuç olarak değil ham girdi olarak ele almalıdır.

Blokzincirden Sisteme Ne Girer?

Blokzincirden sisteme giren şey:
bir “ödeme” değildir,
bir “başarı” değildir,
sadece ham işlem olaylarıdır.

Bu veriler henüz şunları bilmez:
hangi ödeme beklentisine ait olduklarını,
güvenilir olup olmadıklarını,
ya da bunlara dayanarak karar verilip verilemeyeceğini.

Bu aşamada henüz bir ödeme gerçekleşmemiştir.

Blokzincir Verisinin Doğası

Blokzincir verisi işlem hash’leri, adresler, tutarlar ve onay durumu gibi teknik bilgilerden oluşur.

Bu veriler ödeme niyeti veya ticari kabul hakkında hiçbir bilgi içermez.

Bir ödeme sistemi bu veriyi doğrudan “ödeme” olarak ele alırsa, ciddi hataların riski çok yükselir.

Katman İki: İşlem İzleme ve Yorumlama

Bu katmanda sistem blokzinciri hedefli bir şekilde izler.

Tüm işlemleri gözlemlemek için değil, yalnızca sistemin zaten beklediği işlemleri bulmak için.

Bu aşamada sistem şunları kontrol eder:

• İşlemin mempool’da mı yoksa onaylı mı olduğu
• Kaç onaya sahip olduğu
• Yeniden düzenleme (reorg) riski olup olmadığı
• Tam tutarın mı yoksa daha düşük bir tutarın mı gönderildiği
• İşlemin izinli bir ağda yapılıp yapılmadığı

Basit izleme yeterli değildir, çünkü ağ davranışı her zaman istikrarlı değildir.

İşlem Yorumlama Neden Hassas Bir Problemdir?

Bir işlem onaylanmış olabilir ancak daha sonra bir reorg nedeniyle ortadan kaybolabilir.

Sistem bu riski dikkate almazsa, sonradan yok olan bir ödemeyi geçerli kabul edebilir.

Bu katman, istikrarsız blokzincir verisini güvenilir bilgiye dönüştürmekten sorumludur.

Sadece Bir İşlemi Görmek Neden Yeterli Değildir?

Bir işlemi görmek “blokzincirde bir şey oldu” anlamına gelir.

Bir ödeme ise “buna dayanarak aksiyon alabilirim” demektir.

Bu fark, bir blokzincir aracı ile gerçek bir ödeme sistemi arasındaki sınırdır.

Ödeme Sisteminde Karar Sınırı

Karar sınırı, bir ödeme sisteminin geri döndürülemez iş aksiyonlarını tetiklemesine izin verilen noktadır.

Bu sınırdan önce blokzincir verisi geçicidir ve istikrarsızdır. İşlemler gecikebilir, yeniden düzenlenebilir, eksik ödenebilir veya kopyalanabilir.

Bu sınırı çok erken geçmek ödeme hatalarının yaygın bir nedenidir. Teslimat veya mutabakat tetiklendiğinde sonucu geri almak maliyetli veya imkansız hale gelir.

Doğru bir ödeme sistemi, işlem görünürlüğünü ödeme kabulünden ayırır. Yalnızca doğrulanmış tutarlar, onaylanmış ağlar ve teyit edilmiş durumlar bu sınırı geçebilir.

Katman Üç: Ödeme Durumları

Bu katmanda yorumlanan işlem bir ödeme durumuna dönüştürülür.

Yaygın ödeme durumlarına örnekler:

• Created
• Pending
• Detected
• Paid
• Confirmed
• Completed
• Expired
• Underpaid
• Invalid Network

Bu durumlar ödeme sistemi ile iş mantığı arasındaki ortak dildir.

İşletmeler kararlarını işlem hash’lerine değil durumlara göre verir.

Durumlar Olmadan Ödeme Kontrolü Neden İmkansızdır?

Durumlar ödeme yaşam döngüsünü açık hale getirir.

Onlar olmadan sistem parçalı verilere dayanarak karar vermek zorunda kalır.

Durumlar otomasyonun, raporlamanın ve hata yönetiminin temelini oluşturur.

Ödeme Durumu Sadece Dahili Kullanım İçin Değildir

Her durum değişikliği önemli bir olayı temsil eder.

Her değişiklik:

• Kaydedilmeli
• İzlenebilir olmalı
• Harici sistemlere iletilmeli

İşte burada ödeme olayı kavramı oluşur.

Durum Değişikliklerinin Kaydedilmesinin Önemi

Durum değişiklikleri kaydedilmezse, anlaşmazlıklar veya finansal incelemeler sırasında ödeme yolunu yeniden oluşturmak imkansız hale gelir.

Doğru durum kaydı destek ve denetim için kritiktir.

Durumdan Olaya: Ödeme Sisteminin Çekirdeği

Her ödeme durumu değiştiğinde sistem bir olay üretir.

Bu olay neyin değiştiğini, ne zaman değiştiğini ve neden değiştiğini tanımlar.

Webhook’lar bu olayların yalnızca iletim mekanizmasıdır, sistemin çekirdeği değildir.

Bir webhook birden fazla kez iletilirse, sistem yan etki olmadan aynı kararı tekrar edebilmelidir.

Olaylar Sistem Kararlılığı İçin Neden Kritiktir

Ağlar güvenilir değildir ve gecikmeler veya çoğaltmalar kaçınılmazdır.

Olay tabanlı ve idempotent bir tasarım, sistemin istikrarsız koşullar altında bile doğru şekilde davranmasını sağlar.

Dördüncü Katman: Ödeme Mantığı

Bu katmanda sistem şunlara karar verir:

• Ödemenin zamanında yapılıp yapılmadığı
• Tutarın kabul edilebilir olup olmadığı
• Ödemenin süresinin dolup dolmadığı
• Dönüşüm oranlarının nasıl hesaplanacağı
• Ödemenin hangi hizmete bağlanacağı

Ancak tek başına bir karar yeterli değildir.

Bir karar mutlaka bir aksiyona yol açmalıdır.

Ödeme Mantığı Neden Bağımsız Olmalıdır

Ödeme mantığı, sıkça değişen iş kurallarından oluşur.

Bu mantık doğrudan blokzincire bağlanırsa, sistem kırılgan hale gelir.

Bu katmanın ayrıştırılması, iş kurallarının tüm sistemi etkilemeden değiştirilebilmesini sağlar.

Beşinci Katman: Ödeme Toplama Yöntemleri ve Rolleri

Farklı ödeme yöntemleri ayrı sistemler değildir.

Bunlar yalnızca paylaşılan bir çekirdeğe açılan farklı giriş noktalarıdır.

• Ödeme Linki
• Fatura
• Statik Adres
• POS
• Eklenti
• Özel Akış

Tüm bu yöntemler bir ödeme beklentisi oluşturur, aynı mantığa bağlanır ve aynı durumlar ile olayları kullanır.

Paylaşılan Bir Çekirdeğin Önemi

Her ödeme yönteminin kendi bağımsız mantığı olsaydı, sistem hızla tutarsız hale gelirdi.

Paylaşılan bir çekirdek, ödeme kurallarının ve davranışlarının tüm senaryolarda tutarlı kalmasını sağlar.

Altıncı Katman: Finansal Operasyonlar ve Mutabakat

Bir ödeme nihai hale geldikten sonra sistem operasyonel aşamaya girer:

• Bakiye yönetimi
• Gerektiğinde para birimi dönüşümü
• Para çekme ve mutabakat
• Raporlama
• Muhasebe

Bu aşama, ödeme sürecinin doğal bir devamıdır, ondan ayrı bir şey değildir.

Her finansal operasyon bir ödeme durumuna bağlı olmalı, izlenebilir ve denetlenebilir olmalıdır.

Mutabakat Neden Duruma Bağlı Olmalıdır

Mutabakat, ödeme durumuna referans verilmeden yapılırsa, hatalı para çekme veya yinelenen işlemler riski artar.

Mutabakatın doğrudan ödeme durumuna bağlanması, doğru hesap uzlaştırmasını mümkün kılar.

Bu Mimari Pratikte Nasıl Çalışır

Bu mimariyi somutlaştırmak için minimal ama gerçekçi bir ödeme akışını ele alalım:

• Bir fatura oluşturulur; beklenen tutar, para birimi, ağlar ve son kullanma zamanı tanımlanır.
• Bir ödeme adresi üretilir ve bu faturaya bağlanır.
• Bir işlem mempool’da görünür ve izleme katmanı tarafından tespit edilir.
• İşlem Detected olarak işaretlenir, ancak hiçbir iş aksiyonu tetiklenmez.
• Yeterli onay ve kararlılık kontrollerinden sonra ödeme Paid ve ardından Confirmed durumuna geçer.
• Tüm kabul koşulları sağlandığında ödeme Completed durumuna ulaşır ve iş aksiyonları yürütülür.

Her durum geçişinde bir ödeme olayı üretilir.

Webhook’lar ham blokzincir aktivitesine değil, bu olaylara göre tetiklenir.

Olaylar idempotent olduğu için, webhook tekrarları veya yinelenen gönderimler hiçbir zaman yinelenen iş aksiyonlarına yol açmaz.

Bu akış, ödeme doğruluğunun yalnızca işlem görünürlüğüne değil, durum geçişlerine ve karar sınırlarına bağlı olduğunu gösterir.

Ödeme Mimarisi ile Operasyonel Hizmetlerin Eşleştirilmesi

Burada tanımlanan mimari teorik bir model değildir. Gerçek operasyonel hizmetlerle eşleştirildiğinde anlam kazanır. Bu bakış açısında hizmetler ayrı ürünler değil, ödeme beklentisini, işlem yorumlamayı, ödeme durumlarını, olayları ve mutabakatı birleşik şekilde yöneten paylaşılan bir ödeme çekirdeğiyle etkileşime girmenin farklı yollarıdır.

OxaPay tam olarak bu bağlayıcı katmanda çalışacak şekilde tasarlanmıştır. Bir blokzincir, cüzdan veya yüzeysel bir ödeme geçidi değildir. Ödeme beklentilerini blokzincir işlemleriyle bağlayarak ve ödeme durumlarını iş aksiyonlarına dönüştürerek blokzincir altyapısı ile gerçek iş ödeme mantığı arasında köprü kurar. Blokzincirlerin doğası gereği eksik olduğu katmanları uygulayarak OxaPay, kripto ödemeleri izole değer transferlerinden güvenilir, izlenebilir ve kontrol edilebilir bir operasyonel sürece dönüştürür.

Merchant Giriş Hizmetleri

Fatura

Fatura hizmeti, ödeme beklentisinin resmi ve sözleşmesel uygulamasıdır. Blokzincirlerin anlamadığı tüm bilgileri önceden tanımlar: tutar, referans para birimi, izinli ağlar, geçerlilik süresi ve kabul kuralları. Sonuç olarak, gelen her işlem doğru şekilde yorumlanabilir ve ödeme durumu yaşam döngüsüne hatasız biçimde dahil edilir.

Ödeme Linki

Ödeme Linkleri, faturalarla aynı mantığı kullanır ancak kullanıcı için minimum sürtünme sağlar. Resmi bir sürecin gerekmediği senaryolar için uygundur; yine de ödeme beklentisini, durumları ve olayları doğru şekilde oluşturur.

Statik Cüzdanlar / Statik Adresler

Statik adresler, tekrarlayan ödemeler için tasarlanmıştır. Bu modelde tek bir adres, birden fazla işlemi birleşik bir ödeme mantığına bağlayan bir ankraj görevi görür. Bu yaklaşım, durum yönetimi ve yorumlamayı kaldırmadan abonelikleri veya bakiye yüklemelerini mümkün kılar.

Beyaz Etiketli Ödeme Sayfaları

Beyaz etiketleme yalnızca sunum katmanını değiştirir. Ödeme çekirdeği, beklentiler, durumlar ve olaylar değişmeden kalır. Bu, doğru bir ödeme mimarisinin marka ve görsel görünümden bağımsız olması gerektiğini gösterir.

Eklentiler ve Entegrasyonlar

Eklentiler ve merchant API’leri, harici sistemler ile ödeme çekirdeği arasında bağlayıcı görevi görür. Bir ödeme ister bir mağazadan, ister kontrol panelinden, ister özel bir uygulamadan gelsin, tüm akışlar aynı boru hattına girer ve aynı kuralları izler.

POS ve Özel Ödeme Akışları

Merchant POS üzerinden yüz yüze ödemeler ve özel senaryolar aynı temel mimariyi kullanır. Fark yalnızca giriş noktasıdır, çekirdek sistem değil. Bu da ödeme mimarisinin yalnızca web veya çevrimiçi ticaretle sınırlı olmadığını gösterir.

Ödeme Çıkışları ve Finansal Operasyonlar

Payout ve Toplu Ödeme

Çıkış ödemeleri, yalnızca gelen ödemeler nihai bir duruma ulaştığında anlam kazanır. Payout hizmeti, ödeme durumu yaşam döngüsünün finansal yürütmeye doğrudan devamıdır. Ödeme durumlarına doğrudan bağlı olmadan yapılan payout’lara güvenilemez.

Otomatik Para Çekme ve Zamanlanmış Para Çekmeler

Otomatik veya zamanlanmış para çekmeler, payout kararlarını ödeme durumları ve finansal politikalarla ilişkilendirir. Bu, manuel, hataya açık veya izlenemez para çekmeleri önler.

Otomatik Dönüşüm

Otomatik varlık dönüşümü, mutabakat mantığının bir parçasıdır. Kullanıcı ödeme deneyimini etkilemeden, finansal operasyonlar katmanında fiyat oynaklığını yönetmek için stabil varlıklara dönüşümü mümkün kılar.

Dahili Swap

Dahili swap, varlık dönüşümünü aynı ödeme sistemi içinde gerçekleştirir. Bu, finansal operasyonların birleşik, izlenebilir ve harici hizmetlerden bağımsız kalmasını sağlar.

Mimari Özellikler Olarak Paylaşılan ve Gelişmiş Yetkinlikler

Karma Ödemeler

Karma ödemeler, yalnızca birden fazla işlemin tek bir ödeme beklentisine bağlanabildiği durumlarda mümkündür. Bu, hassas bir durum makinesi gerektirir. Aksi halde ödemeler ya erken sonlandırılır ya da yanlış sınıflandırılır.

Eksik Ödeme Yönetimi

Eksik ödeme, kripto ödemelerdeki en yaygın hata noktalarından biridir. Sistem, eksik ödemeyi mutlak bir başarısızlık değil, yönetilebilir bir durum olarak ele almalıdır. Bu, yalnızca olay tabanlı ve durum temelli bir mimaride kararlıdır.

Webhook’lar ve Gerçek Zamanlı Bildirimler

Webhook’lar karar verici değil, iletim mekanizmalarıdır. Doğru webhook tasarımı; tekrarları, gecikmeleri ve ağ hatalarını kabul ederken her olayın tek bir mantıksal reaksiyon tetiklemesini sağlar.

Çoklu Coin ve Çoklu Ağ Desteği

Mimari belirli bir ağa bağlı olmadığında, yeni bir blokzincir eklemek ödeme mantığını yeniden yazmayı değil, izlemeyi genişletmeyi gerektirir. Bu ayrım ölçeklenebilirlik ve uzun vadeli kararlılık sağlar.

Dashboard ve Yönetim Araçları

Gerçek bir dashboard yalnızca işlem listelerini değil, ödeme durumlarını, olayları ve finansal operasyonları gösterir. Değeri, en başından itibaren yapılandırılmış ve izlenebilir verilere sahip olmaya bağlıdır.

Etkileşim Kanalı Olarak Cüzdan

Bir cüzdan, diğer tüm kanallar gibi yalnızca bir etkileşim katmanıdır. Ödeme mantığı, durumlar ve finansal operasyonlar kanaldan bağımsızdır. Bu ayrım, ödeme sisteminin belirli bir platforma bağlı kalmadan farklı ortamlarda tutarlı şekilde çalışmasını sağlar.

Bu Mimari OxaPay’de Neden Önemlidir

Bu mimarinin önemi, kağıt üzerinde var olmasıyla değil, uygulandığında ortaya çıkar.

OxaPay’de her mimari katman gerçek operasyonel davranışlara doğrudan karşılık gelir: ödeme beklentileri oluşturulur, işlemler yalnızca yorumlandıktan sonra karar sürecine girer ve tanımlı durumlardan geçmeden hiçbir finansal aksiyon gerçekleşmez.

Mimari ile uygulama arasındaki bu sıkı bağ, ödemeleri izlenebilir, tekrarlanabilir ve denetlenebilir kılar.

Sonuç, ölçek büyüdüğünde ve olumsuz ağ koşulları altında bile kararlı kalan bir sistemdir.

İşlem Değil, Sistem Olarak Kripto Ödemeler

Bu mimari, kripto ödemelerin doğası gereği bir süreç olduğunu, bir blokzincir olayı olmadığını gösterir. Bir işlem, sistemin yalnızca bir girdisidir.

Bir ödemeyi gerçek kılan, blokzincirden önce ve sonra gerçekleşen kararlar, durumlar ve operasyonlar zinciridir.

Bu bakış açısında karmaşıklık ortadan kaldırılmaz, yönetilir. Sonuç olarak yalnızca işlemleri gözlemleyen değil, ödemeleri yorumlayabilen, karar verebilen ve işletmelerde güvenilir şekilde kullanılabilen bir sistem ortaya çıkar.