Partielle und vollständige Refands

TL; DR

Ein Refand ist eine umgekehrte Operation für einen erfassten Betrag. Vollständig schließt die gesamte Transaktion, teilweise gibt einen Teil zurück (kann eine Reihe von partiell bis vollständig sein). Kritisch: Refund-to-Source, strikte Idempotenz, Ursachenjournalisierung und Orchestrierung mit Webhooks/Retrays. Wir messen Refund Rate, TtR p95, Refund Error und beseitigen Doubles/Inkonsistenzen durch Auto-Abstimmungen.

1) Begriffe und grundsätzliche Unterschiede

Full Refund - Rückgabe des gesamten festgeschriebenen Betrags ('refund _ amount = capture_amount').
Partial Refund - Rückgabe des Teils ('0 <refund_amount <capture_amount'), erlaubt den Rest partiell bis zur Summe' capture _ amount'.
Refund to Source - Rückkehr zur ursprünglichen Zahlungsmethode/-schiene (regulatorisch bevorzugt/vorgeschrieben).
Void - Stornierung bis zur Aufnahme (wenn durch Schienen unterstützt), gilt nicht als Refand.
Reversal/Chargeback - Bank/Rail Mechanik außerhalb Ihrer Initiative (Sporen, Chargebacks) - nicht zu verwechseln mit Reband.

2) Wenn die Ausgabe voll vs teilweise

• Stornierung der gesamten Bestellung/Dienstleistung, doppelte Belastung, Systemfehler.
• Obligatorisch bei fehlgeschlagener Erbringung der Dienstleistung (nach den Regeln des Verbrauchers/der Regulierungsbehörde).

• Teilweise Stornierung der Dienstleistung, proportionale Anpassungen (Rabatte, Verspätungsausgleich).
• Technische Grenzen Schiene (max. Betrag pro Betrieb) - Serie partiell.
• Post-Fact-Retention von Provisionen (wo regulatorisch erlaubt) - seltener in iGaming.

3) Richtlinien und Grenzen

Refund-to-source = true standardmäßig; Ausnahmen - über MLRO/Compliance-Fälle (protokolliert).
Cut-off: Refands sind N Tage ab Capture erlaubt (nach Methode/Gerichtsbarkeit).
Max Partial Count: nicht mehr als K partial pro Zahlung (typisch K ≤ 5).
Min Partial Amount: nicht unter dem technischen Minimum der Schiene/PSP.

• Agent sapport: partial ≤ X, full ≤ Y.
• Manager/Finanzen: über Grenzen, methodenübergreifende Ausnahmen.
• Cooling-off für wiederholte Versuche (Anti-Prasseln).

4) Architektur und Ereignisablauf

• Payment Orchestrator ist die Quelle der Statuswahrheit.
• Refund Service - API, Idempotenz, Orchestrierung von Retrays, Journaling.
• PSP Adapters - Integration nach Methoden.
• Reconciliation - Auto-Abstimmungen, DLQ, Korrekturen.
• Ledger/Accounting - Buchungen, Defer, Ausrichtung mit Clearing.
• Risiko/Compliance - Sanktionsprüfungen/SoF in umstrittenen Szenarien.

1. `Refund. Create'(API) → Validierung (Limits, Saldo, Richtlinien, KYC/SoF, falls erforderlich).

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

3. Der Aufruf der PSP → den Status „PENDING“.

4. Webhook/Polling → „SUCCESS “/„ FAILED“ bei Timeout - Retrays mit demselben Schlüssel.

5. Veröffentlichung der Veranstaltung in Kafka → Ledger, BI, Alert.

6. Auto-Abgleich: Zuordnung von 'provider _ refund _ id' zur Registry.

5) Idempotenz und Anti-Double

Derselbe Refand kann nicht zweimal gutgeschrieben werden: die ganze Logik über idempotency storage (KV/Redis + TTL).
Schlüssel auf payment_id × amount × reason (und, falls erforderlich, 'partial _ index').
Retrays verwenden den gleichen Schlüssel.
Parallele Partiale werden durch row-level locks/optimistic version auf Aggregate-Summen geschützt.

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) Datenmodell (minimal ausreichend)

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) Besonderheiten auf den Zahlungsschienen

Karten (Visa/Mastercard)

Unterstützt full/partial; oft etwas partiell; TtR hängt von der Bank des Kunden ab (T + 1... T + 5 Bd.).
Webhooks über den Erfolg kommen schnell, aber die Einschreibung auf der Entlastung kann sich verzögern → erklären wir in den Saport-Vorlagen.

A2A/Open Banking/RTP

Häufig sofortige Rückerstattung (reversal/credit push); einige Anbieter unterstützen nur full oder 1 partial.
Strikte Bindung an das Quellkonto; refund-to-source ist obligatorisch.

Elektronische Geldbörsen

Normal voll/teilweise; TtR in Minuten; Mengenbeschränkungen und Mindestbetrag.

Gutscheine/Prepaid

In der Regel refund-to-source ist nicht verfügbar → Politik: Rückkehr in die interne Brieftasche oder re-issue-Gutschein (wenn der Anbieter weiß, wie). Erfordert Compliance-Vorbehalte.

Krypto

Schienen - volatil; vorzugsweise nicht als Refandmethode eingesetzt werden. Wenn erlaubt: Rückgabe an die gleiche Adresse/Börse mit dokumentiertem Kurs und Gebühren; AML-Screening.

8) Buchhaltung, Abstimmung und Finanzen

Ledger: Buchungen „DR Revenue/CR Cash“ bei Erfassung; wenn refund - Rückbuchungen. Partial wird proportional reflektiert.
Anerkennung: Bei iGaming reduziert der Refand die GGR des jeweiligen Zeitraums (Rechnungslegungsgrundsätze).
Reconciliation: tägliche Abstimmungen 'merchant _ refund _ id ↔ provider_refund_id', Status, Beträge, FX-Kurse.
FX: Aufzeichnung der Kurslogik (zum Zeitpunkt der Erfassung oder zum Zeitpunkt des Refunds), falls zutreffend; Halten Sie das Gitter der Spreads.

9) KPIs, Ziele und Warnungen (Refund Health)

Refund Rate = 'Refunded _ Tx/ Captured_Tx' (segmentieren: aus Gründen).
Refund Amount Ratio = `Refunded_Amount / Captured_Amount`.
TtR p95 = p95 ('credited _ at - created_at') nach der Methode.
Refund Error Rate = `Failed / Attempted` (<0. 3%).
Refund-to-Source% ≥ 95% (wo verfügbar).
Double Refund Incidents = 0.

• „TtR p95“ über SLO nach Methode → P2.
• Spikes durch „Refund Rate“ in einem Anbieter/BIN → P1 (Check Grips/Takes).
• Jeder 'Double Refund> 0' → P0 (sofortiges Einfrieren von Auto-Refands).

10) SQL-Schnitte

10. 1 Refand-Profil

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 Rückstandskontrolle für partielle

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 und Sapport

Meldungsvorlagen nach Methode: Karten erklären die mögliche Verzögerung auf der Abrechnung, A2A fast augenblicklich.
Status im Büro: „Dekoriert → In Bearbeitung → Zurückgegeben“; das voraussichtliche Datum der Einschreibung.
Gründe (reason_code) - Menschen gelesen: „Doppelte Abschreibung“, „Stornierung der Dienstleistung“, „Teilentschädigung“.
Self-Service partial - sicher nur mit Grenzen und klaren Regeln.

12) Risiko und Compliance

Anti-Geldwäsche: Der Refand sollte nicht in eine Ausgabe auf einem alternativen Kanal umgewandelt werden; Ausnahmen mit MLRO-Zulassung erfassen.
Sanktionen/RER: Bei Retouren, die auf „rote“ Konten/Details initiiert werden - eine obligatorische Überprüfung.
DSAR/Retention: Speichern Sie Refand-Spuren als Teil Ihrer Datenspeicherungsrichtlinie.
Lokale Regeln: Zeitpunkt und Reihenfolge der Rücksendungen (z. B. Verbrauchervorschriften) - spiegeln sich in der Richtlinie wider.

13) Häufige Fehler und wie man sie vermeidet

Ein doppelter Refand aufgrund fehlender Idempotenz und wiederholter Webhooks → den Idem-Schlüssel/Status speichern, den Rest überprüfen.
Partial> Rest → row-lock/optimistic version und strenge Kontrollen.
Cross-Method Refund ohne Compliance-Genehmigung verstößt → gegen Refund-to-Source.
Die Vermischung von Void und Refund in Berichten → eine Verzerrung der KPIs.
Es gibt keine Autopfeifen → „schwarze Löcher“ zwischen der PSP und Ihrem Ledger.

14) Playbooks

Ein Anstieg der Retouren durch den Anbieter → die Überprüfung von Autorisierungsfehlern/Capture-Takes, die Aktivierung des Failovers und den Kontakt mit der PSP.
Massenpartialkompensation (Kampagne) → die partielle Grenze erhöhen, Gruppenoperationen einschließen, Abstimmungen verstärken.
Der Webhook-Fehler →, auf Polling umzuschalten, die TTL-Idempotenz zu erhöhen und Auto-Refands zu verschieben.
Refund-to-Source-Ausschluss (selten) → MLRO-Eskalation, dokumentierte Auszahlung und Markierung „comp _ approved = true“.

15) Testfälle (UAT/Prod)

1. Full Refund nach einem Capture → setzt den Rest korrekt auf Null.
2. Serie partial (3 ×) → Summe der ≤ Capture; dann voll auf den Rest.
3. Idempotenz: Wiederholung derselben Abfrage → 1 Ergebnis.
4. Webhook-Drepping: 3 identische Benachrichtigungen → eine Abbuchung/Einschreibung.
5. Abstimmungen: künstliche Mismatch → Alert und Autokorrektur.
6. Einschränkung der Rechte: Der Agent darf das partielle Limit nicht überschreiten.
7. Cut-off: Versuch eines späten Refands → korrekte Ablehnung und Protokollierung.

16) Checkliste zur Umsetzung

• Full/partial + refund-to-source Richtlinien nach Jurisdiktionen/Methoden.
• Idempotenz, Retrays, Webhooks und Polling, DLQ.
• Datenmodell mit Rückständen zu Return und reason_code.
• Ledger und tägliche Auto-Abstimmungen.
• KPI/Dashboard: Refund Rate, TtR, Error, Double Refund = 0.
• Rechte und Approve-Matrix, Sapport-Vorlagen.
• UAT-Testfälle und Prod-Level-Alerts.

Zusammenfassung

Refand Management ist eine strenge Disziplin der Prozesse: Refund-to-Source, Idempotenz, transparentes Datenmodell, Auto-Matching und verständliche Partial/Full-Policies. Mit solchen Grundlagen halten Sie die TtR niedrig, Fehler sind bei Null, Takes sind unmöglich und Compliance und Finanzen sind mit den Geschäftszielen synchronisiert.