Ödeme Altyapısı Entegrasyonu: Geliştiricilerin Doğru Yapması Gerekenler
Ödeme entegrasyonu bir eğitimde basit görünür ve canlıda affetmez, çünkü her arıza durumu ya ödeyip hiçbir şey alamayan bir müşteri ya da bir şey alıp ödemeyen bir müşteri demektir.
Bu rehber akışın nasıl işlediğini, sorunların çoğunu önleyen tasarım kararını ve yayından önce bilerek test edilmesi gereken durumları ele alıyor.
Akış gerçekte nasıl işler#
Sağlayıcı ne olursa olsun şekil aynıdır: sunucunuz bir tahsilat niyeti oluşturur, müşteri ödeme sağlayıcısında kimlik doğrular ve sağlayıcı size sonucu söyler — iki kez, iki farklı yoldan.
- Sunucunuz tutar, para birimi ve siparişinize bir referansla bir ödeme niyeti oluşturur.
- Müşteri kart bilgilerini barındırılan bir alana ya da sayfaya girer, böylece veri sunucunuza hiç dokunmaz.
- Güçlü kimlik doğrulama gerekebilir; bu, müşterinin tamamlaması gereken bir adım ekler.
- Sağlayıcı müşteriyi bir sonuçla sitenize geri yönlendirir.
- Ayrıca sunucudan sunucuya, yetkili sonucu içeren bir webhook gönderir.
- Sisteminiz siparişi günceller — yönlendirmeden değil webhook’tan.
- Sevkiyat yalnız ödeme doğrulandıktan sonra tetiklenir.
Bütün tasarım 4. ve 5. adımdır. Yönlendirme ne olduğuna dair bir ipucu, webhook ise olgudur.
Webhook neden tek doğruluk kaynağı olmalı#
Müşterinin tarayıcısı güvenilmez bir anlatıcıdır. Yönlendirme sırasında kapanabilir, bağlantısı kopabilir ya da manipüle edilebilir. Sipariş durumunuz müşterinin başarı sayfanıza dönmesine bağlıysa, hiç kaydedilmemiş ödenmiş siparişleriniz olacaktır.
- Sipariş durumunu yalnız doğrulanmış webhook’lardan güncelleyin; yönlendirmeyi yalnız kullanıcıya gösterilen bir mesaj sayın.
- Webhook imzalarını doğrulayın. Siparişleri ödenmiş işaretleyen kimliksiz bir uç nokta tam olarak kulağa geldiği kadar kötüdür.
- Webhook işlemeyi idempotent yapın — sağlayıcılar yeniden dener ve kopyalar gelecektir.
- Hızlı yanıt verip işlemi asenkron yapın; yavaş uç noktalar yeniden denenir ve sonunda devre dışı bırakılır.
- Her webhook yükünü kaydedin. Ödeme itirazları kayıtlarla çözülür.
- Olayları sırasız gelebilecek şekilde ele alın, çünkü öyle gelebilir ve gelecektir.
Test edilmeye değer arıza durumları#
Bunların her biri canlıda oluyor. Yayından önce sağlayıcının test kartlarıyla bilerek test edin.
| Durum | Ne olmalı |
|---|---|
| Müşteri ödedikten sonra sekmeyi kapatıyor | Webhook siparişi yine tamamlıyor; onay e-postası gidiyor |
| Kart reddedildi | Net mesaj, sepet korunuyor, tekrar denenebiliyor |
| Güçlü kimlik doğrulama başarısız | Sipariş onaylanmıyor; müşteriye ne yapacağı söyleniyor |
| Kopya webhook | Sipariş bir kez güncelleniyor, iki kez değil; ikinci sevkiyat yok |
| Webhook yönlendirmeden önce geliyor | Başarı sayfası zaten tamamlanmış siparişi yansıtıyor |
| Kısmi iade | Sipariş toplamları ve muhasebe aktarımı tutarlı kalıyor |
| Ödeme ile sevkiyat arasında stok bitti | Tanımlı süreç: iade, ön sipariş ya da muadil |
| Para birimi yuvarlama | Tahsil edilen tutar gösterilen toplamla birebir aynı |
Kapsam, uyum ve para#
Birkaç karar, ne kadar mevzuat yükü üstleneceğinizi ve işlemin ne kadarını elde tutacağınızı belirler.
- Kart numaralarını asla saklamayın. Barındırılan alanlar ya da barındırılan bir sayfa kullanın ki kart verisi sunucunuza hiç ulaşmasın; PCI kapsamı böylece asgaride kalır.
- Ücret yapısını anlayın. Yüzde artı sabit ücret, artı para birimi çevrimi, artı ters ibraz ücreti. Manşet yüzdesi maliyet değildir.
- Ödeme zamanlamasını kontrol edin. Hesabınıza geçiş süresi, küçük bir oran farkından çok nakit akışını etkiler.
- İade yolunun kısmi iadeler dahil uçtan uca çalıştığını yayından önce doğrulayın.
- Pazarınızın gerçekten kullandığı yerel yöntemleri destekleyin — kart her yerde varsayılan değildir ve baskın yerel yöntemi atlamak dönüşüm kaybettirir.
- Ödeme kritikse ikinci bir sağlayıcı hazır tutun. Kesintiler oluyor ve geliri tamamen durduruyorlar.
Sık sorulan sorular
Barındırılan ödeme sayfası mı gömülü form mu?
Barındırılan ödeme daha basittir, PCI kapsamını en küçük tutar ve bakımını sağlayıcı yapar — çoğu mağaza için doğru varsayılan budur. Gömülü alanlar müşteriyi sizin alan adınızda tutar ve deneyim üzerinde daha çok kontrol verir; bedeli daha fazla kod ve daha fazla sorumluluktur. İkisi de kart verisini sunucunuzdan uzak tutar ki asıl önemli olan odur.
Webhook uç noktam çökerse ne olur?
Sağlayıcılar geri çekilmeli olarak yeniden dener, genelde saatler ya da günler boyunca, dolayısıyla kısa bir kesinti kendiliğinden toparlanır. Uzun bir kesinti, siparişlerin onaysız beklemesi demektir, o yüzden uç noktayı izleyin ve arızalarda uyarı alın. Ayrıca sağlayıcı işlemlerini siparişlerinizle günlük karşılaştıran bir mutabakat işi kurun — yeniden denemelerin kaçırdığı her şeyi o yakalar.
Güçlü müşteri kimlik doğrulamasını ele almam gerekir mi?
Bunu gerektiren bölgelerdeki müşterilere satıyorsanız evet ve modern sağlayıcı SDK’ları akışın çoğunu üstlenir. Sizin üstlenmeniz gereken şey sonuçtur: kimlik doğrulaması bekleyen bir sipariş ödenmiş değildir ve onu ödenmiş saymak, karşılığını hiç almadığınız malı göndermek demektir.
Ödemeleri güvenli biçimde nasıl test ederim?
Her sağlayıcının belirli sonuçları tetikleyen kartları olan bir test modu vardır — ret, kimlik doğrulama gerekli, dolandırıcılık. Yukarıdaki tablodaki zor durumlar dahil listenin tamamını çalıştırın. Sonra yayından önce canlıda küçük bir gerçek işlem yapıp iade edin, çünkü test modu canlı anahtarlarınızı ve canlı webhook adresinizi denemez.
ödeme altyapısı entegrasyonue-ticaret ödemewebhookpci uyumluluködeme geliştirmeonline ödeme
