TWINT Schweiz: QR und In-App

1) TWINT Kontext und Positionierung

TWINT ist ein Schweizer mobiles A2A-Zahlungssystem und eine Geldbörse, die in die Banken des Landes integriert ist. Der Nutzer zahlt aus der TWINT-App/Bank: online - über in-app/App2App oder Deep Link, offline - über QR (Standard „TWINT QR“). Die Bestätigung erfolgt in der App (SCA: PIN/Biometrie), das Geld wird vom zugehörigen Konto/Karte abgebucht und dem Händler per Bankkredit gutgeschrieben.

• Einheitliche Marke/QR für Online und POS, hohe Nutzerabdeckung.
• Sofortige Online-Bestätigung für UX und schnelle Einstellung (innerhalb der Bankfenster).
• P2P nach Telefonnummer/Kontakt innerhalb des Ökosystems.
• Geringe Belastung durch SCA und Gerätebindung.

2) Teilnehmer und Rollen

TWINT (Schema/Switch): Regeln, Teilnehmerverzeichnisse, Routing.
TWINT teilnehmende Banken/Emittenten: KYC, Limits und Betrugsbekämpfung.
PSPs/Acquirer: Verbinden Sie den Merchant (online/POS), stellen Sie APIs/SDKs, Web-Hooks und Berichte bereit.
Merchant: initiiert eine Zahlung/Anfrage, verarbeitet Status/Retouren, führt einen Abgleich durch.
Zahler: bestätigt Transaktionen in der TWINT/Bank-App.

3) Kanäle und benutzerdefinierte Skripte

3. 1 E-commerce: in-app / Deep Link / App2App

Auf dem Checkout erstellt der Merchant einen Zahlungsintent → gibt Deep Link/den Button „Pay TWINT“.
Die TWINT-App wird geöffnet (App2App), der Benutzer bestätigt → Rückkehr zur Kasse mit dem Status.
Für den Desktop wird ein dynamischer QR-Per-Order angezeigt; Kunde scannt in der App und bestätigt.

3. 2 POS/offline: TWINT QR

Dynamischer QR auf dem Kassen-/Terminalbildschirm: Summe, Bestellnummer, Metadaten.
Der Nutzer scannt → bestätigt in der App → der Merchant erhält einen Online-Status.
Der statische QR (Betrag wird manuell eingegeben) gilt für Spenden/kleinen Einzelhandel, ist aber schlechter im Abgleich.

3. 3 P2P „pro Telefon“

Überweisungen zwischen Einzelpersonen per Telefonnummer/Kontakt mit Push-Bestätigung und Sofortguthaben an den Empfänger.

3. 4 Request-to-Pay / Pay-by-Link

Der Merchant veranlasst eine Zahlungsaufforderung (Betrag/Termin/Frist) → der Kunde bestätigt in der App → die Zahlung erfolgt nach dem üblichen A2A-Flow.

4) Status und Timings

Typischer Status: „initiated“ → „pending“ → „success “/„ failed “/„ canceled “/„ expired“.
Berücksichtigen Sie bei QR/Desktop das Zeitlimit für die Bestätigung (Timer anzeigen).
Siedlung: Bankkredit T + 0/T + 1 in Abhängigkeit vom Abwicklungsfenster/PSP; für die Berichterstattung ist noch ein Tagesrecon Pflicht.

5) Grenzen und Risikorichtlinien

• Per-Transaktion, per-day/24h, manchmal wöchentlich/monatlich.
• Neuer Empfänger/Merchant - niedrigere Schwellenwerte und/oder Verschlusszeit.
• Kanalgrenzen: E-Commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Velocity/Device/Geo-Regeln werden von Banken und dem System angewendet.

6) Wirtschaft und Kommissionen

Für einen TWINT-Händler ist es in der Regel billiger als ein typischer Karts-MDR; Die Bedingungen unterscheiden sich bei der PSP (fix/low%).
Legen Sie die Kosten für Integration/SDK, 'pending/expired' -Verarbeitung, Support/OS und Abgleich fest.

7) Retouren und Dispute

Chargeback (wie in den Karten) fehlt. Rendite - neue Kredittransaktion vom Händler zum Zahler; Partielle Refunds werden unterstützt.
Die Rückgabefristen sind Bank (in der Regel T + 0/T + 1).
Streitigkeiten/Beschwerden - nach PSP/Bank-Verfahren; Speichern Sie die Protokolle der Bestellung, Bestätigung der Erbringung der Dienstleistung/Lieferung, Bündel von refund↔order.

8) Sicherheit und Compliance

SCA in der TWINT/Bank-App (PIN/Biometrie), Gerätebindung.
Betrugsbekämpfung bei der Bank/PSP: Velocity, neue Empfänger, Risiko-Scoring.
PII-Minimierung und Verschlüsselung, HMAC/Nonce auf Web-Hooks, Replay-Schutz, Audit-Protokoll.
Einhaltung lokaler Zahlungsdienstanforderungen und DSGVO-vergleichbarer Datenschutzbestimmungen.

9) Merchant-Integration

Varianten

1. Hosted/Embedded by PSP - Schnellstart, In-App/QR Out-of-the-Box, Status und Fehler.
2. Server-to-Server + Deep Link/QR - eigene UX, dynamische QR-per-Order, feine Fehlerbehandlung.
3. Pay-by-Link/Request-to-Pay - Rechnungsstellung per Link (E-Mail/SMS/Messenger).

• API: `createPayment`, `refund`, `requestToPay`, `webhook`, `reconcile`.
• Idempotenz ('orderId' + Schlüssel), exponentielle Retrays, Dedup von Ereignissen.
• Recon: täglicher Auto-Recon + periodischer Full-Recon; Bewahren Sie die UTR/Bankreferenz auf.
• SLA-Dashboards: Conversion, 'pending→success/expired', Zeit bis zur Anmeldung/Rückgabe.

10) Abstimmung und Berichterstattung

Loggen: 'paymentId/transactionId' des Anbieters, 'orderId', Kanal (App2App/QR/Link), Zahlerbank, Status, Betrag/Währung, timestamp, UTR.
Von PSP/Bank: Register der Einschreibungen/Retouren/Korrekturen, späte Statusaktualisierungen.
Richten Sie Alerts für Fehlsynchronisierungen und „hängende“ 'Pending' ein.

11) UX-Praktiken

Mobile-first: Mobil - in-app/App2App; auf dem Desktop gibt es einen großen dynamischen QR mit Timer.
Recovery: mit 'timeout/expired' - sichere Wiederholung und Alternative (Karte/SEPA/andere A2A).
Quittung: Betrag, Zeit, 'transactionId', Kanal, UTR, Saport Kontakte.
Risiko/Limits hervorheben: Zeigen Sie dem Benutzer, wer die Schwelle gesetzt hat - Bank oder Kanal.

12) Recurrent und Mandate

Basis TWINT - Ein-Aus mit SCA. Für Abonnements verwenden Sie ein Bündel: die erste Zahlung TWINT → e-mandate/SEPA DD/Open-Banking für zukünftige Belastungen (Limit/Periodizität/Benachrichtigungen).
Geben Sie dem Benutzer vor der Abbuchung einen Bildschirm für die Mandatsverwaltung (pause/cancel/update) und pre-notification.

13) Hochrisikovertikale (einschließlich iGaming)

Die Verfügbarkeit von Kanälen und Limits hängt von der Bank-/PSP-Richtlinie und dem lokalen Recht ab.
Erwarten Sie niedrigere Schwellen, verstärkt durch KYC, mögliche Halter.
Planen Sie alternative Schienen (Karten, SEPA, andere PIS) und Smart-Routing nach Risiko/Kanal/Bank.

14) „TWINT Gateway“ Architektur

API-Layer (REST/GraphQL) für Kasse und Backophis.
Ereigniswarteschlangen: Status-Events → Abrechnung/CRM/Analysen.
Sicherheit: Tresor für Geheimnisse, IP-allowlist PSP, strikte Validierung von redirect-URIs, Anti-Replay-Token.
Observability: Kanalkonvertierung (App2App/QR/Link), Anteil 'pending→expired', Zeit bis zur Einstellung/Rückgabe.

15) Checkliste Ausgabe in prod

1. TWINT an der PSP/Bank anschließen; Kanäle auswählen (App2App/QR/Link).
2. Implementieren Sie' createPayment '/' requestToPay', dynamische QR, Fehler/Limits Bildschirme.
3. Verbinden Sie Webhooks, Idempotenz, Retrays und Event-Dedup.
4. Richten Sie Recon (täglich + voll) ein, speichern Sie UTR/Fin-Referenzen.
5. Unterstützen Sie partielle/vollständige Refund- und ODR-Verfahren.
6. Führen Sie SLA-Dashboards und Konversions-/Latenz-/Hängestatusalerts aus.
7. Führen Sie e2e-Tests mit den wichtigsten Banken/Geräten und dem POS durch (falls relevant).

Landmark-Karte nach Limits

Per-txn/24h/7d: Speichern Sie in config und überprüfen Sie vor dem Start.
Neue Empfänger/Händler: niedrigere Schwellenwerte/Verschlusszeit.
Kanäle: separate Limits für E-Commerce (App2App/QR), POS, P2P, Request-to-Pay.
Velocity/Risiko: Die Betrugsbekämpfung der Bank kann Transaktionen sanft ablehnen/verlangsamen.

Zusammenfassung

Für Online - in-app/App2App + Dynamic QR, für den Einzelhandel - TWINT QR, für Transfers - P2P auf das Telefon.
Trennen Sie die Online-Bestätigung und die endgültige Gutschrift; bauen um webhooks + recon und partielle refunds.
Legen Sie keine Beträge fest: Führen Sie Limits über Banken/Kanäle hinweg und aktualisieren Sie sie regelmäßig.
Für Abonnements - Bündel erste TWINT → Mandat mit transparenter Verwaltung und Benachrichtigungen.