E-Ticaret

Ön Provizyon Nedir? E-Ticaret ve Rezervasyon Sistemlerinde Kullanımı

Ön Provizyon Nedir? E-Ticaret ve Rezervasyon Sistemlerinde Kullanımı konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

Ön Provizyon Nedir? E-Ticaret ve Rezervasyon Sistemlerinde KullanımıTeknik bilgi • Uygulanabilir yaklaşım
Ön Provizyon Nedir? E-Ticaret ve Rezervasyon Sistemlerinde Kullanımı konusunda güvenli uygulama, doğrulama ve sık yapılan hatalar için UST Bilişim teknik rehberi.

Ön provizyonda kartta tutar ayrılır; kesin tahsilat ayrı bir kapama/capture işlemiyle yapılır. Uygulamanız bu iki durumu aynı “ödendi” etiketi altında saklarsa iptal ve iade karışır. Sağlayıcınızın hesabınız için ön provizyon desteğini ve sürelerini doğrulayın.

1. Örnek akışı yazın

1000,00 TRY rezervasyon için authorize başarılı olsun. Hizmet 800,00 TRY gerçekleştiyse, sağlayıcı kısmi kapamayı destekliyorsa 800,00 capture talep edilir. Kalan blokajın çözülme zamanı banka/sağlayıcıya bağlıdır; müşteriye her banka için sabit gün sözü vermeyin.

DurumSonraki işlem
Yetkilendirme başarısızCapture gönderilmez
Yetkilendirildi, hizmet iptalUygun void/iptal işlemi
Yetkilendirildi, hizmet tamamİzin verilen tutarda capture
Capture başarılı, iade gerekiyorRefund/iade
Sonuç belirsizSağlayıcı sorgusu ile uzlaşma

2. İşlemleri ayrı kayıt olarak saklayın

MySQL test veritabanı için veri modeli örneği:

CREATE TABLE payment_operations (
 id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
 order_id BIGINT UNSIGNED NOT NULL,
 provider VARCHAR(40) NOT NULL,
 idempotency_key VARCHAR(80) NOT NULL UNIQUE,
 provider_operation_id VARCHAR(190) NULL,
 operation_type VARCHAR(20) NOT NULL,
 amount DECIMAL(12,2) NOT NULL,
 currency CHAR(3) NOT NULL,
 status VARCHAR(30) NOT NULL,
 created_at DATETIME NOT NULL,
 UNIQUE KEY provider_operation (provider, provider_operation_id),
 INDEX order_history (order_id, created_at)
) ENGINE=InnoDB;

Her authorize/capture/refund kendi satırını taşır. Sağlayıcı id'si henüz dönmemişken NULL kullanılabilir; sahte id üretmeyin. Bu tablo para çekmez ve API uygulaması değildir. Mevcut ödeme tablonuz varsa önce eşleme/migration planı yapın.

3. Tutar sınırlarını sunucuda uygulayın

Tarayıcıdan gelen capture tutarını güvenilir saymayın. Yetkilendirilmiş tutar, önceki kapamalar ve sağlayıcının kısmi kapama kuralını kontrol edin. Aynı butona iki kez basılması iki işlem üretmemeli. Dağıtık kilit/transaction ve sağlayıcının idempotency desteği birlikte değerlendirilir.

4. Timeout senaryosunu deneyin

Capture isteği sonrası yanıt alınamazsa kaydı “belirsiz” tutup sağlayıcı işlem kimliğiyle sorgulayın. Doğrudan başarısız sayarak tekrar çekim göndermeyin. Müşteriye “işlem doğrulanıyor” durumu gösterin ve operasyon ekibine uzlaşma kuyruğu açın.

Son kontrol

Sandbox raporunda authorization, capture ve refund tutarlarını kendi kayıtlarınızla karşılaştırın. Kesinleşmiş ödeme kayıtlarını eski veritabanı yedeğiyle geri almak finansal işlemi geri almaz. Yanlış işlem varsa sağlayıcının iptal/iade API'si ve muhasebe kaydı üzerinden düzeltin.

UST Bilişim Yaklaşımı

Bilgiyi uygulanabilir projeye dönüştürelim.

İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.

Projenizi Anlatın