Kısmi ve tam refandlar

TL; DR

Refand, yakalanan miktarın ters işlemidir. Tam tüm işlemi kapatır, kısmi bir parça döndürür (tamına kadar kısmi bir seri olabilir). Kritik: kaynağa geri ödeme, sıkı idempotence, neden günlüğü ve webhooks/retras ile orkestrasyon. Geri Ödeme Oranını, TtR p95, Geri Ödeme Hatasını ölçün ve otomatik mutabakatlar yoluyla kopyaları/tutarsızlıkları ortadan kaldırın.

1) Şartlar ve temel farklılıklar

Tam Geri Ödeme - Taahhüt edilen tutarın tamamını iade eder ('geri ödeme _ miktar = capture_amount').
Kısmi Geri Ödeme - bir parça döndürür ('0 <refund_amount <capture_amount'), geri kalanı toplam' capture _ amount 'kısmi sağlar.
Kaynağa Geri Ödeme - orijinal ödeme yöntemine/raylara geri dönün (düzenleyici tercih edilen/zorunlu).
Void - yakalama iptali (raylarla destekleniyorsa), bir refand olarak kabul edilmez.
Ters/Ters ibraz - girişiminizin dışındaki banka/demiryolu mekaniği (anlaşmazlıklar, ters ibrazlar) - refand ile karıştırılmamalıdır.

2) Tam ve kısmi ne zaman verilir

• Tüm siparişi/hizmeti iptal et, yinelenen yazma, sistem hatası.
• Hizmet verilmiyorsa zorunlu (tüketici/düzenleyici kurallarına göre).

• Hizmetin kısmi iptali, orantılı ayarlamalar (indirimler, gecikmeler için tazminat).
• Teknik sınırlar raylar (çalışma başına maksimum miktar) - kısmi seri.
• Post-factum komisyon stopajı (düzenlemelere izin verilen yerlerde) - iGaming'de daha az sıklıkta.

3) Politikalar ve sınırlar

Kaynağa geri ödeme = varsayılan olarak true; İstisnalar - MLRO/uyumluluk durumları (günlüğe kaydedilmiş) aracılığıyla.
Cut-off: Refands (yöntem/yargı tarafından) yakalama N gün izin verilir.
Maks. Kısmi Sayım: Ödeme başına K kısmi sayıdan fazla değildir (genellikle K ≤ 5).
Min Kısmi Miktar: Teknik minimum ray/PSP'den daha düşük değildir.

• Destek ajanı: kısmi ≤ X, tam ≤ Y.
• Yönetici/Finans: aşırı limitler, yöntemler arası istisnalar.
• Tekrarlanan denemelerde soğuma (anti-bounce).

4) Mimari ve olay akışı

• Ödeme Orkestratörü statü gerçeğinin kaynağıdır.
• Geri Ödeme Hizmeti - API, idempotency, retrays düzenlenmesi, günlüğe kaydetme.
• PSP Adaptörleri - Yöntem Entegrasyonları.
• Uzlaşma - otomatik mutabakatlar, DLQ, düzeltmeler.
• Defter/Muhasebe - ilanlar, defektörler, açıklıklarla temizleme.
• Risk/Uyum - Yaptırımlar/SoF tartışmalı senaryolarda kontrol eder.

1. 'Geri ödeme. Create '(API) validation> (limit, balance, policy, gerekirse KYC/SoF).

2. Генерация idempotency_key ('hash (payment_id + refund_amount + reason + nonce)').

3. PSP çağrısı - 'PENDING'.

4. Webhook/yoklama - 'BAŞARI'/' BAŞARISIZ'; Zaman aşımı olduğunda - aynı anahtarla yeniden dener.

5. Olayın Kafka'da yayınlanması - Ledger, BI, uyarılar.

6. Otomatik mutabakat: kayıt defterine 'provider _ refund _ id' eşlemesi.

5) Idempotency ve anti-takes

Aynı refand iki kez yatırılamaz: idempotency depolama yoluyla tüm mantık (KV/Redis + TTL).
payment_id × miktarı × nedeni (ve gerekirse 'partial _ index') üzerindeki anahtarlar.
Retray'ler aynı anahtarı kullanır.
Paralel kısmi, toplam miktarlardaki satır düzeyinde kilitlerle/iyimser versiyonla korunur.

python def refund(payment_id, amount, reason, idem_key):
if idem_store. exists(idem_key): return idem_store. get(idem_key)
with tx():
p = db. get_payment(payment_id, for_update=True)
assert p. captured_amount - p. refunded_amount >= amount > 0 r = p. create_refund(amount, reason, status='PENDING', idem_key=idem_key)
resp = psp. refund(p. provider_txid, amount, idem_key)
return finalize(r, resp. status, resp. ext_id)

6) Veri modeli (minimum yeterli)

json
{
"payment_id": "pay_123",
"captured_amount": 150. 00,
"currency": "EUR",
"refunded_amount": 40. 00,
"refunds": [
{
"refund_id": "rf_001",
"type": "partial    full",
"amount": 20. 00,
"reason_code": "PARTIAL_SERVICE",
"idempotency_key": "idem_a1",
"status": "PENDING    SUCCESS    FAILED",
"provider_refund_id": "psp_rf_9xz",
"created_at": "2025-11-03T12:00:00Z",
"credited_at": "2025-11-03T15:05:00Z",
"notes": "ticket #456"
}
],
"flags": {
"refund_to_source": true,
"jurisdiction": "EEA",
"kyc_tier_required": "tier2"
}
}

7) Ödeme raylarındaki özellikler

Kartlar (Visa/Mastercard)

Tam/kısmi destek; Genellikle biraz kısmi; TtR müşterinin bankasına bağlıdır (T + 1... T + 5 bp).
Başarı hakkında Webhooks hızlı bir şekilde gelir, ancak deşarj üzerine kayıt geç olabilir - destek şablonlarında açıklıyoruz.

A2A/Open Bankacılık/RTP

Genellikle anında geri dönüş (ters/kredi itme); Bazı sağlayıcılar sadece tam veya 1 kısmi destekler.
Orijinal hesaba sıkı sıkıya bağlı; kaynağa geri ödeme gereklidir.

Elektronik cüzdanlar

Normal tam/kısmi; TtR dakika; Kısmi ve minimum miktar limitleri.

Kuponlar/Ön ödemeli

Genellikle, kaynak geri ödeme politikası kullanılamaz: Dahili cüzdana geri dönün veya yeniden kupon verin (sağlayıcı nasıl yapılacağını biliyorsa). Uyumluluk maddeleri gerektirir.

Kripto

Raylar - uçucu; Tercihen refand yöntemi olarak kullanılmaz. İzin verilirse: belgelenmiş oran ve komisyonlarla aynı adrese/borsaya dönün; AML taraması.

8) Muhasebe, uzlaşma ve finans

Ledger: Yakalamada "DR Revenue/CR Cash" ilanları; Geri ödeme - writeback. Kısmi orantılı olarak yansıtılır.
Tanıma: iGaming'de refand, ilgili dönemin GGR'sini azaltır (muhasebe politikası).
Mutabakat: günlük mutabakatlar 'merchant _ refund _ id ↔ provider_refund_id', statüler, miktarlar, döviz kurları.
FX: uygulanabilir olduğunda kursların mantığını (yakalama sırasında veya geri ödeme sırasında) düzeltin; Yayılma ızgarasını tut.

9) KPI'lar, hedefler ve uyarılar (Sağlık İadesi)

Geri Ödeme Oranı = 'Refunded _ Tx/ Captured_Tx'.
İade Miktarı Oranı = 'İade Edildi _ Miktar/ Captured_Amount'.
TtR p95 = p95 ('credited _ at - created_at') yöntemiyle.
Geri Ödeme Hatası Oranı = 'Başarısız/Denendi' (<0. 3%).
Kaynağa Geri Ödeme % ≥ %95 (varsa).
Çift Geri Ödeme Olayları = 0.

• 'TtR p95', P2 yöntemi ile SLO'dan daha yüksektir.
• Bir sağlayıcıda "Geri Ödeme Oranı'ile ani artışlar/BIN - P1 (check grabs/double).
• Herhangi bir 'Çift İade> 0' - P0 (otomatik refandların hemen dondurulması).

10) SQL dilimleri

10. 1 Refand profili

sql
SELECT
DATE_TRUNC('day', r. created_at) AS d,
method_code, provider,
COUNT() FILTER (WHERE r. status='SUCCESS')  AS refunds_ok,
COUNT() FILTER (WHERE r. status='FAILED')  AS refunds_fail,
SUM(r. amount) AS refunded_amount,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (r. credited_at - r. created_at))) AS ttr_p95_sec
FROM refunds r
JOIN payments p ON p. payment_id = r. payment_id
GROUP BY 1,2,3;

10. 2 Kısmi için denge kontrolü

sql
SELECT p. payment_id,
p. captured_amount,
SUM(r. amount) AS refunded_sum,
(p. captured_amount - SUM(r. amount)) AS refundable_left
FROM payments p
LEFT JOIN refunds r ON r. payment_id = p. payment_id AND r. status IN ('SUCCESS','PENDING')
GROUP BY 1,2
HAVING (p. captured_amount - SUM(r. amount)) < 0;

11) UX ve destek

Mesaj şablonları yöntemlerle: Biz kartlara deşarj olası gecikme açıklamak, A2A - neredeyse anında.
Ofisteki durumlar: 'Verilen - Süreçte - İade Edildi'; Beklenen kayıt tarihini göster.
Nedenler (reason_code) - insan tarafından okunabilir: 'Yinelenen yazma', 'Hizmet iptali', 'Kısmi tazminat'.
Self servis kısmi - yalnızca sınırları ve açık kuralları olan güvenli.

12) Risk ve uyum

Anti-aklama: refand alternatif bir kanala çıkış haline dönüşmemelidir; MLRO onayı ile istisnalar işlemek.
Yaptırımlar/REP: "kırmızı" hesaplara/ayrıntılara başlatılan iadeler için - zorunlu doğrulama.
DSAR/Retention - Bir retention politikası dahilinde refands izlerini depolayın.
Yerel kurallar: iadeler için şartlar ve prosedür (örneğin, tüketici düzenlemeleri) - politikaya yansıtılır.

13) Sık yapılan hatalar ve bunlardan nasıl kaçınılacağı

Idempotency ve tekrarlanan webhooks eksikliği nedeniyle çift refand - mağaza idem anahtarı/durumu, bakiyeyi kontrol edin.
Kısmi> balance> row-lock/optimist versiyon ve sıkı kontroller.
Uyumluluk izni olmadan çapraz yöntem geri ödemesi - kaynağa geri ödemeyi ihlal eder.
Raporlarda boşluk ve geri ödeme karıştırma - KPI'ların bozulması.
Otomatik kontrol yok - PSP ve defteriniz arasında kara delikler var.

14) Oyun kitapları

Sağlayıcı iadelerindeki artış - yetkilendirme hatalarını kontrol edin/kopyaları yakalayın, yük devretmeyi açın, PSP ile iletişim kurun.
Toplu kısmi tazminat (kampanya) - kısmi sınırı yükseltin, grup işlemlerini etkinleştirin ve mutabakatları güçlendirin.
Webhooks hatası - yoklamaya geçin, TTL idempotensisini artırın, otomatik refandları erteleyin.
Kaynağa geri ödeme istisnası (nadir) - MLRO artışı, belgelenmiş ödeme ve 'comp _ approved = true'.

15) Test Durumları (UAT/Prod)

1. Bir çekimden sonra tam geri ödeme - dengeyi doğru şekilde sıfırlar.
2. Toplu kısmi (3 ×) - toplam ≤ yakalama; Geri kalanı için dolu.
3. Idempotency - Aynı sorguyu tekrarlayın - 1 sonuç.
4. Webhook-bounce: 3 özdeş bildirim - bir yazma/kredi.
5. Mutabakatlar: yapay uyumsuzluk - uyarı ve otomatik düzeltme.
6. Hakların kısıtlanması: Acente kısmi sınırı aşamaz.
7. Kesme: geç refand girişimi - doğru başarısızlık ve günlüğe kaydetme.

16) Uygulama kontrol listesi

• yargı yetkisi/yöntemiyle tam/kısmi + kaynağa geri ödeme politikaları.
• Idempotency, inzivalar, webhooks ve yoklama, DLQ.
• Geri dönmek ve reason_code için kalıntı ile veri modeli.
• Defter ve günlük otomatik mutabakatlar.
• KPI/gösterge tablosu: Geri Ödeme Oranı, TtR, Hata, Çift Geri Ödeme = 0.
• Haklar ve uygulama matrisi, destek şablonları.
• UAT test durumları ve üretim seviyesi uyarıları.

Özet

Refand yönetimi, süreçlerin sıkı bir disiplinidir: kaynağa geri ödeme, idempotency, şeffaf veri modeli, otomatik mutabakat ve anlaşılabilir kısmi/tam politikalar. Bu temellerle, TtR'yi düşük tutarsınız, hatalar sıfıra yakındır, kopyalar imkansızdır ve uyumluluk ve finans iş hedefleriyle senkronize edilir.