Ö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.
| Durum | Sonraki işlem |
|---|---|
| Yetkilendirme başarısız | Capture gönderilmez |
| Yetkilendirildi, hizmet iptal | Uygun void/iptal işlemi |
| Yetkilendirildi, hizmet tamam | İzin verilen tutarda capture |
| Capture başarılı, iade gerekiyor | Refund/iade |
| Sonuç belirsiz | Sağ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.
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
