TWINT Szwajcaria: QR i in-app

1) kontekst TWINT i pozycjonowanie

TWINT to szwajcarski system płatności mobilnych A2A i portfel zintegrowany z bankami w kraju. Użytkownik płaci z aplikacji TWINT/bank: online - za pośrednictwem in-app/App2App lub Deep Link, offline - za pośrednictwem QR (standard „TWINT QR”). Potwierdzenie jest wykonywane w aplikacji (SCA: PIN/biometria), środki są obciążane z powiązanego konta/karty i przekazywane handlowcowi przez kredyt bankowy.

• Ujednolicona marka/QR dla online i POS, wysoki zasięg użytkownika.
• Natychmiastowe potwierdzenie online dla UX i szybkie rozliczenie (w oknach bankowych).
• P2P przez numer telefonu/kontakt w ekosystemie.
• Niskie oszustwa ze względu na SCA i wiążące urządzenie.

2) Członkowie i role

TWINT (schemat/przełącznik): zasady, katalogi uczestników, routing.
Banki członkowskie/emitentów TWINT: KYC, limity i zwalczanie nadużyć finansowych.
PSP/acquirers: connect merchant (online/POS), provide API/SDK, web haki i raporty.
Handlowiec: inicjuje płatność/żądanie, przetwarza statusy/zwraca, utrzymuje uzgodnienie.
Płatnik: Potwierdza transakcje w aplikacji TWINT/bank.

3) Kanały i scenariusze użytkownika

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

Na czeku handlowiec tworzy zamiar płatności → daje Deep Link/przycisk „Pay TWINT”.
Aplikacja TWINT otwiera (App2App), użytkownik potwierdza → powrót do kasjera ze statusem.
Dla pulpitu wyświetlany jest dynamiczny QR na zamówienie; klient skanuje w aplikacji i potwierdza.

3. 2 POS/offline: TWINT QR

Dynamiczny QR na ekranie kasy/terminala: kwota, „ Id”, metadane.
Użytkownik skanuje → potwierdza w aplikacji → handlowiec otrzymuje status online.
Statyczny QR (kwota jest wprowadzana ręcznie) ma zastosowanie do darowizn/małych detalicznych, ale gorzej dla pojednania.

3. 3 P2P „na telefon”

Przelewy między osobami przez numer telefonu/kontakt z potwierdzeniem push i natychmiastowym kredytem do odbiorcy.

3. 4 Żądanie zapłaty/płatne połączenie

Handlowiec inicjuje wniosek o płatność (kwota/umówienie/termin) → klient potwierdza we wniosku → płatność przechodzi przez zwykły przepływ A2A.

4) Statusy i terminy

Typowe statusy są 'zainicjowane' → 'w oczekiwaniu' → 'sukces '/' nieudany '/' anulowany '/' wygasł'.
W przypadku QR/pulpitu należy rozważyć termin potwierdzenia (pokaż timer).
Rozrachunek: kredyt bankowy T + 0/T + 1 w zależności od okna rozliczeniowego/PSP; dzienny zwiad jest nadal wymagany do sprawozdawczości.

5) Limity i polityka ryzyka

• Na transakcję, dziennie/24h, czasami tygodniowo/miesięcznie.
• Nowy odbiornik/handlowiec - obniżone progi i/lub prędkość migawki.
• Limity kanałów: e-commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Zasady prędkości/urządzenia/geo-reguły są stosowane przez banki i system.

6) Ekonomia i prowizje

Dla handlowca TWINT jest zwykle tańszy niż typowy MDR karty; warunki różnią się między PSP (fix/low%).
Opłata za integrację/SDK, oczekujące/wygasłe przetwarzanie, wsparcie/ODR i pojednanie.

7) Zwroty i spory

Brak obciążenia zwrotnego (jak w kartach). Zwrot - nowa transakcja kredytowa od handlowca do płatnika; wspierane są częściowe refundacje.
Terminy zwrotu to bank (zwykle T + 0/T + 1).
Spory/reklamacje - zgodnie z procedurami PSP/bankowymi; przechowywanie dzienników zamówienia, potwierdzenie usługi/dostawy, pakiet zwrotów.

8) Bezpieczeństwo i zgodność

SCA w aplikacji TWINT/bank (PIN/biometria), wiązanie urządzenia.
Antyfraud w banku/PSP: prędkość, nowi odbiorcy, ocena ryzyka.
Minimalizacja i szyfrowanie PII, HMAC/nonce na hakach internetowych, ochrona przed powtórzeniem, dziennik audytu.
Spełniają lokalne wymagania dotyczące usług płatniczych oraz porównywalne z RODO przepisy o ochronie danych.

9) Integracja handlowców

Opcje

1. Hosted/Embedded at PSP - szybki start, in-app/QR poza pudełkiem, statusy i błędy.
2. Server-to-Server + Deep Link/QR - natywny UX, dynamiczny QR na zamówienie, drobna obsługa błędów.
3. Pay-by-Link/Request-to-Pay - rozliczenie za pomocą linku (e-mail/SMS/messenger).

• API: „Z płatnością”, „z refundacją”, „z ToPay”, „z hakiem internetowym”, „z pogodzeniem”.
• Idempotencja (klucz ' Id' +), przekładnie wykładnicze, dedup zdarzeń.
• Recon: dzienny auto-recon + okresowy pełny zwiad; Przechowywać UTR/referencje bankowe.
• Deski rozdzielcze SLA: konwersja, 'w oczekiwaniu → sukces/wygasł', czas na zapisanie/powrót.

10) Pojednanie i sprawozdawczość

Dziennik: 'Id/ Id' dostawcy,' Id', kanał (App2App/QR/Link), bank płatnika, status, kwota/waluta, znacznik czasu, UTR.
Z PSP/banku: rejestry kredytów/zwrotów/korekt, późne aktualizacje stanu.
Skonfiguruj wpisy do „pozasynchronizowanych” i „wiszących” „oczekujących”.

11) Praktyki UX

Mobile-first: na telefon komórkowy - in-app/App2App; na pulpicie - duży dynamiczny QR z zegarem.
Odzyskiwanie: z „timeout/expired” - bezpieczny powtórny i alternatywny (card/SEPA/other A2A).
Odbiór: ilość, czas, ' Id', kanał, UTR, kontakty wsparcia.
Podkreślanie ryzyka/limitów: pokaż użytkownika, który ustawił próg - bank lub kanał.

12) Powtarzanie i mandaty

Podstawowy TWINT jest jednorazowy z SCA. W przypadku subskrypcji stosuje się pakiet: pierwsza płatność TWINT → e-mandat/SEPA DD/Open-Banking dla przyszłych odpisów (limit/frequency/notifications).
Daj użytkownikowi wstrzymanie/anulowanie/aktualizację i ekran przed powiadomieniem przed odpisaniem.

13) Piony wysokiego ryzyka (w tym iGaming)

Dostępność kanałów i limity zależą od polityki banku/PSP i prawa lokalnego.
Oczekiwać obniżonych progów, wzmocniony KYC, możliwe uchwyty.
Planuj alternatywne szyny (karty, SEPA, inne PIS) i inteligentne trasy przez ryzyko/kanał/bank.

14) Architektura bramy TWINT

warstwa API (REST/GraphQL) do kasy i koparki.
Kolejki wydarzeń: zdarzenia stanu → rozliczenie/CRM/analityka.
Bezpieczeństwo: skarbiec dla tajemnic, IP-permlist PSP, ścisłe przekierowanie-walidacja URI, żetony anty-replay.
Obserwowalność: konwersja kanału (App2App/QR/Link), ułamek 'oczekujących → wygasła', czas do rozliczenia/zwrotu.

15) Lista kontrolna wyjściowa

1. Podłącz TWINT w PSP/banku; wybierz kanały (App2App/QR/Link).
2. Implementacja ekranów dynamicznych QR, błędów/limitów.
3. Podłącz haki internetowe, idempotencję, retrai i event dedup.
4. Skonfigurować recon (dziennie + pełny), UTR/fin referencje przechowywania.
5. Wsparcie częściowych/pełnych refundacji i procedur ODR.
6. Uruchom deski rozdzielcze SLA i wpisy do statusów konwersji/opóźnienia/zawieszenia.
7. Przeprowadzanie testów e2e z głównymi bankami/urządzeniami i POS (w stosownych przypadkach).

Karta referencyjna limitu

Per-txn/24h/7d: przechowywać w konfiguracji i sprawdzać przed rozpoczęciem.
Nowi odbiorcy/handlowcy: obniżone progi/prędkość migawki.
Kanały: oddzielne limity dla handlu elektronicznego (App2App/QR), POS, P2P, Request-to-Pay.
Prędkość/ryzyko: Bank może delikatnie odchylić/spowolnić operacje.

Podsumowanie

Dla online - in-app/App2App + dynamiczne QR, dla detalicznych - TWINT QR, dla transferów - P2P do telefonu.
Oddzielne potwierdzenie online i kredyt końcowy; zbudować wokół webhooks + recon i częściowe zwroty.
Nie ustalaj kwot: zachowaj konfiguracje limitu przez bank/kanał i regularnie aktualizuj.
W przypadku subskrypcji, pierwszy pakiet TWINT → bilet z przejrzystym zarządzaniem i powiadomieniami.