Versicherer-Auszahlungen und Wallet

Wenn ein Levy Cover Schaden genehmigt und bezahlt wird, kommt das Geld vom Versicherer, nicht von Levy. Der Versicherer wahlt das Ziel (Karte, Bank, PayPal oder Levy-Wallet) basierend auf der Auswahl des Fahrers zur Schadenszeit. Diese Seite beschreibt, was fur jedes Ziel passiert - insbesondere der Levy-Wallet-Fall, der strikte Buchhaltungsregeln hat.

Auszahlungsziele

Der Versicherer unterstutzt vier Auszahlungsziele:

Fur die ersten drei erhalt Levy einen payout.completed-Webhook nur zur Sichtbarkeit - die Mittel gehen direkt vom Versicherer zum Fahrer, und Levys Hauptbuch ist nicht betroffen. Der Status auf insurance_claims bewegt sich zu paid und der Betreiber sieht ihn in der Schadensliste.

Der Levy-Wallet-Fall ist anders. Mittel fliessen vom Versicherer zu Levy, und Levy bucht eine Wallet-Gutschrift an den Fahrer. Diese Seite konzentriert sich auf diesen Fall.

Die Wallet-Auszahlungsregel

Warum die strikte Anforderung:

1. Audit. Jede Wallet-Gutschrift muss auf ein dokumentiertes Ereignis zuruckfuhrbar sein. Pramienruckerstattungen fuhren zu einer ride_refunds-Zeile; Schadensauszahlungen fuhren zu einer insurance_claims-Zeile. Beide Pfade erfordern, dass ihre Referenz existiert.
2. Missbrauchsschutz. Ohne die Schutzregel konnte ein falsch konfigurierter Cron, ein Tippfehler in einem Skript oder ein boswilliger Betreiber Wallet-Gutschriften erstellen, die als Versicherungsauszahlungen typisiert sind, aber keinem tatsachlichen Schaden entsprechen. Die DB-Ebenen-Durchsetzung verhindert dies.
3. Abrechnungsabstimmung. Levy stimmt Wallet-Auszahlungen monatlich gegen die Abrechnungsdatei des Versicherers ab. Diskrepanzen weisen auf falsch gebuchte Gutschriften hin und werden als Operations-Aufgaben hervorgehoben.

Wofur insurance_claim_payout da ist

wallet_transactions.reference_type = 'insurance_claim_payout' ist speziell fur vom Versicherer ausgegebene Schadensauszahlungen. Es ist nicht fur:

• Pramienruckerstattungen. Diese verweisen auf ride_refunds-Zeilen. Siehe Pramienruckerstattungen uber die Fahrt.
• Kulanz-Gutschriften. Diese haben ihren eigenen Referenztyp und sind ausdrucklich keine Versicherung.
• Betreiber-initiierte Wallet-Gutschriften, um einen Fahrer fur ein Off-Platform-Problem zu entschadigen.

Wenn Sie nach insurance_claim_payout greifen, aber keine genehmigte insurance_claims-Zeile mit status IN ('approved', 'paid') haben, ist die Gutschrift vom falschen Typ. Halten Sie an und wahlen Sie den richtigen Pfad.

Der Fluss fur eine wallet-bestimmte Auszahlung

1. Der Versicherer (Cover Genius) genehmigt den Schaden und der Fahrer hat Levy-Wallet als Ziel gewahlt.
2. Der Versicherer gibt einen payout.completed-Webhook aus mit:
   • claim_id passend zur Versicherer-Schadens-ID, gespeichert auf insurance_claims.carrier_claim_id
   • payout_amount und payout_currency
   • payout_destination = "levy_wallet"
3. Der Webhook-Handler in src/lib/insurance/webhook-handlers.ts:
   • Verifiziert die Signatur.
   • Sucht insurance_claims per carrier_claim_id. Wenn keine Zeile existiert, wird der Webhook abgelehnt (das ist die Schutzregel).
   • Fugt eine insurance_payouts-Zeile ein, die auf den Schaden verweist.
   • Ruft creditWalletForRefund mit reference_type = 'insurance_claim_payout' und reference_id = insurance_claims.id auf.
4. Der Wallet-Helper verifiziert, dass die insurance_claims-Zeile mit dem erwarteten Status existiert, und bucht die Gutschrift.
5. Der Fahrer erhalt eine Push-Benachrichtigung: "Ihre Levy Cover Auszahlung von X USD wurde Ihrem Wallet hinzugefugt."

Was rides.net_deposited NICHT macht

Schadensauszahlungen beruhren rides.net_deposited auf der zugrunde liegenden Fahrt nicht. Die Fahrt wurde bereits korrekt verbucht:

• Pramie wurde berechnet.
• Versicherer-Netto wurde beiseite gelegt.
• Levy- und Betreiber-Provisionen wurden erfasst.
• Die Fahrt ist abgeschlossen.

Die Schadensauszahlung ist ein nachgelagertes Versicherungsereignis. Es passiert, weil eine gultige Police ihre Aufgabe erfullt hat. Die ursprungliche Fahrt-Buchhaltung war korrekt und bleibt korrekt.

Dies ist das Gegenteil einer Pramienruckerstattung, die net_deposited beruhrt, weil die zugrunde liegende Fahrt eine Korrektur benotigt (die Pramie hatte nicht behalten werden sollen).

Vergleich nebeneinander

Die beiden Pfade sehen oberflachlich ahnlich aus - beide enden in einer Wallet-Gutschrift, die auf eine andere Zeile verweist - aber die Bedeutung und die nachgelagerte Buchhaltung sind vollig anders.

Fehlgeschlagene Wallet-Buchungen

Wenn die Wallet-Gutschrift fehlschlagt (z.B. das Fahrerkonto ist geschlossen):

1. Die insurance_payouts-Zeile wird mit wallet_transaction_id = NULL erstellt.
2. Das payout.completed-Ereignis wird in insurance_webhook_log mit processed_at IS NULL protokolliert.
3. Operations untersucht - typischerweise muss der Fahrer sich melden, um sich zu erholen, oder Levy meldet den Wallet-Pfad als nicht verfugbar, sodass der Versicherer an Karte/Bank umleitet.

Der Versicherer handhabt die Umleitung. Levy initiiert keine Ruckerstattung bei einer fehlgeschlagenen Auszahlung - diese Mittel gehoren dem Versicherer, der sie umleiten kann, nicht Levy, das sie ruckerstatten kann.

Levys Abrechnung mit dem Versicherer

Wallet-Auszahlungen werden fur den Fahrer sofort gebucht. Hinter den Kulissen rechnet Levy monatlich mit dem Versicherer uber das Abstimmungssystem des Versicherers (XPay fur Cover Genius) ab. Der Cashflow ist:

• Versicherer schuldet Levy: die Summe der wallet-bestimmten Auszahlungen im Monat.
• Levy schuldet dem Versicherer: die Summe der Versicherer-Netto-Pramien, die auf gebundenen Policen im Monat eingezogen wurden.
• Diese verrechnen sich, und Levy oder der Versicherer zahlt die Differenz.

Diese Abrechnung wird auf Plattform-Ebene gehandhabt; einzelne Unterkonten sehen nur die Pro-Schadens-Auszahlungsereignisse, nicht die Verrechnung.

---