Refanduri parțiale și complete

TL; DR

Refand este operațiunea inversă pe suma capturată. Închide complet întreaga tranzacție, returnează parțial o parte (poate fi o serie parțială până la completă). Critic: rambursare la sursă, idempotență strictă, logare motiv, și orchestrare cu webhooks/retras. Măsurați rata de rambursare, TtR p95, Eroare de rambursare și eliminați duplicatele/inconsecvențele prin reconcilieri automate.

1) Termeni și diferențe fundamentale

Rambursare completă - Returnează întreaga sumă angajată ('rambursare _ sumă = capture_amount').
Rambursare parțială - returnează o parte ('0 <refund_amount <capture_amount'), permite restul parțial la totalul' capture _ sound '.
Rambursarea către Sursă - întoarcerea la metoda de plată inițială/șine (preferată/obligatorie).
Void - anularea capturării (dacă este acceptată de șine), nu este considerată un refand.
Inversarea/Chargeback - mecanica bancară/feroviară în afara inițiativei dvs. (litigii, chargebacks) - a nu se confunda cu refand.

2) Când să emită complet vs parțială

• Anulați întreaga comandă/serviciu, duplicați scrierea, eroarea de sistem.
• Obligatoriu în cazul în care serviciul nu este furnizat (în conformitate cu regulile consumatorului/autorității de reglementare).

• Anularea parțială a serviciului, ajustări proporționale (reduceri, compensații pentru întârzieri).
• Șine limită tehnică (suma maximă pe operațiune) - serie parțială.
• Reținerea comisionului post-factum (în cazul în care reglementarea este permisă) - mai rar în iGaming.

3) Politici și limite

Rambursare la sursă = adevărat în mod implicit; excepții - prin MLRO/cazuri de conformitate (logate).
Cut-off: refandurile sunt permise N zile de la captare (prin metodă/jurisdicție).
Număr parțial maxim: nu mai mult de K parțial pe plată (de obicei K ≤ 5).
Suma minimă parțială: nu mai mică decât șina tehnică minimă/PSP.

• Agent suport: parțial ≤ X, plin ≤ Y.
• Manager/Finanțe: peste limite, excepții de metodă încrucișată.
• Răcire pe încercări repetate (anti-saritura).

4) Arhitectura și fluxul de evenimente

• Orchestratorul de plăţi este sursa adevărului statutului.
• Serviciul de rambursare - API, idempotență, orchestrarea retroys, logare.
• Adaptoare PSP - Integrarea metodelor.
• Reconciliere - auto-reconcilieri, DLQ, corecții.
• Registru/Contabilitate - postări, defectoare, compensare cu compensări.
• Risc/Conformitate - Sancțiuni/Controale SoF în scenarii controversate.

1. Creați "(API) → de validare (limite, echilibru, politică, KYC/SOf, dacă este necesar).

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

3. Apelul PSP → „ÎN AȘTEPTARE”.

4. Webhook/sondare → „SUCCES ”/„ EȘEC”; când timeout - se retrage cu aceeași cheie.

5. Publicarea evenimentului în Kafka → Ledger, BI, alerte.

6. Auto-reconciliere: mapping 'provider _ rambursare _ id' la registru.

5) Idempotență și anti-ia

Același refand nu poate fi creditat de două ori: toate logica prin stocare idempotency (KV/Redis + TTL).
Tastele de pe payment_id × suma × motiv (și, dacă este necesar, „parțial _ index”).
Retraiele folosesc aceeaşi cheie.
Paralele parțiale sunt protejate de încuietori de nivel rând/versiune optimistă pe cantități agregate.

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) Modelul de date (minim suficient)

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) Caracteristici pe șine de plată

Carduri (Visa/Mastercard)

Suport complet/parțial; adesea oarecum parțială; TtR depinde de banca clientului (T + 1... T + 5 bp).
Cărțile web despre succes vin rapid, dar înscrierea la descărcare poate întârzia → explicăm în șabloanele de asistență.

A2A/Open Banking/RTP

De multe ori instant return (inversare/credit push); unii furnizori suportă doar parțial sau parțial 1.
Obligativitatea strictă a contului original; rambursarea la sursă este necesară.

Portofele electronice

Normală completă/parțială; minute TtR; limitele parțiale și minime ale sumei.

Vouchere/Prepaid

De obicei, politica de → nu este disponibilă pentru rambursare la sursă: returnarea la portofelul intern sau reemiterea voucherului (dacă furnizorul știe cum). Necesită clauze de conformitate.

Crypto

Șine - volatile; preferabil nu este utilizat ca o metodă de refand. Dacă este permis: întoarceți-vă la aceeași adresă/schimb cu rata și comisioanele documentate; Screening-ul AML.

8) Contabilitate, reconciliere și finanțe

Registru: postările „DR Revenue/CR Cash” la captură; la rambursare - writeback. Parțial se reflectă proporțional.
Recunoaștere: în iGaming, refand-ul reduce RGG din perioada corespunzătoare (politica contabilă).
Reconciliere: zilnic reconcilieri "comerciant _ rambursare _ id ↔ provider_refund_id', statusuri, sume, rate FX.
FX: fixați logica cursurilor (în momentul capturării sau în momentul rambursării), după caz; țineți grila de răspândire.

9) KPI-uri, obiective și alerte (Sănătate rambursată)

Rata de rambursare = 'Rambursat _ Tx/ Captured_Tx'.
Rata sumei de rambursare = 'Rambursat _ Suma/ Captured_Amount'.
TtR p95 = p95 ('credited _ at - created_at') prin metoda.
Rata de eroare a rambursării = 'Eșec/încercare' (<0. 3%).
Rambursare la sursă% ≥ 95% (dacă este disponibil).
Incidente de rambursare dublă = 0.

• „TtR p95” este mai mare decât SLO prin metoda P2 →.
• Spikes de „Rata de rambursare” într-un singur furnizor/BIN → P1 (verificați apucături/duble).
• Orice 'Dublu rambursare> 0' → P0 (înghețarea imediată a auto-restituiri).

10) Felii SQL

10. 1 Profil Refand

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 Controlul echilibrului pentru parțial

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 și suport

Șabloane de mesaje prin metode: explicăm posibila întârziere a descărcării de gestiune pe carduri, A2A - aproape instantaneu.
Statusuri în birou: „Emise → În proces → returnate”; Arată data preconizată a înscrierii.
Motive (reason_code) - lizibil uman: 'Duplicat write-off', 'Anulare serviciu', 'Compensare parţială'.
Self-service parțial - sigur numai cu limite și reguli clare.

12) Risc și conformitate

Anti-spălare: refand nu ar trebui să se transforme în ieșire la un canal alternativ; să comită excepții cu aprobarea MLRO.
Sancțiuni/REP: pentru returnările inițiate în conturile/detaliile „roșii” - verificare obligatorie.
DSAR/Retention - Stocați urme de refanduri în cadrul unei politici de retenție.
Reguli locale: termeni și procedură pentru returnări (de exemplu, reglementări privind protecția consumatorilor) - reflectate în politici.

13) Greșeli frecvente și cum să le evitați

Refand dublu din cauza lipsei de idempotenta si carti web repetate → stoca idem cheie/stare, verifica soldul.
Parțial> echilibru → versiunea de blocare a rândului/optimistă și verificări stricte.
Rambursarea metodelor încrucișate fără permisiunea de conformitate → încalcă rambursarea la sursă.
Amestecarea nulității și rambursarea în rapoarte → denaturarea KPI-urilor.
Nu există verificări automate → găuri negre între PSP și registrul dvs.

14) Playbooks

O creștere a furnizorului revine → verificați eșecurile de autorizare/duplicatele de captare, activați failover-ul, contactați PSP-ul.
Compensarea parțială în masă (campanie) → ridica limita parțială, permite operațiuni de grup și consolidează reconcilierile.
Eroare la cărți web → comutare la sondare, creșterea idempotenței TTL, amânarea auto-refandurilor.
Excepție de la rambursare la sursă (rară) → escaladarea MLRO, plata documentată și „rep _ approved = true”.

15) Cazuri de testare (UAT/Prod)

1. Rambursarea completă după o captură → resetează corect soldul.
2. Lot parțial (3 ×) → sumă ≤ captură; apoi plin pentru restul.
3. Idempotency - Repetați aceeași interogare → 1 rezultat.
4. Webhook-bounce: 3 notificări identice → o reducere/credit.
5. Reconcilieri: neconcordanță artificială → alertă și corecție automată.
6. Restricționarea drepturilor: agentul nu poate depăși limita parțială.
7. Cut-off: Refand târziu încercarea de → corecta eșecul și logare.

16) Lista de verificare a implementării

• politici complete/parțiale + de rambursare la sursă prin jurisdicție/metodă.
• Idempotență, retrageri, webhook-uri și sondaje, DLQ.
• Modelul de date cu rezidual pentru a reveni și reason_code.
• Registru și auto-reconcilieri zilnice.
• KPI/tablou de bord: Rata de rambursare, TtR, Eroare, Rambursare dublă = 0.
• Drepturi și matrice de aplicare, șabloane de sprijin.
• Cazuri de testare UAT și alerte la nivel de producție.

Rezumat

Managementul Refand este o disciplină strictă a proceselor: rambursare la sursă, idempotență, model transparent de date, auto-reconciliere și politici parțiale/complete ușor de înțeles. Cu astfel de fundamente, păstrați TtR scăzut, erori aproape de zero, duplicate imposibile, și conformitatea și finanțarea sincronizate cu obiectivele de afaceri.