Swish Sweden: mobile payments

1) What is Swish

Swish is the national Swedish mobile A2A payment system (operator Getswish AB) with 24/7 instant transfers. The user confirms transactions through BankID (SCA). P2P scenarios (per phone), business P2M (online and offline), donations and payments are supported.

• Addressing by phone number (or merchant number/QR), without IBAN in UX.
• Instant credit to the recipient's bank account; finality of bank transfer.
• Low friction: App2App/QR, confirmation in BankID.
• Wide bank coverage and high popularity in retail/online.

2) Roles and products

Getswish (scheme) - rules, catalogs and brand.
Participating banks - issue/connect Swish, apply limits and anti-fraud.
PSP/acquirers - connect merchants (Swish Handel/Swish Företag), provide API/SDK, reports, settlement.

• Swish P2P - transfers between individuals.
• Swish Företag - accept payments offline (showcase/POS).
• Swish Handel (Swish for e-commerce) - online checkout (QR/App2App/Link).
• Swish Donations - short numbers/aliases for donations.
• Swish Payouts/Disbursements - mass payouts (via bank/PSP).

3) Payment flows

3. 1 P2P (push)

1. The sender selects the phone contact → enters the amount/message.
2. Confirms in BankID (Face/Touch/code).
3. The recipient instantly sees the credit on the account and the notification in the app.

3. 2 P2M: e-commerce (Swish Handel)

• App2App/Deeplink: on the check-out, open the Swish/BankID application → confirmation → return to the merchant.
• QR per-order: a dynamic QR (sum, orderId, merchant reference) is generated; the client scans with a Swish camera → confirms with BankID.

3. 3 POS/offline (Företag)

Dynamic QR at the checkout or static Swish number (manual amount).
Confirmation in BankID; check - at the merchant and in the client's application.

3. 4 Request-to-Rau/Invoices

Merchant sends a payment link/request (in email/SMS/messenger); the customer confirms in BankID.

3. 5 Payouts

The business sends the customer a money transfer to a telephone number through a bank/PSP; anti-fraud and outgoing limits are applied.

4) Statuses and timings

Typical statuses are 'initiated' → 'pending' → 'success '/' failed '/' cancelled '/' expired'.
For a web check, there may be delays in the response of the/BankID application → keep timeouts and status repetition (polling + webhooks).
Settlement for merchant - real-time bank loan/to the nearest operating slot depending on the bank/PSP (for reporting, do a daily recon anyway).

5) Limits and risk policies

• Per-transaction, per-day/24h; sometimes weekly/monthly.
• New receiver/new merchant - reduced thresholds/shutter speed.
• Channel limits: P2P, e-commerce (App2App/QR), POS, payouts.
• Velocity/device/geo-rules and risk scoring on the bank side.

6) Economics and commissions

The cost for the merchant is usually lower than the classic card MDR, but the conditions depend on the bank/PSP (fix/low interest, fee for QR/SDK/reports).
Charge for 'pending/expired' support, disputes, recon and SLA monitoring.

7) Returns and Disputes (ODR)

Chargeback as in cards is absent. Return - a separate credit transaction from the merchant to the client (partial refunds are supported).
Terms - bank (usually T + 0/T + 1).
Disputes - according to bank/PSP procedures: keep order logs, confirmation of service/delivery, compliance of customer details.

8) Safety and compliance

SCA via BankID, device binding, checking SIM/device by the bank.
PII minimization: store only the necessary attributes (phone/references), encrypt PII; access - according to the principle of least privileges.
Webhooks: HMAC/nonce, replay protection, timestamps and event dedup.
Compliance with Finansinspektionen PSD2/GDPR and local requirements.

9) Merchant integration

Options

1. Hosted/Embedded by PSP - fast start, App2App/QR out of the box, statuses and bugs.
2. Server-to-Server + App2App/QR - native UX, dynamic QR per-order, deep error/repetition processing.
3. Pay-by-Link/Invoice - sending a link/request; convenient for services and B2B.

• API: 'createPayment', 'refund', 'requestToPay' (if available from PSP), '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', latency before enrollment.

10) Reconciliation and Reporting

Log: 'paymentId/transactionId' of the provider, 'orderId', channel (App2App/QR/Link/POS), recipient number, status, amount/currency, timestamp, UTR.
From PSP/bank: registers of credits/returns/corrections, late status updates.
Include alerts for out-of-sync and anomalies (double write-offs, hanging 'pending').

11) UX patterns

Mobile-first: App2App auto-offer; on the desktop - a large dynamic QR with a timer.
Transparent errors: limit, BankID failure, timeout; safe repeat and alternative (card/SEPA/A2A of another provider).
Receipt: amount, time, 'transactionId', channel, UTR, support contacts.
Action timer for QR/requests and expiration recovery script.

12) Recurrence and mandates

Basic Swish - one-off with SCA. For subscriptions, a bundle is used: the first payment Swish → e-mandate/Autogiro/Open-Banking PIS for further debits (limit/frequency/notifications, ticket management screen).

13) High-risk verticals (including iGaming)

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

14) "Swish 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/POS/Link), fraction of 'pending→expired', time to settlement/return.

15) Output checklist

1. Connect the PSP/bank with Swish Handel/Företag; agree rates/SLAs and channels (App2App/QR/POS/Link).
2. Implement 'createPayment' + dynamic QR/App2App, error/limit screens.
3. Connect webhooks, idempotency, retrai and event dedup.
4. Set up recon (daily + full), UTR/fin references storage.
5. Enable 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, 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 P2P, e-commerce (App2App/QR), POS, payouts.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Resume Summary

For online - App2App + dynamic QR, for offline - QR/POS (Företag), for transfers - P2P to the phone.
Separate online confirmation and final credit in business logic; build around webhooks + recon and partial refunds.
Do not fix amounts: maintain limit configs by banks/channels with regular updating.
For subscriptions, the first Swish bundle → a ticket with transparent management and notifications.