Rifandi parziali e completi

TL; DR

Refand è l'operazione inversa per la somma capturata. Completa chiude l'intera transazione, parziale restituisce la parte (può essere una serie partiale fino a completa). Critico: refund-to-source, idampotenza rigorosa, registrazione delle cause, e orchestrazione con webhoop/retrai. Misuriamo il Refund Rate, il TtR p95, il Refund Errore e eliminiamo le doppie/incongruenze attraverso i controlli automatici.

1) Termini e differenze di principio

Full Refund - Restituisce l'intero valore registrato ('refund _ amount = capture _ amount').
Partial Refund - Restituisce la parte ('0 <refund _ amount <capture _ amount'), consente il resto della parte fino al totale'capture _ amount '.
Refund to Source - Restituzione al metodo/binario originale di pagamento (regolamentare preferibilmente/obbligatorio).
Void - Annulla a capture (se supportato da binari) non è considerato refanda.
Reversal/Chargeback - meccaniche bancarie/rotaie fuori dalla vostra iniziativa (discussioni, Charjback) - non confondere con Refand.

2) Quando emettere un vs completo parziale

• Annullamento dell'intero ordine/servizio, addebito duplicato, errore di sistema.
• Obbligatorio in caso di servizio fallito (secondo le regole del consumatore/regolatore).

• Cancellazione parziale del servizio, aggiustamenti proporzionali (sconti, compensazione dei ritardi).
• I limiti tecnici del binario (importo massimo per singola operazione) sono una serie di partial.
• La detrazione post-fattura delle commissioni (in cui è autorizzata la regolamentazione) è meno frequente nel iGaming.

3) Criteri e limiti

Refund-to-source = true predefinito eccezioni - tramite MLRO/valigetta di compilazione (logica).
Cut-off: i refandi sono ammessi in N giorni a partire da capture (in base al metodo/giurisdizione).
Max Partial Count: non più K partial per payment (tipico K-5).
Min Partial Amount non inferiore al minimo tecnico del binario/PSP.

• Agente dello Zapport, parziale X, full Y.
• Manager/finanza: oltre i limiti, eccezioni crocifissi.
• Cooling-off per riprovare (anti-drebesing).

4) Architettura e flusso di eventi

• Payment Orchestrator è la fonte della verità degli stati.
• Refund Service - API, idampotenza, orchestrazione dei retrai, registrazione.
• PSP Adatters - Integrazione sui metodi.
• Recordation - Incrociatori automatici, DLQ, correzioni.
• Ledger/Accounting - cablaggi, defer, allineamento con clearing.
• Risk/Compliance - Controlli sulle sanzioni/SoF per gli scenari controversi.

1. `Refund. Create (API) di convalida (limiti, residuo, policy, se necessario).

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

3. Chiamata PSP con stato PENDING.

4. Webhook/polling «SUCCESS »/« FAILED»; time-out - retrai con la stessa chiave.

5. Pubblicare un evento su Kafka n'Ledger, BI, alert.

6. Incrociatura automatica: mappa'provider _ refund _ id 'al registro.

5) Idempotenza e anti-doppie

Lo stesso refand non può essere registrato due volte: tutta la logica attraverso lo storage idempotency (KV/Redis + TTL).
Chiavi su payment _ id x amount x reason (e, se necessario, «partial _ index»).
I retrai usano la stessa chiave.
I partial paralleli sono protetti da row-level locks/variation ottimistica sull'importo aggregate.

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) Modello di dati (minimo sufficiente)

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) Caratteristiche dei binari di pagamento

Carte (Visa/Mastercard)

Supporta full/partial; spesso più partial; Il TtR dipende dalla banca del cliente (T + 1... T + 5 b.d.).
I webhook di successo arrivano rapidamente, ma l'iscrizione può essere ritardata per spiegazione nei modelli di zapport.

A2A/Open Banking/RTP

Restituzioni frequenti (reversal/credit push) alcuni provider supportano solo full o 1 partial.
Collegamento rigoroso al conto di origine refund-to-source è obbligatorio.

Portafogli elettronici

Normale full/partial; TtR minuti; limitazione del numero di partial e dell'importo minimo.

Voucher/Prepaid

Di solito non è disponibile un criterio di riferimento-to-source: restituzione a un portafoglio interno o a un voucher re-issue (se il provider sa fare). Richiede riserve complesse.

Crittografia

I binari sono volatili; preferibilmente non usare come metodo di refanda. Se consentito: rimborso allo stesso indirizzo/borsa con corso documentato e commissioni; screening AML.

8) Contabilità, incrocio e finanza

Ledger: cavi dì DR Revenue/CR Cash "per capture; Quando si fa rifunzione, le voci invertite. Partial si riflette proporzionalmente.
Recognition - In un iGaming, riduce la GGR del periodo corrispondente (criterio di account).
Ripartizione: compressioni giornaliere'merchant _ refund _ id _ provider _ refund _ id ', states, importi, corsi FX.
FX: fissa la logica dei corsi (al momento della capture o al momento del refund), se applicabile; tenete le sbarre dello spread.

9) KPI, obiettivi e alert (Refund Health)

Refund Rate = 'Refunded _ Tx/Captured _ Tx' (segmentare per motivi).
Refund Amount Ratio = `Refunded_Amount / Captured_Amount`.
TtR p95 = p95 ('credited _ at - created _ at') secondo il metodo.
Refund Error Rate = `Failed / Attempted` (<0. 3%).
Refund-to-Source% ≥ 95% (dove disponibile).
Double Refund Incidents = 0.

• « p95» sopra lo SLO secondo il metodo P2.
• Spikes per «Refund Rate» in un unico provider/BIN → P1 (controlla sequenze/riprese).
• Qualsiasi «Doppio Refund> 0» → P0 (congelamento immediato dei rifandi auto).

10) Tagli SQL

10. 1 Profilo 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 Controllo residuo per partial

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 e sapport

Modelli di messaggi di metodo: mappe spieghiamo il possibile ritardo nell'estrazione, A2A quasi istantaneamente.
Stato nell'ufficio: "→ → In lavorazione" Restituito "; Mostra la data di iscrizione prevista.
I motivi (reason _ code) sono gli esseri umani: «Duplicazione dei prelievi», «Cancellazione del servizio», «Compensazione parziale».
Self-service partial è sicuro solo con limiti e regole chiare.

12) Rischio e compliance

Anti-riciclaggio: il Refand non deve diventare un canale alternativo; fissare le eccezioni con l'approvazione MLRO.
Le sanzioni/RER sono un controllo obbligatorio per i rimborsi avviati su account/accessori rossi.
DSAR/Retention - Memorizza le tracce di refand all'interno del criterio di conservazione dei dati.
Regole locali: data e ordine dei rimborsi (ad esempio, regolamenti per i consumatori) - riflesso in policy.

13) Errori frequenti e come evitarli

Doppio Rifand a causa della mancanza di idampotenza e ripetuti webhoot, memorizzare la chiave/stato idem, controllare il resto.
Partial> residuo → row-lock/ottimistica versione e controlli rigorosi.
Cross-method refund senza autorizzazione compilata viola il refund-to-source.
La miscelazione tra il void e il refund nei rapporti → una distorsione KPI.
Non ci sono auto tra il PSP e il tuo atore.

14) Playbook

L'aumento dei ritorni del provider consente di verificare i guasti/riprese automatici, attivare il feelover, contattare il PSP.
I partial compensi di massa (campagna) consentono di aumentare il limite di partial, attivare le operazioni di gruppo e aumentare i controlli.
L'errore dei webhocks → di passare al polling, aumentare l'idampotenza TTL, ritardare il rifando automatico.
L'eccezione refund-to-source (raramente) è l'escalation MLRO, il pagamento documentato e l'etichetta'pop _ approved = true '.

15) Valigette di prova (UAT/Prod)

1. Full refund dopo una capture → azzera correttamente il resto.
2. Serie partiale (3 x): somma di capture; poi full per il resto.
3. Idempotenza: ripetizione della stessa query: risultato 1.
4. Webhook - 3 notifiche identiche per un prelievo/iscrizione.
5. Scorciatoie: mismatch artificiale, alert e correzione automatica.
6. Limitazione dei diritti: l'agente non può superare il limite di partial.
7. Cut-off - Tentativo di Reading tardivo per un corretto guasto e loging.

16) Foglio di controllo dell'implementazione

• Criteri full/partial + refund-to-source per giurisdizioni/metodi.
• Idempotenza, retrai, webhook e polling, DLQ.
• Modello di dati con residuo di restituzione e reason _ code.
• Ledger e incroci auto giornalieri.
• KPI/dashboard: Refund Rate, , , Doppio Refund = 0.
• Diritti e abbreviazione, modelli di zapport.
• Valigette di prova UAT e alert di livello prod.

Riepilogo

La gestione dei refandi è una disciplina rigorosa dei processi: refund-to-source, idempotenza, modello di dati trasparente, incrociatura automatica e regole partial/full comprensibili. Con queste basi si mantiene basso, gli errori sono a zero, le prese sono impossibili e la compliance e la finanza sono sincronizzati con gli obiettivi aziendali.