Kripto ödeme entegrasyonunu test etmek, yalnızca ödeme sayfasının açıldığını değil, doğru siparişin ancak ödeme doğrulandıktan sonra ve tek seferde yerine getirildiğini kanıtlamaktır. Mesaj teslim testlerini, uygulamanızın sipariş durumu testlerini ve izin verilmiş gerçek paralı kabul kontrolünü birbirinden ayırın. Her biri farklı bir soruyu yanıtlar.
Bu kontrol listesi, seçilen varlık ve ağın gerçekten kullanılabildiği USDC veya USDT ödemeleri de dahil olmak üzere, ödeme akışını yayına hazırlayan geliştiriciler ve satıcılar içindir. Önerilen bir test yöntemidir; Yolfi'nin uygulamanız için bu testleri geçtiğini veya test ağında eksiksiz bir ödeme akışı sunduğunu bildiren bir rapor değildir.
Hangi tür testi yaptığınızı bilin
Benzetim yoluyla oluşturulan ödeme bildirimi, blokzincir transferi değildir. Test ağındaki transfer, üretim ağındaki ödeme değildir. Başarılı bir tarayıcı yönlendirmesi ise bunların hiçbiri değildir.
| Test katmanı | Neyi ortaya koyabilir | Neyi ortaya koymaz |
|---|---|---|
| Kontrollü test verileriyle uygulama testleri | Sipariş geçişleri, ret kuralları ve yinelenen olayların işlenmesi | Sağlayıcının yayındaki alıcınıza ulaşabildiğini |
| Sağlayıcının test webhook olayı | Uç noktanın erişilebilirliği ve sağlayıcının test yükünün işlenmesi | Para aktarıldığını veya gerçek bir faturanın ödendiğini |
| Açıkça desteklendiği durumlarda test ağı transferi | İlgili test ağındaki davranış | Üretimde varlığın kullanılabilirliğini veya ana ağdaki mutabakatı |
| İzinli canlı kabul kontrolü | Gerçek bir üretim ödemesinde gözlemlenen sonuç | Her ağın, tokenın ve hata durumunun çalıştığını |
Ethereum'un ağ rehberi, hesap bakiyelerinin ve işlem geçmişinin bağımsız ağlar arasında taşınmadığını açıklar. Adresin aynı görünmesi, test ağı bakiyesini ana ağda harcanabilir kılmaz. Genel bir cüzdan testinin ödeme hizmeti için de geçerli olduğunu varsaymak yerine sağlayıcının güncel belgelerini inceleyin.
Önce testin sınırlarını yazılı olarak belirleyin
Herhangi bir şey göndermeden önce uygulama ortamını, sağlayıcı hesabını, alıcı URL'sini, imzalama sırrının konumunu, sipariş kimliklerini ve amaçlanan yan etkileri kaydedin. Benzetim senaryolarında geçici müşteri kayıtları kullanın; gerçek teslimatı, ücretli erişimi ve müşteri e-postalarını devre dışı bırakın.
Test ve üretim yapılandırmalarını ayrı tutun. İmzalama sırrını asla bir makaleye, ekran görüntüsüne, sorun kaydına veya sohbet dökümüne kopyalamayın. Test kanıtlarınız kullanılan sırrın sürümünü belirtmeli, değerini açığa çıkarmamalıdır. Başarısız bir testi araştırmak için alıcıdan cüzdan kurtarma ifadelerini veya özel anahtarlarını istemeyin.
Gerçek paralı bir kontrol için tutar, ücretler, hedef ve sorumlu kişi konusunda açık kurum içi onay alın. İşletmenin kontrolündeki bir cüzdanı ve kaybetmeyi göze alabileceğiniz bir tutarı kullanın. Eski bir ekran görüntüsünde, otomatik oluşturulmuş bir coin sayfasında veya resmî olmayan bir test talimatında göründüğü için bir adrese ya da ağa para göndermeyin.
Sipariş tutarını sunucunun belirlediğini kanıtlayın
Yolfi API Checkout akışında satıcının sunucusu, nihai tutar ve para birimiyle bir Checkout Session oluşturur. Alıcı daha sonra desteklenen bir ağ ve token seçer; bu oturumdan bir Invoice oluşturulur. Yeniden kullanılabilir Paylink, fiyatı sunucuda hesaplanan dinamik bir siparişten farklı bir amaca hizmet eder.
Dinamik bir sepet için para hareketini sınamadan önce kendi sunucunuzun fiyat hesabını ve oturum ilişkilendirmesini test edin:
- Tarayıcının gönderdiği toplam tutarı değiştirin ve bunun esas alınan sipariş fiyatını değiştiremediğini doğrulayın.
- Başka bir müşterinin sipariş referansını kullanmayı deneyin ve uygulamanın yetkisiz erişimi reddettiğini doğrulayın.
- Ödeme akışını yenileyin veya yeniden açın; tekrarlanan girişimlerin amaçlanan siparişle ilişkili kaldığını kontrol edin.
- Oturum oluşturulduktan sonra sepeti değiştirin; uygulamanın eski ödeme girişimini değiştirmek veya reddetmek için açık bir kuralı olduğunu doğrulayın.
Bunlar uygulamanın kabul ölçütleridir; sağlayıcı uç noktasının olası her isteği reddettiğine dair iddialar değildir. Sunucunun sipariş referansı ile döndürülen oturum referansını birlikte saklayın. Bir API alanı uydurmayın veya tarayıcının kontrolündeki bir tanımlayıcının sahipliği kanıtladığını varsaymayın.
Gerçek satış oluşturmadan test webhook olayı gönderin
Güncel Yolfi webhook belgeleri, yönetim panelinden gönderilen ve canlı olaylarla aynı teslim yolunu, adaptörü ve imza başlığını kullanan bir test olayını açıklar. Yükü livemode: false içerir ve olay kimliği evt_test_ öneki taşır. Test; fatura, ödeme olayı, abonelik veya müşteri kaydı oluşturmaz.
Bu olayı para aktarımını değil, teslimi ve yükün işlenmesini kontrol etmek için kullanın. 200 OK döndüren bir alıcı yine de yanlışlıkla erişim veriyor veya mesajı sessizce atıyor olabilir. Teslim sonucunun yanı sıra ortaya çıkan uygulama durumunu da inceleyin.
İmzaları, kuruluşun API anahtarıyla değil, belgelenen yöntem ve uç noktaya özgü imzalama sırrıyla doğrulayın. Canlı sipariş karşılama akışınızın bir test olayını ödenmiş sipariş sayamadığını doğrulayın. Yalıtılmış test ortamında test verileriyle sipariş karşılamayı deniyorsanız geçici kayıtlar kullanın ve bunları üretim kayıtlarından ayrı inceleyin.
Yolfi, herkese açık bir HTTP veya HTTPS hedefi gerektirir ve yönlendirmeleri takip etmez. Belgeleri yerel geliştirme için herkese açık bir HTTPS tüneli önerir. Alıcının tam ve nihai URL'sini kontrol edin; başka bir yola veya yalnızca yerelden erişilen adrese yapılan başarılı istek, sağlayıcının teslimini kanıtlamaz.
Yalnızca sorunsuz akışın ekran görüntüsüne değil, hata matrisine başvurun
Sağlayıcının test göndericisinde bulunmayan durumlar için kendi yalıtılmış test ortamınızda kontrollü test verileri kullanın. Bunları açıkça uygulama testi olarak etiketleyin; uydurulmuş sağlayıcı olaylarını gerçek ödeme kanıtı olarak sunmayın.
| Senaryo | Uygulamanızda gözlemlenmesi gereken sonuç |
|---|---|
| Geçerli test olayı | Test olarak kaydedilir; gerçek teslimat veya ödeme makbuzu oluşmaz |
| Eksik veya geçersiz imza | Sipariş değişmeden reddedilir |
| Başlatılmış ancak doğrulanmamış ödeme | Sipariş ödenmemiş olarak kalır |
| Bilinmeyen siparişe ait doğrulanmış ödeme | Araştırma için bekletilir; tahminle müşteri eşleştirilmez |
| Aynı imzalı olayın iki kez teslimi | Tek kalıcı iş sonucu; yinelenen teslimat yok |
| Aynı olayı iki işleyicinin işlemesi | Eşzamanlı işlemeye rağmen tek sipariş karşılama kararı |
| Alıcının erişilemez olup sonra düzelmesi | Sipariş ikinci kez karşılanmadan toparlanmanın gözlemlenmesi |
| Tarayıcının dönüşten önce kapanması | Ödeme işlemenin dönüş sayfasına bağlı olmaması |
Yolfi'de invoice.created başlangıcı bildirir; payment.confirmed, belgelerde belirtilen sipariş karşılama tetikleyicisidir. Sırf ilk mesaj geldi diye siparişi ödenmiş duruma geçirmeyin. İdempotent webhook rehberi, yinelenen olayların kalıcı biçimde ayıklanmasını ele alır; bu kontrol listesi ise uygulamanızın gerçekten böyle davrandığına dair kanıt toplamaya odaklanır.
Toparlanmayı bilinçli olarak test edin. Bir olayı saklamadan önce başarı yanıtı veren süreç, çökerse işi kaybedebilir. Tamamlanmayı kaydetmeden önce ürün teslim eden süreç, yeniden denemeden sonra teslimatı tekrarlayabilir. Kalıcı kayda dayalı bir işleme tasarımı seçin, ardından tek başarılı isteğin güvenilirliği kanıtladığını varsaymak yerine kesinti noktalarını sınayın.
Alıcı talimatlarını ve çözümlenmemiş ödeme akışını kontrol edin
Gerçek ödeme akışını telefonda ve bilgisayarda açın. Gösterilen tutarın, seçili varlığın, ağın, hedefin ve son geçerlilik bilgilerinin transferden önce anlaşılır olduğunu kontrol edin. QR kodunun her gönderici cüzdanını otomatik olarak doğru yapılandırdığını varsaymadan kopyalama düğmelerini ve QR taramayı test edin.
Sırf bir hata mesajını sınamak için desteklenmeyen token göndermeyin, bilerek yanlış ağ kullanmayın veya geri döndürülemez transfer yapmayın. Bunun yerine bu destek durumlarını kontrollü kayıtlarla prova edin. Yanlış ağa ödeme yapılmasını önleme rehberi, alıcı tarafında hangi kontrollerin bulunması gerektiğini açıklar.
Ödenmemiş veya süresi dolmuş bir siparişi prova edin: Alıcıya dayanaksız bir kurtarma sözü değil, açık bir durum ve güvenli bir sonraki adım sunulmalıdır. Yeniden ödeme istemeden önce nelerin araştırılacağını belirlemek için süresi dolmuş fatura prosedürünü kullanın. İlk girişimin belirsizliğine verilen otomatik yanıt ikinci bir ödeme olmamalıdır.
İzin verilmişse bir canlı kabul kontrolünü belgeleyin
Yalnızca seçilen üretim varlığının ve ağının gerçek akışta kullanılabildiğini doğruladıktan sonra ilerleyin. Gerekli ağ ücretlerini hesaba katın ve hedefi işletmenin kontrolünde tutun. Sağlayıcının test webhook olayı, doğrulanmamış bir yoldan gerçek para göndermeyi haklı çıkarmaz.
Sipariş ve ödeme referanslarını, kullanılan gerçek varlığı ve ağı, tutarı, gözlemlenen doğrulamayı, alıcı cüzdanındaki kanıtları ve siparişin karşılanma durumunu kaydedin. Her durum için geçerli bir onay sayısı veya aktarım süresi vadetmeyin. Yalnızca cüzdan ekran görüntüsünü değil, gerçekten gözlemlediğiniz sonucu kontrol edin.
Ardından bu ödemeyi sipariş ve makbuz kayıtlarıyla mutabık hale getirin. Ödeme mutabakatı kontrol listesi, gelen parayı siparişlere ayrılan tutarlardan ve ücretlerden ayırmaya yardımcı olur. Kabul ödemesini iade etmeyi planlıyorsanız iadeyi ayrıca onaylatın ve doğrulayın; bunun otomatik bir ters işlem olduğunu varsaymayın.
Başarılı bir kontrol, belli bir anda gözlemlenmiş tek bir yolu doğrular. Ödeme mantığı, alıcının dağıtımı, sırlar veya desteklenen yollar değiştiğinde ilgili kabul testlerini tekrarlayın. Tek bir USDC ödemesini asla tüm USDT ağlarının çalıştığının kanıtı olarak genellemeyin.
Sürüm için test kanıtı kaydı tutun
Test edilen uygulama sürümünü, ortamı, senaryoları, beklenen sonuçları, gerçek sonuçları ve çözülmemiş sorunları içeren kısa bir rapor saklayın. Müşteri tanımlayıcılarını veya cüzdanların tüm geçmişini yayımlamak yerine özel günlüklere ve sipariş kayıtlarına bağlantı verin.
Bir test olayı canlı siparişi karşılayabiliyorsa, yinelenen olay iki kez teslimata yol açabiliyorsa, geçersiz imzalar durumu değiştirebiliyorsa veya doğrulanmış ödemeler güvenli biçimde eşleştirilemiyorsa yayına geçişi durdurun. Çözülmemiş her maddeye bir sorumlu atayın. Yeşil teslim rozeti, bu iş sonuçlarının yerine geçmez.
Sık sorulan sorular
Yolfi test webhook olayı kripto para aktarır mı?
Hayır. Belgelenen test, fatura veya ödeme kaydı oluşturmadan teslimi ve yükün işlenmesini doğrular. Gerçek bir blokzincir ödemesinin başarılı olduğunu kanıtlamaz.
Test ağı ödemesi ile ödeme hizmetinin deneme ortamı aynı mıdır?
Hayır. Test ağı ayrı bir blokzincir ağıdır. Sağlayıcının deneme ortamı ise hizmete özgüdür. Sağlayıcının ihtiyaç duyduğunuz belirli modu destekleyip desteklemediğini doğrulayın; bu makale Yolfi'de test ağı ödeme akışının bulunduğunu ortaya koymaz.
Ödeme sayfası başarıyla yönlendirdikten sonra yayına geçebilir miyim?
Tek başına bu kanıtla değil. Sunucu tarafında ödeme işlemeyi, sipariş eşleştirmeyi, yinelenen olaylara karşı korumayı ve hata sonrası toparlanmayı doğrulayın. Alıcı, herhangi bir dönüş sayfası açılmadan tarayıcıyı kapatabilir.
Her hatayı gerçek para göndererek test etmek zorunda mıyım?
Hayır. Hataların işlenmesi için yalıtılmış uygulama testlerini ve sağlayıcının belgelenmiş benzetimlerini kullanın. Her canlı kabul kontrolü, yanlış ağlara kasıtlı transferler değil, izin ve doğrulanmış, desteklenen bir yol gerektirir.
Sonuç: yayına geçmeden önce iş sonucunu test edin
Açık bir sınırla başlayın, sunucu tarafında sipariş işlemeyi kanıtlayın ve benzetim olayını doğrulanmış paradan ayırın. Uygun sabit fiyatlı teklifler için Yolfi ödeme linklerini, dinamik siparişler için belgelenen API akışını kullanın; ardından sipariş karşılamayı tarayıcı yönlendirmesinin değil, ödeme işlemenin yönettiğine dair kanıt saklayın.
