Częściowe i kompletne refasy

TL; DR

Refand jest odwrotną operacją na wychwytywanej kwocie. Pełny zamyka całą transakcję, częściowy zwraca część (może być częściową serią do pełnej). Krytyczne: zwrot do źródła, ścisła idempotencja, logowanie powodów i orkiestra z hakami/retrasami. Zmierz stawkę zwrotu, TtR p95, błąd zwrotu i wyeliminować duplikaty/niespójności poprzez automatyczne pojednanie.

1) Terminy i podstawowe różnice

Pełny zwrot pieniędzy - zwraca całą zobowiązaną kwotę ('refund _ amount = capture_amount').
Częściowy zwrot pieniędzy - zwraca część ('0 <refund_amount <capture_amount'), umożliwia resztę częściową do całkowitej' capture _ amount '.
Zwrot do źródła - powrót do pierwotnej metody płatności/szyn (preferowane/obowiązkowe).
Nieważność - anulowanie przechwytywania (jeśli obsługiwane przez szyny), nie jest uważane za refand.
Odwrócenie/obciążenie zwrotne - mechanika bankowa/kolejowa poza Twoją inicjatywą (spory, obciążenia zwrotne) - nie mylić z odmową.

2) Kiedy wydać pełny vs częściowy

• Anuluj całe zamówienie/usługę, zduplikowane umorzenie, błąd systemu.
• Obowiązkowe, jeśli usługa nie jest świadczona (zgodnie z zasadami konsumenta/regulatora).

• Częściowe anulowanie usługi, proporcjonalne korekty (rabaty, odszkodowanie za opóźnienia).
• Granice techniczne szyn (maksymalna ilość na operację) - seria częściowa.
• Wstrzymywanie prowizji po stronie faktycznej (gdzie dozwolone są przepisy) - rzadziej w iGaming.

3) Polityki i ograniczenia

Zwrot do źródła = domyślnie true; wyjątki - poprzez MLRO/przypadki zgodności (rejestrowane).
Odcięcie: refands są dozwolone N dni od wychwytywania (metodą/jurysdykcją).
Maksymalna liczba cząstkowa: nie więcej niż K częściowa za płatność (zazwyczaj K ≤ 5).
Minimalna ilość częściowa: nie niższa niż minimalna techniczna kolej/PSP.

• Środek wspomagający: częściowy ≤ X, pełny ≤ Y.
• Menedżer/Finanse: ponad limity, wyjątki metodologiczne.
• Chłodzenie przy powtarzających się próbach (anty-bounce).

4) Architektura i przepływ wydarzeń

• Orkiestra płatnicza jest źródłem prawdy o statusie.
• Usługa zwrotu pieniędzy - API, idempotencja, orkiestra retras, logowanie.
• Adaptery PSP - integracja metod.
• Pojednanie - automatyczne uzgodnienia, DLQ, korekty.
• Księgowość/Księgowość - delegowanie, defektory, rozliczanie z rozliczaniem.
• Ryzyko/zgodność - kontrole sankcji/SOF w kontrowersyjnych scenariuszach.

• 1) "Refundacja. Utwórz '(API) walidacja → (limity, równowaga, polityka, KYC/SoF w razie potrzeby).
• 2. Менеравий idempotency_key („hash (payment_id + refund_amount + reason + nonce)”).
• 3. Połączenie PSP → „OCZEKUJĄCE”.
• 4. Webhook/sondaż → 'SUCCESS '/' FAILED'; kiedy timeout - przekłada się tym samym kluczem.
• 5. Publikacja wydarzenia w Kafce → Ledger, BI, wpisy.
• 6. Automatyczne pojednanie: mapowanie 'provider _ refund _ id' do rejestru.

5) Idempotencja i anty-bierze

Ten sam refand nie może być zapisany dwukrotnie: cała logika przez magazyn idempotencji (KV/Redis + TTL).
Klawisze na payment_id × ilość × powód (oraz, w razie potrzeby, „indeks _ częściowy”).
Retray używają tego samego klucza.
Częściowe równoległe są chronione za pomocą blokad poziomu wiersza/wersji optymistycznej na sumarycznych ilościach.

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) Model danych (minimum wystarczające)

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) Cechy dotyczące szyn płatniczych

Karty (Visa/Mastercard)

Obsługa pełna/częściowa; często nieco częściowe; TtR zależy od banku klienta (T + 1... T + 5 pb).
Webhaki o sukcesie przychodzą szybko, ale zapisanie się na zwolnienie może być późno → wyjaśniamy w szablonach wsparcia.

Bankowość A2A/Open/RTP

Często natychmiastowy zwrot (cofnięcie/push kredytu); niektórzy dostawcy obsługują tylko pełny lub 1 częściowy.
ścisłe powiązanie z oryginalnym kontem; wymagany jest zwrot do źródła.

Portfele elektroniczne

Normalny pełny/częściowy; TtR minut; częściowe i minimalne limity kwot.

Vouchery/Prepaid

Zazwyczaj polityka → nie jest dostępna dla zwrotu do źródła: powrót do portfela wewnętrznego lub ponowne wydanie vouchera (jeśli dostawca wie, jak). Wymaga klauzul zgodności.

Krypto

Szyny - lotne; najlepiej nie stosować jako metody refandu. Jeśli dozwolone: powrót do tego samego adresu/wymiany z udokumentowanym kursem i prowizją; Badanie AML.

8) Rachunkowość, pojednanie i finanse

Ledger: „DR Revenue/CR Cash” w momencie wychwytywania; na zwrot - pismo zwrotne. Częściowy odbija się proporcjonalnie.
Rozpoznawanie: w iGamingu refand zmniejsza GGR odpowiedniego okresu (zasady rachunkowości).
Pojednanie: dzienne uzgodnienia handlowca _ refund _ id provider_refund_id', statusy, kwoty, stawki FX.
FX: ustalić logikę kursów (w momencie przejęcia lub w momencie zwrotu), w stosownych przypadkach; Trzymaj siatkę rozprzestrzeniania.

9) KPI, cele i wpisy (zwrot zdrowia)

Stawka zwrotu = 'Refundowany _ Tx/ Captured_Tx'.
Współczynnik kwoty zwrotu = 'Refundowana _ Kwota/ Captured_Amount'.
TtR p95 = p95 ('credited _ at - created_at') metodą.
Stawka błędu zwrotu = 'Failed/Attempted' (<0. 3%).
Zwrot do źródła% ≥ 95% (jeśli jest dostępny).
Przypadki podwójnego zwrotu pieniędzy = 0.

• „TtR p95” jest wyższy niż SLO metodą P2 →.
• Kolce według „Stawki zwrotu” w jednym dostawcy/BIN → P1 (sprawdź chwyty/podwójne).
• Każdy 'Double Refund> 0' → P0 (natychmiastowe zamrażanie auto-refands).

10) plasterki 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 Kontrola bilansu dla części

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 wsparcie

Szablony wiadomości metodami: wyjaśniamy możliwe opóźnienie w rozładowaniu kart, A2A - niemal natychmiast.
Statusy w urzędzie: „Wydany → W procesie → Zwrócony”; Pokaż oczekiwaną datę naboru.
Przyczyny (reason_code) - czytelny dla człowieka: „Podwójne umorzenie”, „Anulowanie usługi”, „Częściowe odszkodowanie”.
Samoobsługa częściowy - bezpieczny tylko z limitami i jasnymi zasadami.

12) Ryzyko i zgodność

Przeciwdziałanie praniu: refand nie powinien przekształcać się w wyjście na alternatywny kanał; dopuszcza wyjątki z zatwierdzeniem MLRO.
Sankcje/REP: w przypadku zwrotów zainicjowanych na „czerwonych” rachunkach/szczegółach - obowiązkowa weryfikacja.
DSAR/Retention - Przechowywanie śladów refands w ramach polityki zatrzymywania.
Zasady lokalne: zasady i procedury dotyczące powrotów (na przykład przepisy dotyczące konsumentów) - odzwierciedlone w polityce.

13) Częste błędy i jak ich uniknąć

Podwójna refand z powodu braku idempotencji i powtarzających się haków → przechowywać klucz idem/status, sprawdź równowagę.
Częściowy> saldo → blokada wiersza/wersja optymistyczna i ścisłe kontrole.
Zwrot dokonywany metodą krzyżową bez zgody na zgodność → narusza zwrot do źródła.
Mieszanie nieważności i zwrotu w raportach → zniekształcenie KPI.
Nie ma automatycznych kontroli → czarne dziury między PSP i księgi.

14) Playbooks

Przepięcie dostawcy zwraca → sprawdź awarie autoryzacji/przechwytywanie duplikatów, włącz awarię, skontaktuj się z PSP.
Masowa częściowa kompensacja (kampania) → podnieść częściowy limit, umożliwić operacje grupowe i wzmocnić pojednanie.
Błąd webhooks → przełączyć się do sondażu, zwiększyć idempotencję TTL, odroczyć auto-refands.
Wyjątek od refundacji do źródła (rzadki) → eskalacja MLRO, udokumentowana wypłata oraz „comp _ approved = true”.

15) Skrzynki testowe (UAT/Prod)

1. Pełny zwrot pieniędzy po jednym przechwyceniu → poprawnie zresetuje saldo.
2. Partia częściowa (3 ×) → suma ≤ wychwytywanie; następnie pełna na resztę.
3. Idempotencja - Powtórz to samo zapytanie → 1 wynik.
4. Webhook-bounce: 3 identyczne powiadomienia → jeden odpis/kredyt.
5. Pojednanie: sztuczne niedopasowanie → alert i automatyczna korekta.
6. Ograniczenie praw: agent nie może przekroczyć częściowego limitu.
7. Odcięcie: późna próba refand → poprawna awaria i rejestrowanie.

16) Lista kontrolna wdrażania

• pełna/częściowa + polityka zwrotu do źródła według jurysdykcji/metody.
• Idempotence, retreats, webhooks and polling, DLQ.
• Model danych z pozostałością do zwrotu i reason_code.
• Księga i codzienne automatyczne pojednanie.
• KPI/deska rozdzielcza: stawka zwrotu, TtR, błąd, podwójny zwrot pieniędzy = 0.
• Prawa i matryca aplikacji, szablony wsparcia.
• Przypadki testów UAT i wpisy na poziomie produkcji.

Podsumowanie

Zarządzanie Refand jest ścisłą dyscypliną procesów: zwrotu do źródła, idempotencji, przejrzystego modelu danych, automatycznego pojednania i zrozumiałej częściowej/pełnej polityki. Dzięki takim podstawom, utrzymujesz niski poziom TtR, błędy bliskie zeru, duplikaty niemożliwe, a zgodność i finanse zsynchronizowane z celami biznesowymi.