Çoklu Kripto Ödeme Entegrasyonu: Teknik Uygulama Rehberi

Birden fazla kripto para birimini kabul etmek oyunculara esneklik sağlar, ama teknik tarafta her yeni para birimi yeni bir ağ, yeni adres biçimleri, farklı onay süreleri ve farklı hata senaryoları demektir. Bu rehberde çoklu kripto ödeme akışının mimari seçeneklerini, sık karşılaşılan tuzakları ve sağlam bir kayıt ve mutabakat düzeninin nasıl kurulacağını anlatıyoruz. Önemli bir not: LLCBullet operatörlere ödeme altyapısı sağlamaz; kendi paket ödemelerini ff.io üzerinden alır. Aşağıda LLCBullet'in ödeme ekranını yalnızca iyi bir kullanıcı akışı örneği olarak anıyoruz.

Mimari seçenekler

Ödeme sağlayıcısı (gateway)

NOWPayments, CoinGate ve CoinPayments gibi sağlayıcılar adres üretimini, blokzincir takibini ve çoğu zaman dönüşüm işlemlerini üstlenir. Entegrasyon hızlıdır; karşılığında komisyon ödersin ve sağlayıcının hesap koşullarına, desteklediği ağlara ve kesintilerine bağımlı olursun. Sağlayıcı seçerken senin pazarındaki kullanım koşullarını ve hangi faaliyet türlerini kabul ettiğini mutlaka kontrol et.

Kendi altyapın

Kendi düğümlerini ya da blokzincir veri servislerini kullanarak adres üretimini ve takibi kendin yaparsın. Tam kontrol ve daha düşük işlem başı maliyet sağlar; ama anahtar yönetimi, düğüm bakımı ve her ağın kendine özgü davranışları ekibinin sorumluluğuna geçer. Birçok operatör hibrit bir yol seçer: yaygın para birimlerini kendi altyapısıyla, daha az kullanılanları bir sağlayıcıyla yönetir.

Fatura başına benzersiz adres

Her ödeme talebi için ayrı bir adres üretmek, gelen transferi doğru siparişle eşleştirmeyi kolaylaştırır. Bitcoin ve benzeri ağlarda bu genellikle hiyerarşik deterministik (HD) cüzdanlarla yapılır: tek bir ana anahtardan çok sayıda adres türetilir, sunucuda yalnızca genişletilmiş açık anahtar tutulur ve özel anahtar ayrı, korumalı bir ortamda kalır. Hesap tabanlı ağlarda (Ethereum ve Tron gibi) adres başına biriken bakiyeleri toplamanın işlem maliyeti ayrıca hesaplanmalıdır. Cüzdan güvenliği için kripto cüzdan güvenliği rehberimize göz atabilirsin.

Ağ, token ve etiket karmaşası

• Aynı koin, farklı ağ: USDT birden çok ağda bulunur. TRC-20 adresleri T ile, Ethereum tabanlı adresler 0x ile başlar. Oyuncuya hangi ağı kullanması gerektiğini açıkça göster; yanlış ağla gönderilen tutar kaybolabilir.
• Memo ya da tag: Bazı ağlar ortak adreslerde ödemeyi ayırt etmek için ek bir etiket ister. Etiket zorunluysa ekranda ayrıca ve belirgin şekilde göster.
• Adres doğrulama: Adres biçimini ve sağlama toplamını hem istemci hem sunucu tarafında doğrula.

LLCBullet'in ödeme ekranı bu konuda iyi bir örnektir: para birimi listesi sunucuda sabittir, USDT yalnızca TRC20 ağında kabul edilir, zorunlu bir etiket gerekirse ayrıca gösterilir ve ekranda gönderilecek tam tutar yazar. Ayrıntılar için USDT TRC-20 rehberimize bakabilirsin.

Onay sayısı ve süre

Bir transferin ağda görülmesi ile kesinleşmesi aynı şey değildir. Her ağ için gereken onay sayısını risk iştahına göre belirle ve durumu oyuncuya aşama aşama göster: bekleniyor, alındı, onaylanıyor, tamamlandı. Bitcoin'de bloklar ortalama 10 dakikada bir üretilir; Tron gibi ağlarda onay çok daha hızlıdır. Kur dalgalanmasına karşı fiyatı sınırlı bir süre için sabitle ve süre dolduğunda yeni bir ödeme talebi oluştur. Volatilite tarafı için kur riski yazımıza göz atabilirsin.

Eksik, fazla ve geç ödeme

• Eksik ödeme: Çoğunlukla borsa çekim ücretinin tutardan düşülmesiyle olur. Otomatik tamamlama yapma; farkın tamamlanması ya da iade için net bir süreç tanımla.
• Fazla ödeme: Farkı bakiyeye mi ekleyeceğini yoksa iade mi edeceğini önceden belirle.
• Geç ödeme: Süresi dolmuş bir talebe gelen transferi otomatik işlemek yerine incelemeye al ve güncel kurla değerlendir.
• Parçalı transfer: Oyuncu tutarı birkaç parçada gönderirse toplamı nasıl değerlendireceğini kurala bağla.

LLCBullet'te da eksik ödeme otomatik tamamlanmaz; kullanıcıdan sipariş numarasıyla destek ekibine yazması istenir. Süresi dolduktan sonra gelen transferler “İnceleme gerekiyor” durumuna düşer. Bu yaklaşım, otomatik akışın belirsiz durumlarda yanlış karar vermesini önler.

İdempotent kayıt

Blokzincir izleyicileri ve sağlayıcı bildirimleri aynı işlemi birden fazla kez iletebilir. Her transferi ağ, işlem özeti (hash) ve çıktı sırası üçlüsüyle benzersiz kaydetmek, aynı ödemenin iki kez işlenmesini veritabanı seviyesinde engeller:

CREATE TABLE crypto_transfers (
  id            BIGSERIAL PRIMARY KEY,
  invoice_id    BIGINT NOT NULL REFERENCES invoices (id),
  network       TEXT NOT NULL,
  tx_hash       TEXT NOT NULL,
  output_index  INTEGER NOT NULL DEFAULT 0,  -- UTXO çıktısı ya da token olay sırası
  amount        NUMERIC(38, 18) NOT NULL CHECK (amount > 0),
  confirmations INTEGER NOT NULL DEFAULT 0,
  status        TEXT NOT NULL CHECK (status IN ('seen', 'confirming', 'confirmed', 'rejected')),
  seen_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (network, tx_hash, output_index)
);

Çıktı sırası önemlidir: UTXO tabanlı ağlarda tek bir işlem, örneğin bir borsanın toplu çekimi, senin birden çok adresine aynı anda ödeme yapabilir. Hesap tabanlı ağlardaki token transferlerinde bu alan için olay (log) sırasını kullanabilirsin. Sağlayıcıdan gelen webhook'larda da imzayı doğrula ve olay kimliğini tekrar kontrolü için sakla.

Mutabakat ve raporlama

Günün sonunda üç kaynağın aynı şeyi söylemesi gerekir: blokzincir, uygulama veritabanı ve muhasebe kayıtları. Otomatik bir mutabakat işi, her onaylanmış transferin bir siparişe bağlı olduğunu, her tamamlanmış siparişin bir transferle karşılandığını ve cüzdan bakiyelerinin kayıtlarla tuttuğunu kontrol etmeli; tutmayan kalemleri bir inceleme listesine düşürmelidir.

Kontrol listesi

1. Desteklenen para birimlerini ve ağları sunucuda sabit bir listede tut.
2. Her ödeme talebi için benzersiz adres ya da zorunlu etiket kullan.
3. Fiyatı sınırlı bir süre için sabitle ve sürenin dolduğunu açıkça göster.
4. Onay sayısını ağ bazında belirle ve durumu canlı olarak göster.
5. Eksik, fazla ve geç ödemeler için yazılı kurallar tanımla.
6. Transferleri idempotent kaydet ve her gün mutabakat çalıştır.