Çok Zincirli Ödeme Orkestrasyonu

Çok zincirli ödeme orkestrasyonu farklı blokzincirleri tek operasyonel modele bağlar

Çok zincirli ödeme orkestrasyonu, farklı blokzincirlerdeki ödeme etkinliklerini yöneten kontrol katmanıdır. Hangi varlık-ağ eşleşmesinin geçerli olduğunu belirler, seçilen rotayı ödeme isteğine bağlar, doğru zincir adaptörüne yönlendirir ve ağın yerel kanıtlarını işletmelerin kullanabileceği ortak bir ödeme sonucuna dönüştürür.

Asıl zorluk birden fazla RPC noktasına bağlanmak değildir. Adresler, işlem yapıları, kesinleşme sinyalleri, token standartları, ücretler ve hata durumları farklıyken aynı ödemenin anlamını korumaktır. Satıcı ödeme kimliği, varlık, ağ, alınan tutar, durum, mutabakat sonucu ve istisna nedenini tutarlı alanlarda görmelidir.

Temel ilke: blokzincir davranışını değil, operasyonel anlamı standartlaştırın. Her ağ kendi kurallarını korur; ödeme sistemi ortak bir iş sözleşmesi sunar.

Adaptörler, ortak olaylar ve ödeme durumlarıyla çok zincirli mimari — Adaptörler ağ kurallarını korur; orkestrasyon sonuçları ortak olay ve ödeme modeline aktarır.

Orkestrasyon ödeme rotalarını koordine eder, zincirler arasında varlık taşımaz

Orkestrasyon ile köprüleme farklı sorunları çözer. Bridge, varlığı ya da mesajı ağlar arasında aktarır; saklama, likidite, kanıt doğrulaması ve hedef ağda yürütme içerebilir. Ödeme orkestratörü ise ödemenin hangi ağda kabul edilip nasıl izleneceğine karar verir.

Bir müşteri USDT'yi desteklenen bir ağda, diğeri aynı ticari değeri başka bir ağda ödeyebilir. Orkestratörün bu parayı zincirler arasında taşıması gerekmez; doğru rotayı kaydetmesi, ilgili işlemi tespit etmesi, ağın politikasını uygulaması ve aynı tür iş sonucu üretmesi gerekir.

Orkestrasyon: rota seçimi, kapasite kontrolü, adaptör yönlendirmesi, olay normalizasyonu, politika ve durum yönetimi.
Köprüleme: varlık ve mesaj geçişi, kanıt kontrolü, likidite ve hedef ağda işlem yürütme.

Çoğu satıcı ödemesi checkout sırasında seçilen ağda tamamlanır; çok zincirli olmak her ödemenin zincirler arası olması demek değildir.

Varlık sembolü ödeme rotasını tanımlamak için yeterli değildir

USDT veya USDC gibi semboller farklı blokzincirlerde bulunabilir. Yalnızca sembolün kaydedilmesi güvenli yönlendirme, doğrulama ya da mutabakat için eksiktir. Varlığın ve blokzincir ortamının birlikte tanımlanması gerekir.

Kalıcı rota kimliği; ağ veya chain ID, varlık kimliği, gerektiğinde token sözleşmesi veya mint, ondalık hassasiyeti, adres biçimi ve Memo/Tag kurallarını kapsar. CAIP-2 standardı zincir kimliğinin açık ve taşınabilir olmasının önemini gösterir.

Kimlik alanı	Amaç	Önlenen hata
Zincir veya ağ ID	İşlemin gerçekleşmesi gereken defteri belirler.	Yanlış ağa yönlendirme ve replay karışıklığı.
Varlık veya token ID	Gerçekten gönderilen varlığı ayırır.	Sahte veya benzer adlı token kabulü.
Sözleşme, mint veya ihraççı	Token uygulamasını belirler.	Sadece sembolle eşleştirme.
Ondalık ve tutar kuralları	Gösterilen değerle temel birimi bağlar.	Yuvarlama ve ölçek hataları.
Adres ve Memo kuralları	Hedefi ve yönlendirme verisini doğrular.	Kurtarılamayan veya eşleşmeyen transferler.

Bu kimlik ödeme oluşturulmasından gözleme, mutabakata, raporlamaya ve finansal uzlaştırmaya kadar korunmalıdır. Sonradan yalnızca token adından ağ tahmin etmek hata üretir.

Bu bölümün kaynakları: CAIP-2

Kontrol düzlemi ile canlı veri düzlemini ayırın

Kontrol düzlemi hangi ağ ve varlıkların desteklendiğini, hangi politikaların yürürlükte olduğunu belirler. Veri düzlemi canlı ödemeleri işler. İkisini karıştırmak, ağ ayrıntılarının ödeme sayfasına, izleme ve hazine servislerine dağılmasına yol açar.

Kapasite kaydı: varlık, ağ, token kimliği, adres biçimi, limit ve kullanılabilirlik.
Politika motoru: rota uygunluğu, onay eşiği, istisna ve mutabakat kuralları.
Rota planlayıcı: ticari isteği izin verilen varlık-ağ eşleşmesine çevirir.
Zincir adaptörleri: RPC, işlem, blok, token ve kesinleşmeyi yorumlar.
Normalizasyon katmanı: yerel kanıtı saklayarak ortak olay üretir.
Operasyonel durum: kanıtı ödeme durumu, satıcı aksiyonu ve kayıtlarla bağlar.

Yeni ağ eklemek ideal olarak yalnızca adaptör, kapasite konfigürasyonu ve politika eklenmesini gerektirir; tüm ödeme yaşam döngüsünün değiştirilmesini değil. Bu ayrım arızaların etki alanını da sınırlar.

Seçilen rotayı para gönderilmeden önce ödeme kimliğine sabitleyin

Ödeme talebi itibari para cinsinden, kripto tutarında veya belirli bir varlık şartıyla başlayabilir. Müşteri varlık ve ağı seçtiğinde orkestratör, sonraki tespit ve doğrulamanın yetkili referansı olan rota bağlantısını oluşturur.

Rota bağlantısı: Ödeme ID + varlık kimliği + ağ kimliği + hedef + tutar kuralı + geçerlilik süresi + politika sürümü.

Politika sürümü önemlidir; açık bir ödeme sırasında ağ ayarları değişebilir. Mevcut ödeme sessizce yeni kurallarla yeniden değerlendirilmemelidir. Adres veya ödeme talimatı gösterildikten sonra rota değişmez olmalıdır. Değişiklik gerekirse eski rota denetim ve istisna için korunup yeni bir ödeme denemesi oluşturulmalıdır.

Adaptörler ağın yerel kanıtlarını yorumlar, zincirleri özdeş saymaz

Adaptör adres doğrulama, işlem sorguları, token ayrıştırma, blok veya slot gözlemi, ücret, onay kanıtları ve kaçırılmış olayları geri alma işlemlerini üstlenir.

Bitcoin benzeri UTXO ağları girdi ve çıktıları izler. EVM ağları JSON-RPC üzerinden hesap durumu, receipt, log ve chain ID sağlar. Solana imza, instruction, token hesabı, slot ve commitment kullanır. TON workchain, shardchain ve eşzamansız mesajlara dayanır. Bu veri modelleri doğrudan birbirinin yerine geçmez.

Ethereum'daki eth_chainId, işlem makbuzları ve log sorguları; Solana'daki processed, confirmed, finalized seviyeleri ve TON'un parçalar arası mesajları farklı şekilde ele alınmalıdır.

Ağ ailesi	Adaptörün izlediği	Önemli fark
UTXO	Girdiler, çıktılar, script, mempool, bloğa giriş, onay derinliği.	Bir işlem birden fazla ilgili çıktı içerebilir.
EVM	İşlemler, receipt, log, token sözleşmesi, chain ID, blok etiketleri.	Başarılı işlem ayrıca token log doğrulaması gerektirebilir.
Solana	İmzalar, talimatlar, token hesapları, loglar, slotlar, commitment.	Erken görünürlük ve son kesinleşme farklıdır.
TON	Mesajlar, hesap işlemleri, mantıksal zaman, shard ve masterchain.	Shardlar arası ilerleme basit blok sayısıyla açıklanamaz.

Bu bölümün kaynakları: Ethereum.org

Ödeme olaylarını standartlaştırırken yerel kanıtı koruyun

Normalizasyon katmanı adaptör verisini ortak olay zarfına çevirir. Sonraki servisler her RPC cevabını ayrı yorumlamak zorunda kalmaz; ancak aşırı sadeleştirme destek, denetim ve yeniden işleme için gerekli kanıtları yok eder.

{
  "event_type": "PAYMENT_TRANSACTION_OBSERVED",
  "payment_id": "pay_8471",
  "route_id": "route_32",
  "chain_id": "eip155:1",
  "asset_id": "token:0x...",
  "network_tx_id": "0xabc...",
  "amount_base_units": "25000000",
  "destination": "0xmerchant...",
  "evidence_level": "included",
  "observed_at": "2026-07-12T11:40:00Z",
  "adapter_version": "evm-4.2",
  "native_evidence": {
    "block_number": "0x...",
    "log_index": "0x...",
    "receipt_status": "0x1"
  }
}

Ortak alanlar ödeme ve rota kimliği, chain ID, asset ID, ağ işlemi, temel birimde tutar, hedef, kanıt düzeyi ve gözlem zamanını içerir. native_evidence blok numarası, log sırası, receipt sonucu ve zincire özgü verileri saklar.

Olay şeması ve adaptör sürümü de kaydedilmelidir. Yeni işlem türleri ve değişen gereksinimler nedeniyle tüketiciler kaydın hangi sürümden geldiğini bilmelidir.

Ortak ödeme durumları zincire özgü politikalardan üretilmelidir

Çok zincirli sistemlerin ortak ödeme durumlarına ihtiyacı vardır, ancak bütün ağlara aynı onay sayısını uygulamak yanlıştır. Orkestratör her adaptörden yerel kanıt alır ve rota politikasına göre ödemenin hangi aşamaya geçeceğini belirler.

Bitcoin'de onay derinliği, Solana'da processed, confirmed ve finalized; TON'da shard ile masterchain ilişkisi önemlidir. Tek bir confirmations alanı bu güvenceleri doğru açıklayamaz.

İş durumları tespit edildi, daha güçlü kanıt bekleniyor, teslimata uygun, mutabakat tamamlandı veya incelemede gibi tanımlanabilir. Her geçişi haklı kılan yerel kanıt saklanmalıdır.

Politika ilkesi: farklı yerel kanıt yolları aynı iş durumuna ulaşabilir. Adaptör kanıtı, orkestratör iş anlamını yönetir.

Önce uygun olmayan rotaları ele, sonra kalanları optimize et

Rota planlayıcı desteklenmeyen, geçici olarak kapalı, varlıkla uyumsuz, satıcı politikasına aykırı veya mutabakat için uygunsuz rotaları çıkarır. Yalnızca geçerli seçenekler sıralanır.

Uygunluk kontrolleri: desteklenen eşleşme, hizmet sağlığı, token kimliği, tutar sınırı, satıcı politikası ve mutabakat.
Sıralama ölçütleri: müşteri tercihi, cüzdan uyumu, beklenen ücret, gecikme, likidite ve operasyonel sağlık.
Çıktı: hedef, tutar, son kullanım ve politika sürümüyle belirli bir ağ-varlık rotası.

En ucuz ağ, cüzdan desteği veya gözlemlenebilirlik zayıfsa iyi seçim olmayabilir. Checkout tam ağ adını göstermeli, sadece token sembolüne güvenmemelidir.

Varlık, ağ, adres ve tutara göre çok zincirli işlem eşleştirmesi — Tutar ve zaman kontrolünden önce ağ ile varlık kimliği doğrulanmalıdır.

İstisnaları sessiz tahminlere değil açık durumlara dönüştürün

Müşteri yanlış ağdan transfer yapabilir, benzer adlı yanlış token gönderebilir, Memo'yu atlayabilir, süresi dolan rotayı kullanabilir veya takip edilmeyen ağa ödeme gönderebilir. Bunların otomatik başarı sayılmaması gerekir.

İstisna	Güvenli yanıt	Yapılmaması gereken
Yanlış ağ	Transferi işaretle, kanıtı koru, kurtarma sürecine yönlendir.	Doğru rota gibi otomatik kabul etme.
Yanlış token sözleşmesi	Sembol tanıdık olsa da varlık eşleşmesini reddet.	Yalnız sembol ve ondalık sayısına güvenme.
Süresi dolmuş rota	Kayıtlı son kullanım ve geç ödeme politikasını uygula.	Güncel kurla sessizce yeniden fiyatlama yapma.
Yinelenen gözlem	Ağ, işlem kimliği ve olay sürümüne göre tekilleştir.	Teslimatı tekrar başlatma.
Adaptör belirsizliği	Ödemeyi inceleme veya kanıt bekleme durumunda tut.	Belirsizliği başarılı duruma çevirme.

Kurtarma olasılığı saklama modeli, adres kontrolü, token desteği ve ağın teknik özelliklerine bağlıdır. İade garanti olmasa bile olay doğru sınıflandırılmalı ve kanıtları korunmalıdır.

Canlı aboneliklere ek olarak backfill, doğrulama ve tekrara dayanıklılık gerekir

RPC bağlantıları kesilir, servis sağlayıcılar gecikir, abonelik olayları kaçırır ve sistemler yeniden başlar. Her adaptör kalıcı bir cursor veya checkpoint ile zincirin kanonik verisinden kaçırılmış işlemleri getiren backfill sürecine sahip olmalıdır.

Sağlayıcı yanıtı kesin gerçek değil, bir gözlemdir. Önemli durum geçişleri başka bir kaynaktan doğrulanabilir; sağlık kontrolü sağlayıcı hatasıyla blokzincir arızasını ayırmalıdır.

Güvenle işlenen son blok, slot, sequence veya logical-time noktasını saklayın.
Yeniden başlatma sonrasında sınırlı örtüşen pencereyi yeniden tarayın.
Durum değiştirmeden önce yinelenen olayları ayıklayın.
Her kararla adaptör ve politika sürümünü kaydedin.
Kanıt kalitesi düşerse yeni rota oluşturmayı duraklatın.
Çözülemeyen zincire özgü sorunlar için manuel inceleme sunun.

Güvenilirlik mühendisliği daha geniştir; orkestrasyon katmanı checkpoint, rota sağlığı ve replay kontrollerini dışarı açmalıdır.

Ödeme normalizasyonu hazine işlemlerinin farklılıklarını ortadan kaldırmaz

İki ödeme aynı iş durumuna ulaşsa da farklı ağ bakiyesi, varlık, çekim koşulu ve ücret oluşturabilir. Orkestratör tüm sonuçları tek bir görünen sayıya indirgememelidir.

Hazineye aktarımda alınan varlık ve ağ, brüt tutar, ücret bileşenleri, varsa dönüştürülen varlık, hedef bakiye ve işlem referansları bulunmalıdır. Böylece finans sistemleri her zinciri yeniden sorgulamadan mutabakat yapabilir.

Likidite, swap, çekim ve zincirler arası transfer hazine ve mutabakat servislerinin görevidir. Adaptör içine gizlenmek yerine açık servis arayüzleri üzerinden çağrılmalıdır.

Satıcıya ağ ayrıntılarıyla birlikte kararlı ödeme sözleşmesi sunun

Hedef tüm ağ farklarını saklamak değildir; satıcı müşteri desteği, gecikme açıklaması, istisna incelemesi ve finansal mutabakat için bilgiye ihtiyaç duyar. Bu bilgilerin sunumu ortak ve anlaşılır olmalıdır.

Kararlı alanlar: ödeme ve sipariş ID, beklenen ve alınan tutar, durum, son kullanım ve mutabakat sonucu.
Ağa özgü alanlar: ağ, varlık, adres, işlem ID, yerel kanıt, hata nedeni.
Eylemler: bekle, teslim et, incele, iade et, müşteriyle görüş veya mutabakat yap.

Checkout tam ağ-varlık eşleşmesini göstermeli, doğru adres ve Memo kullanmalı, desteklenmeyen seçenekleri sunmamalıdır.

OxaPay kapasite keşfini ödeme oluşturma ve izleme arayüzlerinden ayırır

OxaPay'deki Supported Currencies ve Supported Networks mevcut varlık ve ağları, Accepted Currencies ise satıcıya açık seçenekleri bildirir. Checkout sabit bir liste kodlamak yerine güncel verileri kullanmalıdır.

Hosted Invoice müşterinin kullanılabilir bir rota seçmesine izin verebilir. White-Label ise para birimi ile ağı belirleyip adres, tutar, Memo, QR kod ve son kullanım bilgisini döndürebilir. Generate White Label, rota seçimi ve checkout'u kendi yöneten işletmeler için önemlidir.

Payment Information ödeme durumunu ve ağ, işlem hash'i gibi verileri sunar; webhook değişiklikleri satıcıya iletir.

Pratik sonuç: kapasite keşfi, rota oluşturma, ödeme gözlemi ve satıcıya bildirim ayrı sorumluluklardır. Bu ayrım çok zincirli ödemeyi kontrol edilebilir kılar.

Bu bölümün kaynakları: OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay Docs · OxaPay Docs

Kimlik, kanıt ve hata yönetimi için tasarım kontrolü

Her rota ağ ve varlık kimliğini açıkça içeriyor mu?
Kapasiteler kontrollü kayıttan mı okunuyor?
Para gönderilmeden önce rota ödemeye bağlanıyor mu?
Adaptörler kesintiden sonra eksik olayları tamamlıyor mu?
Ortak olay yerel kanıtı koruyor mu?
Politika kararları sürümlü ve denetlenebilir mi?
Yanlış ağ ve yanlış token ayırt ediliyor mu?
Tekrar işleme ikinci teslimatı önlüyor mu?
Tüm ödemeleri durdurmadan yeni rota oluşturma kapatılabiliyor mu?
Hazineye varlık, ağ, ücret ve dönüşüm bilgileri geçiyor mu?
Destek ekibi bekleme veya inceleme nedenini açıklayabiliyor mu?
Yeni zincir satıcı servislerini yeniden yazmadan eklenebiliyor mu?

Birçok ağ logosu göstermek tek başına yeterli değildir. Bu kontroller yoksa arayüz çok ağlıdır ama ödeme sistemi gerçek anlamda orkestre edilmez.

Farklı yerel yürütme yollarında tek ödeme kimliği koruyun

İşletme bir ödeme yükümlülüğü oluşturur; müşteri uygun bir ağ-varlık rotası seçer; blokzincir kendi kurallarını uygular; adaptör yerel kanıtları toplar ve orkestratör bunları ortak iş sonucuna yorumlar.

Son model: bir ticari ödeme → sabitlenmiş varlık-ağ rotası → yerel blokzincir işlemi → standart kanıt akışı → denetlenebilir tek satıcı sonucu.

Ağ çeşitliliği tek bir ödeme hakkında çelişen gerçekler üretmemelidir. Çeşitlilik ağ sınırında, tutarlılık operasyonel çekirdekte kalmalıdır.

Birincil teknik kaynaklar

Analiz CAIP-2 standardı, Bitcoin işlem ve ödeme rehberleri, Ethereum JSON-RPC ve EIP-695, Solana RPC, TON shard yapısı, TRON işlemleri ve OxaPay'in Supported Currencies ile Supported Networks belgelerine dayanır. Doğrudan kaynak bağlantıları aşağıdadır.