TWINT Switzerland: QR and in-app

1) TWINT context and positioning

TWINT is a Swiss mobile A2A payment scheme and wallet integrated with banks in the country. The user pays from the TWINT/bank application: online - via in-app/App2App or Deep Link, offline - via QR (standard "TWINT QR"). Confirmation is performed in the application (SCA: PIN/biometrics), funds are debited from the associated account/card and credited to the merchant by bank credit.

• Unified brand/QR for online and POS, high user reach.
• Instant online confirmation for UX and quick settlement (within bank windows).
• P2P by phone number/contact within the ecosystem.
• Low fraud due to SCA and device binding.

2) Members and roles

TWINT (schema/switch): rules, participant directories, routing.
TWINT member/issuer banks: KYC, limits and anti-fraud.
PSP/acquirers: connect merchant (online/POS), provide API/SDK, web hooks and reports.
Merchant: initiates a payment/request, processes statuses/returns, maintains reconciliation.
Payer: Confirms transactions in TWINT/bank application.

3) Channels and user scenarios

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

On the check, the merchant creates a payment intent → gives Deep Link/the "Pay TWINT" button.
The TWINT application opens (App2App), the user confirms → return to the cashier with the status.
A dynamic QR per-order is displayed for the desktop; the client scans in the application and confirms.

3. 2 POS/offline: TWINT QR

Dynamic QR on the cash register/terminal screen: amount, orderId, metadata.
The user scans → confirms in the application → the merchant receives an online status.
Static QR (the amount is entered manually) is applicable for donations/small retail, but worse for reconciliation.

3. 3 P2P "per phone"

Transfers between individuals by phone number/contact with push confirmation and instant credit to the recipient.

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

The merchant initiates a request for payment (amount/appointment/deadline) → the client confirms in the application → the payment goes through the usual A2A flow.

4) Statuses and timings

Typical statuses are 'initiated' → 'pending' → 'success '/' failed '/' cancelled '/' expired'.
For QR/desktop, consider the timeout for confirmation (show the timer).
Settlement: bank credit T + 0/T + 1 depending on the settlement window/PSP; a daily recon is still required for reporting.

5) Limits and risk policies

• Per-transaction, per-day/24h, sometimes weekly/monthly.
• New receiver/merchant - reduced thresholds and/or shutter speed.
• Channel limits: e-commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Velocity/device/geo-rules are applied by banks and the scheme.

6) Economics and commissions

For merchant, TWINT is usually cheaper than a typical card MDR; conditions differ between PSPs (fix/low%).
Charge for integration/SDK, pending/expired processing, support/ODR, and reconciliation.

7) Returns and disputes

Chargeback (as in cards) is missing. Return - new credit transaction from merchant to payer; partial refunds are supported.
Return dates are bank (usually T + 0/T + 1).
Disputes/complaints - according to PSP/bank procedures; keep order logs, confirmation of service/delivery, bundle of refund↔order.

8) Safety and compliance

SCA in TWINT/bank application (PIN/biometrics), device binding.
Antifraud at the bank/PSP: velocity, new recipients, risk scoring.
PII minimization and encryption, HMAC/nonce on web hooks, replay protection, audit log.
Meet local payment service requirements and GDPR-comparable data protection regulations.

9) Merchant integration

Options

1. Hosted/Embedded at PSP - fast start, in-app/QR out of the box, statuses and errors.
2. Server-to-Server + Deep Link/QR - native UX, dynamic QR per-order, fine error handling.
3. Pay-by-Link/Request-to-Pay - billing with a link (email/SMS/messenger).

• API: `createPayment`, `refund`, `requestToPay`, `webhook`, `reconcile`.
• Idempotence ('orderId' + key), exponential retrays, event dedup.
• Recon: daily auto-recon + periodic full-recon; Store UTR/bank reference.
• SLA dashboards: conversion, 'pending→success/expired', time to enrollment/return.

10) Reconciliation and Reporting

Log: 'paymentId/transactionId' of the provider, 'orderId', channel (App2App/QR/Link), payer bank, status, amount/currency, timestamp, UTR.
From PSP/bank: registers of credits/returns/corrections, late status updates.
Set up alerts for out-of-sync and "hanging" 'pending'.

11) UX practices

Mobile-first: on mobile - in-app/App2App; on the desktop - a large dynamic QR with a timer.
Recovery: with 'timeout/expired' - safe retry and alternative (card/SEPA/other A2A).
Receipt: amount, time, 'transactionId', channel, UTR, support contacts.
Highlighting risk/limits: show the user who set the threshold - bank or channel.

12) Recurrence and mandates

The basic TWINT is one-off with SCA. For subscriptions, a bundle is used: the first payment TWINT → e-mandate/SEPA DD/Open-Banking for future write-offs (limit/frequency/notifications).
Give the user a pause/cancel/update and pre-notification screen before writing off.

13) High-risk verticals (including iGaming)

Channel availability and limits depend on bank/PSP policy and local law.
Expect lowered thresholds, enhanced KYC, possible holds.
Plan alternative rails (cards, SEPA, other PIS) and smart-routing by risk/channel/bank.

14) TWINT Gateway architecture

API layer (REST/GraphQL) for cash register and backhoe.
Event queues: status events → billing/CRM/analytics.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay tokens.
Observability: channel conversion (App2App/QR/Link), fraction of 'pending→expired', time to settlement/return.

15) Output checklist

1. Connect TWINT at PSP/bank; select channels (App2App/QR/Link).
2. Implement 'createPayment '/' requestToPay', dynamic QR, error/limit screens.
3. Connect webhooks, idempotency, retrai and event dedup.
4. Set up recon (daily + full), UTR/fin references storage.
5. Support partial/full refunds and ODR procedures.
6. Run SLA dashboards and alerts for conversion/latency/hung statuses.
7. Perform e2e tests with main banks/devices and POS (if relevant).

Limit Reference Card

Per-txn/24h/7d: store in config and check before starting.
New recipients/merchants: lowered thresholds/shutter speed.
Channels: separate limits for e-commerce (App2App/QR), POS, P2P, Request-to-Pay.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Summary

For online - in-app/App2App + dynamic QR, for retail - TWINT QR, for transfers - P2P to the phone.
Separate online confirmation and final credit; build around webhooks + recon and partial refunds.
Do not fix the amounts: keep limit configs by bank/channel and update regularly.
For subscriptions, the first TWINT bundle → a ticket with transparent management and notifications.