Bargeldgutscheine und Handelsketten

1) Was es ist und wann es anzuwenden ist

Mit Bargutscheinen und eCash-Netzwerken können Sie Zahlungen ohne Bankkarten und IBAN akzeptieren. Der Nutzer kauft einen Prepaid-Gutschein (PIN) oder erhält einen Barcode/QR (Pay-at-Store) und bezahlt die Bestellung am Offline-Point des Partners (Kiosk, Supermarkt, Tankstelle, Post) oder bei der Internetbank/ATM. Das Geld geht an den Händler über PSP/Anbieter auf den Bankschienen; Es gibt keinen Charjback, die Betrugsrisiken sind minimal.

• Digitale Waren/Spiele, Inhalte, Abonnements mit niedrigem/mittlerem Check.
• Regionen mit hohem Bargeldanteil oder niedriger Kartendurchdringung.
• Zielgruppen, die Privatsphäre/Vorauszahlung bevorzugen.

2) Typologie der eCash-Tools

1. PIN-Gutscheine (Prepaid-Codes):

Beispiele: Paysafecard, Neosurf, Flexepin.
UX: Eingabe einer 16-/10-stelligen PIN auf dem Hosted-Formular oder Zahlung aus dem Wallet (myPaysafe/myNeosurf).
Besonderheiten: Teilabbuchungen, Kombination mehrerer PINs, Restbetrag wird gespeichert.

2. Barcodes/QR „Bezahlen im Laden“ (Barcode):

Beispiele: paysafecash, lokale Netzwerke (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - EU usw.).
UX: Der Merchant generiert einen Barcode/QR → der Kunde zahlt bar an der Kasse → der Anbieter sendet eine Bestätigung.
Besonderheiten: Der Scheck ist zeitlich begrenzt (expiry) gültig, der Betrag ist festgelegt.

3. Referenz/Slip für ATM/Online-Banking (Rechnungsdaten):

Beispiele: Multibanco Referenzen - PT, Konbini - JP.
UX: Code/Referenz + Betrag wird ausgegeben, Zahlung in ATM/Online-Bank/Partner-Shop.
Eigenschaften: Minimum von Betrug, strenger Abgleich nach Referenz.

3) Akteure des Ökosystems

Anbieter/Schema (eCash/Gutscheine): gibt PINs/Barcodes aus, führt Einzelhandelskataloge, KYC/AML, Betrugsbekämpfung, gibt APIs/Widgets.
PSP/Acquirer: Verbindet Merchant, Hosted-Kasse/SDK, Status, Web-Hooks, Register und Berechnungen.
Einzelhandel/Kasse: Bargeldannahme/Barcode-Auslesen, Synchronisation mit dem Anbieter.
Bank/Clearing: Abrechnung und Gutschrift an den Merchant.
Merchant: initiiert Zahlung/Rechnung, verarbeitet Status, Retouren und Recon.

4) Zahlungsströme

4. 1 PIN-Gutschein (gehostet/umgeleitet)

1. Checkout → Auswahl von eCash (z.B. Paysafecard/Neosurf).
2. Redirect/Hosted Anbieterformular → PIN-Eingabe/Wallet-Login → Bestätigung (SCA/Behavioral Scoring).
3. Return to merchant: „success/pending/failed/canceled/expired“.
4. Die tatsächliche Gutschrift erfolgt über Tagesregister (T + 1/T + 2).

4. 2 Barcode/QR „im Laden bezahlen“

1. Merchant erstellt eine Rechnung: Summe + Barcode/QR + Expiry.
2. Der Kunde geht zum Point of Sale und zahlt in bar → die Kasse bestätigt die Transaktion dem Anbieter.
3. Der Anbieter schickt dem Merchant einen Online-Erfolg, anschließend einen Kredit in den Registern (T + 0/T + 1).

4. 3 Referenz/Slip (ATM/Online-Banking/Conbini)

1. Referenzgenerierung (entity/reference/amount) + Gültigkeit.
2. Zahlung bei ATM/Online-Bank/Partner-Shop.
3. Der Online-Status von „paid“ und die anschließende Einstellung in den Registern.

5) Status und Berechnungen

Online-Status: "erstellt "/" ausstehend "/" Erfolg" bezahlt "/" fehlgeschlagen "/" storniert "/" abgelaufen ".
Siedlung: in der Regel T + 0/T + 2 Bankarbeitstage (per Vertrag/Kanal).
Trennen Sie in der Geschäftslogik die Online-Bestätigung und die tatsächliche Gutschrift.

6) Limits, KYC und Risiko

• Per-Transaktion, 24h/7d, Limit für PIN-Nummer pro Zahlung/Tag.
• Für neue Empfänger/Händler - reduzierte Schwellenwerte/Auszug.
• Geo-Regeln (Gutscheinland vs Kundenstandort/Merchant), Velocity, Device-Signale.
• Es gibt keinen Charjback; Disputationen - nach Anbieter ODR/PSP.
• Empfehlung: Halten Sie config Grenzen nach Land/Netzwerk/CUS und nicht hardcodieren Beträge.

7) Retouren und Teilabschreibungen

Refund = neue Kredittransaktion (in eCash Wallet/Banküberweisung - nach den Regeln des Anbieters).
Partielle Refunds werden in der Regel unterstützt.
Für PIN-Gutscheine stehen häufig Teilbelastungen und eine PIN-Kombination zur Verfügung; für Barcode-Rechnungen - der Betrag ist festgelegt.

8) Wirtschaft und Tarife

Die Provision für den Händler liegt in der Regel unter dem CNP-Kart-MDR, variiert jedoch in Geo/Volumen/Kategorie.
Zusätzliche Kosten: Hosted/SDK, Point-of-Sale-Werbung, Sapport/ODR, Verarbeitung von 'expired/pending', recon.

9) UX-Muster

PIN-Zahlung: klare Benutzeroberfläche für mehrere PINs und Saldo-Indikator; Fehlermeldungen: „falsch/verwendet“, „Limit überschritten“, „Region nicht unterstützt“.
Barcode/QR: großer Code + Ablauftimer, Buttons „ausdrucken/an Messenger/E-Mail senden“.
Offline-Zahlungsanweisungen: 3-4 Schritte mit den Logos der Netzwerke; Karte der nächstgelegenen Punkte/Öffnungszeiten.
Bestellstatus: „Wartet auf Zahlung“ mit Auto-Update; bei 'abgelaufen' die Schaltfläche' neuen Code erstellen'.
Quittung: Betrag, Zeit, 'paymentId', Kanal (PIN/Barcode/Reference), UTR/ref. aus dem Register, Sapport-Kontakte.
Lokalisierung: Währung/Sprache/Steuertexte, lokale Marken der Netzwerke.

10) Sicherheit und Compliance

PII-Minimierung: Die PIN/Wallet wird anbieterseitig eingegeben (Hosted/Widget).
Web-Hooks: HMAC/Nonce, Replay-Schutz, Ereignis-Dedup, Audit-Log.
KYC/AML/GDPR: Alters-/Grenzregeln für Prepaid-Gelder, Sanktions-/Geo-Beschränkungen.
Betrugsbekämpfung: Geräte-/Sitzungslimits, Cooling-Off, Step-Up, Überwachung von sich wiederholenden PINs/Barcodes.

11) Integration und Architektur

Verbindungsoptionen

1. Hosted/Embedded von PSP/Provider - schneller Start, minimale Verantwortung für sensible Daten.
2. Server-to-Server + Hosted - eigener Checkout mit Statuskontrolle, ohne PIN-Verarbeitung bei Ihnen.
3. Pay-by-Link/Rechnung - Referenzzahlungen und Sapport-Fälle.

Bekend-mindestens

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotenz ('orderId' + Schlüssel), exponentielle Retrays, DLQ, Dedup von Web-Hooks.
Verzeichnisse: Länder/Netzwerke/Limits/CUS-Ebenen, Fehlercodes, SLA-Metriken nach Kanal.
Observability: Conversion (PIN vs Barcode/Reference), Anteil 'pending→expired', durchschnittliche Timings vor Zahlung/settlement, Geo-Anomalien.

12) Geografische Hinweise (Landmarken)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Asien: Konbini (JP) und lokale Netzwerke (FamilyMart/Lawson/7-Eleven).

13) Checkliste Ausgabe in prod

1. Wählen Sie Anbieter/PSP und Zielnetze (PIN/Barcode/Referenz), vereinbaren Sie Tarife/SLA/settlement.
2. Implementieren Sie' createPayment 'createInvoice' mit expiry, Instruktionsseiten und Fallback-Skripten.
3. Verbinden Sie Webhooks (HMAC), Idempotenz, Retrays und Event-Dedup.
4. Konfigurieren Sie daily auto-recon + full-recon, speichern Sie die UTR/fin-Referenzen.
5. Aktivieren Sie partielle Refunds, ODR-Verfahren und verständliche Fehlermeldungen/Limits.
6. Führen Sie SLA-Dashboards (Conversion, 'expired', Time Before Payment/Settlement) und Alerts für Fehlsynchronisierungen aus.
7. Führen Sie e2e-Tests durch: mehrere PINs, überfälliger Barcode, falscher Betrag, doppelte Bezahlung, Rückerstattung in Raten.

Landmark-Karte

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Siedlung: normalerweise T + 0-T + 2 über PSP/Provider-Register.
Chargeback: nicht vorhanden; refund ist eine separate Kreditoperation.
Limits/CUS: abhängig von Land/Netzwerk/Kanal und Kundenprofil.
Recurrent: Erstes eCash → Mandat (SEPA/Open-Banking/lokal) für spätere Abschreibungen.

Zusammenfassung

Strategie: eCash-Mix (PIN + Barcode/QR + Referenz), um das Cash-Publikum zu erreichen und die MDR zu senken.
Architektur rund um Webhooks + Recon, strenge Idempotenz und verständliche UX 'pending/expired'.
Configy Limits/CUS und Geo-Regeln - außerhalb des Codes, mit regelmäßiger Aktualisierung.
Für Abonnements - das erste eCash → Mandat, transparente Verwaltung und Benachrichtigungen für den Benutzer.