Kripto Fatura: Siparişten Onaya Tam Yaşam Döngüsü

Kripto fatura, siparişi izlenen bir blokzincir ödemesine bağlar. Fatura; satıcının sipariş tanımlayıcısını beklenen tutara, son geçerlilik süresine, geçerli varlık-ağ seçeneklerine, ödeme durumuna ve sonuçta oluşan işlem kaydına bağlar. Her Paymos ödeme yüzeyinin arkasındaki işlem kaydı budur.

Tek başına bir cüzdan adresi bu işi yapamaz. Siparişi tanımlamaz, ödemenin ne zaman nihai olduğuna karar vermez ve satıcı sistemine teslimatın ne zaman güvenli olduğunu söylemez. Fatura, eksik olan bu ticari bağlamı sağlar. Daha geniş model için kripto ödemelerin nasıl çalıştığını okuyun.

Kripto faturada hangi bilgiler olmalı?

Üretim faturası üç soruyu yanıtlar. Müşteri ne borçlu, nereden ödeyebilir ve satıcı transferi siparişle nasıl eşleştirecek? Asgari olarak satıcının sipariş tanımlayıcısını, istenen tutarı, fiyatlandırma para birimini, son geçerlilik süresini, seçilen varlık ve ağı, hedef adresi, fatura durumunu ve blokzincir işlem referansını saklayın.

Müşteriye dönük her etikette varlıkla ağı birlikte tutun. Tek başına «USDT» eksiktir çünkü Tron'daki USDT ile Ethereum'daki USDT ayrı zincir üstü varlıklardır. Ödeme talimatları ayrıca QR kodu veya kopyalanabilir adres, kesin token tutarı ve canlı durum göstermelidir. Satıcı kaydı hem kendi sipariş numarasını hem altyapının fatura numarasını tutmalı ki destek ve mutabakat işlemin iki tarafını da izleyebilsin.

Fatura oluşturma yinelemeyi nasıl önlemeli?

Fatura oluşturma, iş siparişi düzeyinde tekrar-güvenli olmalıdır. Bir zaman aşımı satıcıyı ilk isteğin başarılı olup olmadığından emin bırakmaz; sabit tanımlayıcı olmadan tekrar denemek tek sipariş için iki ödenebilir fatura açabilir.

Paymos bu amaçla arayanın verdiği external_order_id değerini kullanır. Aynı harici sipariş tanımlayıcısının yeniden kullanılması yeni fatura açmak yerine mevcut faturayı döndürür. Paymos fatura oluşturmada Idempotency-Key başlığı kullanmaz; entegrasyon ilk API çağrısından önce sipariş numarasını üretip saklamalıdır.

Dönen Paymos fatura numarasını orijinal siparişle saklayın. Yanıt kaybolursa isteği aynı external_order_id ile tekrarlayın ve mevcut faturayla devam edin. Bu, her taşıma hatasından sonra yeni tanımlayıcı üretmekten daha güvenlidir.

Müşteri ödeme ayrıntılarına nasıl ulaşır?

Müşterinin, cüzdan ödemeyi göndermeden önce net tek bir ödeme rotasına ihtiyacı vardır. Paymos bunu Hazır Ödeme Sayfası, gömülü iframe, Ödeme Linki, Low-Code SDK, CMS eklentisi veya REST API destekli özel arayüzle sunabilir. Rota; seçilen varlığı, ağı, tutarı, adresi, QR kodu ve güncel durumu göstermelidir.

Hazır Ödeme Sayfası ödeme arayüzünü üstlenir. Satıcı sipariş ve teslimat mantığının sahibi kalır. CMS eklentisi aynı fatura modelini desteklenen ticaret veya faturalama platformuna bağlar. REST API özel arayüz isteyen ekiplere uyar ama onları doğrulama, hata yönetimi, imzalı istekler, durum sunumu ve mutabakattan sorumlu kılar. Ürün deneyimi gereksinimini karşılayan en az özel yüzeyi seçin.

Tam Paymos fatura yaşam döngüsü nedir?

Entegrasyon yüzeyi değişir ama kontrol döngüsü aynı kalır:

1. Faturayı sabit bir external_order_id ile oluşturun.
2. Ödeme sayfası, link, eklenti, widget veya özel arayüzle uygun varlık-ağ rotasını sunun.
3. Müşterinin cüzdanının ödemeyi göndermesine ve gelen ağ ücretini karşılamasına izin verin.
4. Paymos o ağ ve tutar için onay politikasını uygularken bekleyin.
5. Projenin eksik ödeme toleransını fiilen alınan tutara uygulayın.
6. Teslimatı çalıştırmadan önce imzalı webhook teslimatını doğrulayıp kalıcı kaydedin.
7. Sipariş numarasını, Paymos fatura numarasını, alınan tutarı ve blokzincir işlem referansını mutabık tutun.

Bu sıra; yineleme önleme, kesinlik, eksik ödeme ve teslimat kontrollerinin desteklenen her entegrasyon yüzeyinde nereye ait olduğunu gösterir. Kesin istek biçimi seçilen yüzeye bağlıdır. Özel yol uygulayan ekipler bunu REST API ödeme rehberiyle eşleştirebilir.

Algılanan ödeme ne zaman teslim edilmeye güvenlidir?

Algılama kesinlik değildir. Altyapı, ağ işlemin kanonik tarihte kalacağına dair yeterli güven vermeden önce bir işlemi gözlemleyebilir. Fatura, ancak geçerli onay politikası tamamlandıktan sonra teslimata hazır duruma geçmelidir.

Paymos onay politikasını hem ağa hem ödeme tutarına göre belirler. Küçük ödemeler daha az onay isteyebilir, büyük ödemeler daha güçlü eşik bekleyebilir. Her faturaya uyan tek bir onay süresi yoktur. Ağ koşulları geçen süreyi de değiştirir.

Yalnızca nihai ödendi durumundan teslim edin. Cüzdan ekran görüntüsüne, müşterinin verdiği işlem karmasına veya erken «görüldü» olayına güvenmeyin. Blokzincir onayları rehberi gereken derinliğin neden değiştiğini açıklar.

Eksik ödeme toleransı nasıl çalışır?

Eksik ödeme proje düzeyinde bir yüzdeyi izler. Anlık destek kararına bağlı değildir. Sürgü %0 ile %2 arasında, onda bir adımlarla hareket eder; yeni proje %0,1 ile açılır. Bu kadarı yuvarlama artığını karşılar, indirime dönüşmez. %0 seçilirse eşleşme katıdır: ödeme faturayı tutar ya da aşar. Alınan tutar yapılandırılan tolerans içindeyse fatura tamamlanır ve satıcı ödenen tutarı tahsil eder. Eksik kalan eklenmez.

Tek ödemeli fatura eşiğin altındaysa eksik ödenmiş kalır. Fatura çoklu ödemeye izin veriyorsa müşteri kalanı gönderirken açık kalabilir. Entegrasyon, siparişi sessizce ödendi işaretlemek yerine bu durumu göstermelidir.

Toleransı sipariş ekonomisinden belirleyin. Küçük bir yüzde cüzdan yuvarlamasını elle iş yaratmadan absorbe edebilir ama geniş tolerans, fiyatlandırma hatasını her faturada kabul edilen indirime çevirebilir.

İmzalı fatura webhookları nasıl işlenmeli?

Webhooklar fatura durumunu satıcı sistemine taşır. Paymos bunları X-Webhook-Signature başlığında t={timestamp},v1={hmac_hex} biçimiyle HMAC-SHA256 kullanarak imzalar. Alan servis, olayı güvenilir veri olarak ayrıştırmadan önce zaman damgasını ve imzayı zamanlama-güvenli karşılaştırmayla doğrulamalıdır.

Teslimat tekrarlanabilir, bu yüzden işleyiciler tekrar-güvenli olmalıdır. Bir Paymos teslimat döngüsü — bir ilk deneme ve on tekrar — toplam 11 deneme yapar ve yaklaşık 16 saat sürer. Başarısız veya ulaştırılamayan olaylar elle yeniden oynatılabilir.

Başarıyı ancak olay kalıcı kaydedildikten sonra döndürün. Teslimatı sonra o kayıttan işleyin. Sonraki iş başarısız olursa, alındığı zaten saklanmış olayı webhook göndericisine tekrarlatmak yerine içeride tekrar deneyin.

X-Webhook-Signature: t=1785326400,v1=2b4f...
Content-Type: application/json

Mutabakat ne saklamalı?

Mutabakat tek eksiksiz iz oluşturmalıdır. Ticari siparişi, altyapı kaydını ve blokzincir işlemini bağlayın. Harici sipariş numarasını, Paymos fatura numarasını, istenen ve alınan tutarları, varlığı, ağı, işlem referansını, nihai durumu ve ilgili zaman damgalarını saklayın. Yinelenen işi önleyen satıcı tanımlı anahtarı da tutun.

Mutabakatı müşterinin verdiği işlem karmasından değil, altyapı durumundan yapın. Transfer yanlış varlık, yanlış ağ, yanlış adres veya yetersiz tutar kullanıp blok gezgininde yine makul görünebilir. Fatura durumu transferi ödeme isteğine göre değerlendirir.

Destek kaydı üç tanımlayıcıdan da bulabilmelidir. Sipariş numarası, fatura numarası ve işlem referansı aynı ize ulaşmalıdır. Bu, iade hatalarını azaltır ve müşteri teslimata itiraz ettiğinde satıcıya savunulabilir denetim izi verir.

Hangi kripto fatura yolunu seçmelisiniz?

Ara sıra elle faturalar için ödeme linki kullanın. Satış veya destek üzerinden faturalamaya uyar. Web sitesi her cüzdan etkileşimine sahip olmadan eksiksiz ödeme sayfası istediğinde Hazır Ödeme Sayfasını veya gömülü akışı kullanın. Mağaza Paymos'un desteklediği platformlardan birinde çalışıyorsa resmi CMS eklentisini kullanın.

Gerçekten özel iş akışı için REST API seçin. Paymos Sandbox ve Production kimliklerini ayırır ama aynı API yüzeyini tutar; ekipler gerçek fonları taşımadan fatura sonuçlarını ve webhook işlemeyi test edebilir. Ödeme ve Ödeme Çıkışı (Payout) kimlikleri ayrı kalır.

Her yolda aynı kontrol döngüsünü koruyun. Sabit harici sipariş numarasıyla oluşturun, kesin ödeme ayrıntılarını sunun, nihai ödendi durumunu bekleyin, imzalı webhookları doğrulayın ve teslimattan önce mutabık kalın.