E-Ticaret Ödeme Entegrasyonu Teklifinde Neleri Kontrol Etmelisiniz?

Önce ödeme akışını ve sorumluları belirleyin

Hazır bir mağaza eklentisi mi kullanılacak, sağlayıcının barındırdığı ödeme sayfasına mı gidilecek, yoksa özel bir API bağlantısı mı geliştirilecek? Teklif hangi yöntemin seçildiğini ve nedenini söylemeli. Platformunuz, ürün tipiniz ve mevcut sipariş akışınız bu kararı etkiler.

Sağlayıcı hesabını kimin açacağı, teknik anahtarları kimin yöneteceği, test ve canlı ortam ayarlarını kimin değiştireceği açıkça yazılmalı. Ödeme kuruluşunun sözleşme ve hesap onay süreci ile yazılım geliştirme işi ayrı takvimlerdir; ikisini tek bir “kurulum tamam” maddesinde bırakmayın.

• Teklif hangi ödeme yöntemlerini, para birimlerini ve taksit senaryolarını kapsıyor?
• Ödeme ekranı, sipariş sayfası ve sağlayıcı panelinde hangi ekip hangi ayarı yapacak?
• Sağlayıcı veya mağaza altyapısı değişirse bağlantının bakımı kimin sorumluluğunda?

Başarılı ödeme ile başarılı sipariş aynı anda mı kaydediliyor?

Müşterinin teşekkür sayfasını görmesi tek başına tahsilat kanıtı sayılmamalı. Ödeme sağlayıcısının sunucuya gönderdiği sonucu, sipariş numarası ve tutarla eşleştirip sipariş durumunu buna göre güncelleyen akışı isteyin. Örneğin PayTR iFrame entegrasyonunda ödeme sonucu ayrı bir Bildirim URL’sine gönderiliyor; bu adresin kurulumu entegrasyonun açık bir adımı.

Bildirim gecikirse, tekrar gelirse veya doğrulanamazsa ne olacağını da sorun. PayTR dokümanı aynı işlem için birden çok bildirim gelebileceğini ve bildirimin hash değerinin doğrulanması gerektiğini açıklıyor. Bu yüzden bir ödeme iki sipariş, iki fatura veya iki stok düşümü üretmemeli. Kullanılan sağlayıcının kendi bildirim doğrulama yöntemine uyulmalı; iyzico da webhook imzası için ayrı bir yöntem belgeliyor.

Kart verisi ve erişim sınırları nasıl yönetilecek?

Kart bilgilerinin hangi ekranda girildiğini ve mağazanızın bu veriye dokunup dokunmadığını netleştirin. PCI Security Standards Council, ödeme işlemi dışarıya devredilse bile işletmenin hizmet sağlayıcısının uygunluğunu ve paylaşılan sorumlulukları izlemesi gerektiğini belirtiyor. Bu nedenle “sağlayıcı güvenli, başka kontrole gerek yok” ifadesi yeterli bir teknik açıklama değildir.

Teklifte üretim anahtarlarının saklanması, yönetici erişimleri, ödeme sayfasındaki üçüncü taraf kodlar ve hata kayıtlarında hassas veri tutulmaması ele alınmalı. Hangi PCI doğrulama yükümlülüğünün size uygulanacağını ödeme kuruluşunuz veya ilgili kurumla teyit edin; bu kapsam entegrasyon yöntemine göre değişebilir.

İptal, iade ve mutabakat kapsamda mı?

Müşteri siparişi iptal ettiğinde paneldeki sipariş durumu ile ödeme kuruluşundaki işlem durumu birlikte izlenebilmeli. Tam ve kısmi iadenin, ödeme yetkilendirmesinin iptalinin ve başarısız iade denemesinin nasıl ele alınacağını teklif içinde ayrı ayrı sorun. PayTR’nin iade API’si kısmi ve tam iade işlemlerini belgeliyor; kullanılacak sağlayıcıda aynı iş akışının nasıl yürüdüğü ayrıca doğrulanmalı.

Gün sonu kontrolünde mağaza siparişleri, sağlayıcı işlem kayıtları ve muhasebe kayıtları hangi alanlarla eşleştirilecek? Tutar, sipariş kimliği ve işlem durumu arasındaki farklar için bir sorumlu ve düzeltme yolu belirlemek, yalnızca “ödeme alındı” mesajına bakmaktan daha yararlıdır.

Canlıya geçmeden hangi senaryolar test edilmeli?

Test ortamında başarılı ve reddedilen ödeme, müşterinin ödeme ekranından ayrılması, tekrar gelen bildirim, farklı teslimat ücreti, indirimli sepet ve iade senaryolarını çalıştırın. Her testte müşterinin gördüğü mesajı, mağazadaki sipariş durumunu ve sağlayıcıdaki işlem kaydını birlikte kontrol edin. Shopify’ın test siparişi rehberi de farklı ödeme yöntemleri, mobil cihazlar ve başarısız işlemlerle akışı sınamayı öneriyor.

Canlıya geçiş teslimatı yalnızca ekran görüntüsü olmamalı. Test listesi, sonuçlar, açık kalan sorunlar, canlı anahtarlara geçiş ve ilk gerçek işlemi kimin izleyeceği yazılı olmalı. Sağlayıcının test modu ve gerçek işlem koşullarını ayrıca kontrol edin; gerçek test işlemleri ücret doğurabilir.

Teklifleri aynı teslim listesiyle karşılaştırın

İki teklifi ödeme ekranı, sağlayıcı hesabı, bildirim doğrulaması, sipariş eşleştirmesi, iade akışı, test senaryoları ve yayın sonrası destek başlıklarında yan yana koyun. Bir teklif yalnızca eklentiyi etkinleştirmeyi içerirken diğeri hata ve mutabakat akışını da kapsayabilir. Eksik işleri ve sorumluları yazılı olarak isteyin; kararınızı yalnızca kurulum bedeline bağlamayın.