3-D Secure Ödemeleri Neden Kesintili Olarak Başarısız Olur ve İmzayı Nasıl Düzeltirsiniz?

Kısa cevap: 3-D Secure sistemlerindeki kesintili “invalid signature” reddetmeleri neredeyse hiçbir zaman bir 3-D Secure sorunu değildir. Bu tamamen bir determinism sorunudur. İki farklı sistem aynı ödeme verisini imzalamadan önce iki farklı şekilde serialize ederse, ürettikleri imzalar birbirinden farklı olur. Bu durumda gateway isteği reddeder ve hata tamamen rastgele görünür.

Hata Modu

3-D Secure standartları, bir request üzerindeki imzanın gateway tarafında yeniden hesaplanan değerle birebir eşleşmesini şart koşar. İmza, request verisinin bir hash sonucudur. Bu nedenle oldukça hassastır. İmzalanan payload üzerindeki tek bir byte bile değişse hash tamamen değişir. Kriptografik imzanın temel amacı budur fakat aynı zamanda en büyük tuzağıdır.

Veri genellikle doğrudur. Farklı olan şey serialization işlemidir. Field sıralaması, bir değerin casing durumu, encoding tercihi veya fazladan bir whitespace karakteri. Bunların her biri farklı bir byte string üretir, farklı bir hash oluşturur ve ödemenin reddedilmesine yol açar.

Neden Kesintili Görünür?

Tek bir terminal entegrasyonunda bu durumu hemen fark edebilirsiniz. Ancak sorun birden fazla cihazın bulunduğu filolarda gizlenir. Çok şubeli bir POS altyapısında terminaller farklı zamanlarda farklı firmware ve konfigürasyon sürümleriyle kurulur. Bu yüzden iki terminal birebir aynı sipariş verisine sahip olsa bile imzalanacak request body yapısını farklı şekilde oluşturabilir.

Bir terminal alanları amount, currency, ref sırasıyla imzalarken, bir diğeri ref, amount, currency sırasını kullanabilir. Her iki yapı da log dosyalarında düzgün görünür. Ancak biri başarılı olurken diğeri hata alır. Cihazlar güncellendikçe hangi terminalin başarılı olduğu zamanla değişir.

Bu durum veriye ve konfigürasyona bağlı olduğu için sistemde rastgele reddetmeler olarak görünür. Arka planda ise gün sonu mutabakatını sessizce bozar.

Çözüm: İmzalamadan Önce Canonicalize Edin

Client tarafından gönderilen verilere körü körüne güvenmeyi bırakın. İmzalanacak string yapısını kendiniz deterministik bir şekilde oluşturun:

• Sabit field sırası. Tek bir canonical sıralama belirleyin ve verileri her zaman bu sıraya göre dizin.
• Normalize edilmiş casing ve encoding. Casing ve karakter encoding standartlarına karar verin ve bunları eksiksiz uygulayın.
• Doğru anahtarla güçlü bir hash. Canonical string yapısını üye iş yeri bankasının (acquirer) paylaştığı gizli anahtarla HMAC-SHA512 kullanarak imzalayın.
• Idempotent imzalama. Yeniden denenen bir request her zaman aynı imzayı üretmelidir. Asla ikinci ve farklı bir imza oluşturmamalıdır.

Canonicalization uygulandığında terminal bazlı farklılıklar önemsiz hale gelir. Birebir aynı veri her yerde aynı imzayı verir.

Mutabakattan Önce Yakalayın

Göremediğiniz bir imza hatasını düzeltemezsiniz. Reason code değeri imza uyuşmazlığı gösteren mutabakat farkları için otomatik alarm tanımlayın. Böylece uyumsuzluklar haftalar sonra bir mutabakat açığı olarak karşınıza çıkmak yerine dakikalar içinde tespit edilir.

Çözümü terminallere kesinti yaşatmadan adım adım dağıtın. Her cihaz yeni sisteme geçtikçe mutabakatın yeniden dengeye oturduğunu izleyin.

Özet ve Önemli Noktalar

• İmzalanan payload yapısını client tarafından serialize edilen rastgele bir veri olarak değil, sizin oluşturduğunuz canonical bir yapı olarak ele alın.
• Determinism en kritik özelliktir. Aynı girdi, aynı imza, her terminalde, her zaman.
• Para transferi içeren işlemleri idempotent yapın, böylece retry senaryoları güvenli hale gelir.
• Mutabakat farkları için alarm kurun, gün sonu mutabakatının tek izleme aracınız olmasına izin vermeyin.