Qismən və tam refandlar

TL; DR

Refand - captured məbləğin əks əməliyyatıdır. Tam tam əməliyyat bağlayır, qismən hissə qaytarır (tam partial seriyası ola bilər). Kritik: refund-to-source, ciddi idempotentlik, səbəblərin qeydiyyatı, və webhook/retray ilə orkestr. Refund Rate, TtR p95, Refund Error ölçün və auto-yoxlama vasitəsilə dubl/uyğunsuzluqları aradan qaldırın.

1) Terminlər və prinsipial fərqlər

Full Refund - qeydə alınan bütün məbləğin qaytarılması ('refund _ amount = capture_amount').
Partial Refund - hissənin qaytarılması ('0 <refund_amount <capture_amount'), qalan partial ümumi' capture _ amount '-a icazə verir.
Refund to Source - orijinal üsul/ödəniş relslərinə geri qaytarılması (tənzimləyici üstünlük/məcburi).
Void - capture əvvəl ləğv (relslər tərəfindən dəstəklənərsə), refand hesab edilmir.
Reversal/Chargeback - təşəbbüsünüzdən kənar bank/rels mexanikləri (mübahisələr, çarjbeklər) - refand ilə qarışdırılmamalıdır.

2) Tam vs qismən verdikdə

• Sifarişin/xidmətin tamamilə ləğv edilməsi, təkrar silinmə, sistem səhvi.
• Xidmət göstərilmədikdə (istehlakçı/tənzimləyici qaydalarına əsasən) məcburidir.

• Xidmətin qismən ləğvi, mütənasib düzəlişlər (endirimlər, gecikmələrin kompensasiyası).
• Relsin texniki limitləri (bir əməliyyat üçün maksimum məbləğ) - partial seriyası.
• Post-faktum saxlama komissiyası (tənzimləyici icazə verilir) - daha az iGaming.

3) Siyasət və limitlər

Refund-to-source = default; istisnalar - MLRO/komplayens-keys vasitəsilə (loge).
Cut-off: refands capture andan N gün icazə verilir (metod/yurisdiksiya).
Max Partial Count: payment (tipik K ≤ 5) üçün ən çox K partial.
Min Partial Amount: texniki minimum rels/PSP-dən aşağı deyil.

• Sapport agenti: partial ≤ X, full ≤ Y.
• Menecer/maliyyə: limitdən yuxarı, xaç-metodik istisnalar.
• Təkrar cəhdlər üçün Cooling-off (anti-draging).

4) Memarlıq və hadisələr axını

• Payment Orchestrator status həqiqət mənbəyidir.
• Refund Service - API, idempotentlik, retraj orkestri, jurnallaşdırma.
• PSP Adapters - metodlara uyğun inteqrasiya.
• Reconciliation - avtomatik yoxlama, DLQ, düzəlişlər.
• Ledger/Accounting - naqillər, deferlər, klirinqlərlə bərabərləşdirmə.
• Risk/Compliance - mübahisəli ssenarilərdə sanksiyaların/SoF yoxlanılması.

1. `Refund. Create '(API) → validasiya (limitlər, balans, siyasət, lazım olduqda KYC/SoF).

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

3. PSP zəng → status 'PENDING'.

4. Webhook/polling → 'SUCCESS '/' FAILED'; zaman-aut - eyni açar ilə retrai.

5. Tədbirin nəşri Kafka → Ledger, BI, alertlər.

6. Avto-müqayisə: reyestr ilə 'provider _ refund _ id' müqayisə.

5) İdempotentlik və anti-dubli

Eyni refand iki dəfə daxil ola bilməz: idempotency storage (KV/Redis + TTL) vasitəsilə bütün məntiq.
Açarlar payment_id × amount × reason (və lazım olduqda 'partial _ index').
Retrailer eyni açardan istifadə edirlər.
Paralel partial row-level locks/optimistic version aggregate məbləğləri ilə qorunur.

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) Məlumat modeli (minimum kifayət qədər)

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) Ödəniş relslərinin xüsusiyyətləri

Kartlar (Visa/Mastercard)

full/partial dəstəkləyir; tez-tez bir neçə partial; TtR müştərinin bankından asılıdır (T + 1... T + 5 s).
Müvəffəqiyyət haqqında vebhuklar tez gəlir, lakin məzuniyyət gecikə bilər → sapport şablonlarında izah olunur.

A2A/Open Banking/RTP

Tez-tez ani geri (reversal/credit push); bəzi provayderlər yalnız full və ya 1 partial dəstəkləyir.
Orijinal hesaba ciddi bağlama; refund-to-source tələb olunur.

Elektron pul kisələri

Normal full/partial; TtR dəqiqə; partial sayı və minimum məbləği məhdudiyyətlər.

Kuponlar/Prepaid

Adətən refund-to-source mövcud deyil → siyasət: daxili cüzdan və ya re-issue çek geri (provayder bilirsə). Uyğunluq şərtləri tələb edir.

Kripto

Relslər - dəyişkən; refand üsulu kimi istifadə edilməməlidir. Icazə verildikdə: sənədləşdirilmiş kurs və komissiyalarla eyni ünvana/birjaya qaytarılması; AML-skrininq.

8) Mühasibat uçotu, yoxlama və maliyyə

Ledger: kabellər 'DR Revenue/CR Cash' capture; refund - əks qeydlər. Partial proporsional əks olunur.
Recognition: iGaming refand müvafiq dövr GGR azaldır (mühasibat siyasəti).
Reconciliation: gündəlik yoxlamalar 'merchant _ refund _ id provider_refund_id', statuslar, məbləğlər, FX kursları.
FX: kursların məntiqini (capture anda və ya refund anda) tətbiq oluna bilən yerdə qeyd edin; spread barmaqlığı saxlayın.

9) KPI, hədəflər və risklər (Refund Health)

Refund Rate = 'Refunded _ Tx/ Captured_Tx' (seqmentləşdirmək: səbəblərə görə).
Refund Amount Ratio = `Refunded_Amount / Captured_Amount`.
TtR p95 = p95 ('credited _ at - created_at') metodu ilə.
Refund Error Rate = `Failed / Attempted` (<0. 3%).
Refund-to-Source% ≥ 95% (harada mövcuddur).
Double Refund Incidents = 0.

• 'TtR p95' SLO → P2 metodu ilə yuxarıda.
• Spikes 'Refund Rate' bir provayder/BIN → P1 (check-up/double).
• Hər hansı bir 'Double Refund> 0' → P0 (avtomatik refandların dərhal dondurulması).

10) SQL dilimləri

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 partial üçün qalıq nəzarət

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 və sapport

Metodlara görə mesaj şablonları: kartlar mümkün çıxarılma gecikməsini izah edir, A2A - demək olar ki, dərhal.
Kabinetdəki statuslar: 'Rəsmiləşdirilmiş → Emal edilmiş → Geri qaytarılmışdır'; gözlənilən qəbul tarixini göstərmək.
Səbəblər (reason_code) - insan tərəfindən oxunan: «Silinmənin təkrarlanması», «Xidmətin ləğvi», «Qismən kompensasiya».
Self-service partial - yalnız limitlər və dəqiq qaydalarla təhlükəsizdir.

12) Risk və uyğunluq

Anti-yuyulma: refand alternativ kanala çevrilməməlidir; MLRO təsdiqi ilə istisnaları qeyd edin.
Sanksiyalar/RER: «qırmızı» hesablara/rekvizitlərə təşəbbüs göstərilən geri qaytarmalar zamanı - məcburi yoxlama.
DSAR/Retention: məlumat saxlama siyasəti çərçivəsində refand izlərini saxlayın.
Yerli qaydalar: qaytarma vaxtı və qaydaları (məsələn, istehlak qaydaları) - policy-də əks olunur.

13) Tez-tez səhvlər və onlardan necə qaçmaq olar

İkiqat refand idempotentlik və təkrar webhook olmaması səbəbindən → idem-key/status saxlamaq, qalığını yoxlamaq.
Partial> balans → row-lock/optimistic version və ciddi yoxlamalar.
Uyğunluq icazəsi olmadan cross-method refund → refund-to-source pozur.
Hesabatlarda void və refund qarışdırılması → KPI təhrif.
PSP və ledger arasında avtomatik yoxlama → «qara dəliklər» yoxdur.

14) Playbook

Provayder geri artım → authorization nasazlıqları/dubly capture yoxlamaq, feylover aktiv, PSP ilə əlaqə.
Kütləvi partial kompensasiya (kampaniya) → partial limitini qaldırmaq, qrup əməliyyatlarını daxil etmək, yoxlamaları gücləndirmək.
Səhv webhook → polling keçid, TTL idempotentlik artırmaq, avto-refand təxirə.
Refund-to-source istisna (nadir hallarda) → MLRO eskalasiyası, sənədləşdirilmiş ödəniş və 'comp _ approved = true' işarəsi.

15) Test halları (UAT/Prod)

1. Bir capture → sonra tam refund düzgün qalan sıfırlayır.
2. partial seriyası (3 ×) → toplamı ≤ capture; sonra qalan tam.
3. İdempotentlik: eyni sorğunun təkrarı → 1 nəticə.
4. Vebhuk drebezg: 3 eyni bildiriş → bir debet/qəbz.
5. Uyğunlaşma: süni mismatch → alert və avtomatik korreksiyası.
6. Hüquqların məhdudlaşdırılması: agent partial limitini keçə bilməz.
7. Cut-off: gec refanda cəhd → düzgün imtina və log.

16) Giriş yoxlama siyahısı

• Yurisdiksiya/metodlar üzrə full/partial + refund-to-source siyasəti.
• İdempotentlik, retraj, vebhuk və polling, DLQ.
• Geri və reason_code qalığı ilə data modeli.
• Ledger və gündəlik avtomatik yoxlama.
• KPI/dashboard: Refund Rate, TtR, Error, Double Refund = 0.
• Hüquqlar və appruv matrisi, sapport şablonları.
• UAT Test Halları və Prot-Level Riskləri.

Xülasə

Refandların idarə edilməsi proseslərin ciddi intizamıdır: refund-to-source, idempotentlik, məlumatların şəffaf modeli, avtomatik yoxlama və partial/full siyasətləri. Bu cür əsaslarla siz TtR-ni aşağı saxlayırsınız, səhvlər sıfırdır, ikiqat mümkün deyil, uyğunluq və maliyyə biznes məqsədləri ilə sinxronlaşdırılır.