Swish Suécia: pagamentos mobil

1) O que é Swish

Swish é um sistema nacional sueco de pagamentos móveis A2A (operadora Getswish AB) com transferências instantâneas 24/7. O usuário confirma as operações via BankID (SCA). Os cenários P2P (por telefone), P2M para negócios (online e offline), donats e pagamentos são suportados.

• Endereço por número de telefone (ou número merchant/QR), sem IBAN em UX.
• Depósito instantâneo na conta bancária do destinatário; finalidade da transferência bancária.
• Baixa fricção: App2App/QR, confirmação em BankID.
• Ampla cobertura dos bancos e alta popularidade na tomada/online.

2) Papéis e produtos

Getswish - regras, diretórios e marcas.
Bancos participantes - Emitem/ligam Swish, aplicam limites e antifrode.
PSP/Equeiros - Conecta merchantes (Swish Handel/Swish Företag), fornece API/SDK, relatórios, senslement.

• Swish P2P - traduções entre indivíduos.
• Swish Företag - Aceitação de pagamentos offline (vitrine/POS).
• Swish Handel (Swish for e-commerce) é um chekout online (QR/App2App/Link).
• Swish Donations - números curtos/alisas para doações.
• Swish Payouts/Disbursents - pagamentos em massa (via banco/PSP).

3) Fluxos de pagamento

3. 1 P2P (push)

1. O remetente seleciona o contato por telefone → digita o valor/mensagem.
2. Confirma no BankID (Face/Touch/código).
3. O destinatário vê instantaneamente o crédito na conta e a notificação no aplicativo.

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

• App2App/Deplink: No checkout, abrimos o aplicativo Swish/BankID → confirmação → retorno ao merchant.
• QR per-order: é gerado QR dinâmico (soma, orderId, merchant reference); o cliente escaneia a câmera Swish → confirma no BankID.

3. 3 POS/offline (Företag)

QR dinâmico na caixa ou número Swish estático (soma manual).
Confirmação no BankID; o cheque é do Merchant e no aplicativo do cliente.

3. 4 Request-to-Raw/Inventos

Merchant envia um link de pagamento/solicitação (em email/SMS/serviço de mensagens); o cliente confirma no BankID.

3. 5 Pagamentos (Payouts)

O negócio envia uma transferência de dinheiro para o cliente por meio do banco/PSP; aplica-se o antifrode e os limites de saída.

4) Estatizações e timing

Estados típicos: 'iniciated' → 'pending' → 'sucess '/' failed '/' canceled '/' expired'.
Para o webcout, você pode atrasar a resposta do aplicativo/BankID → mantenha o tempo e a repetição de status (polling + webhooks).
Senslement para merchant - crédito bancário em tempo real/slot operacional mais próximo, dependendo do banco/PSP (ainda faça recon diurno para relatórios).

5) Limites e políticas de risco

• Per-transaction, per-day/24h; às vezes semana/monthly.
• Novo destinatário/novo merchant - liminares baixos/extrato.
• Limites de canal: P2P, e-commerce (App2App/QR), POS, payouts.
• Velocity/device/geo-regras e risco-escrutínio do lado do banco.

6) Economia e comissões

O custo para o merchant normalmente é inferior ao MDR clássico, mas as condições dependem do banco/PSP (fix/juro baixo, taxa de QR/SDK/relatórios).
Coloque os custos de suporte de 'pending/expired', display, recon e monitoramento de SLA.

7) Devoluções e displays (ODR)

A Marceback não está nos mapas. Reembolso - emprestando uma operação separadamente do merchant para o cliente (suportado por partial refunds).
Os prazos são bancários (geralmente T + 0/T + 1).
Displays - pelos procedimentos do banco/PSP: guarde os logs da encomenda, comprovante de serviço/entrega, conformidade com os adereços do cliente.

8) Segurança e conformidade

SCA via BankID, device binding, verificação SIM/dispositivo banco.
Minimização PII: guarde apenas os atributos necessários (telefone/árbitro), criptografe o PII; acesso pelo princípio do menor privilégio.
Webhooks: HMAC/nonce, protecção contra replay, tempo e eventos.
Conformidade com o PSD2/GDPR e os requisitos locais da Finansinspektionen.

9) Integração do merchant

Opções

1. Hosted/Embedded do PSP - início rápido, App2App/QR da caixa, estatais e erros.
2. O Server-to-Server + App2App/QR é um OX próprio, QR per-order dinâmico, processamento profundo de erros/repetições.
3. Pay-by-Link/Invoice - enviar um link/solicitação; conveniente para serviços e B2B.

• API: 'createPayment', 'refund', 'requestToPay' (se disponível no PSP), 'webhook', 'reconcile'.
• Idempotidade ('orderId' + chave), retraias exponenciais, eventos de dedução.
• Recon: daily auto-recon + full-recon periódico; armazenar UTR/anistia bancária.
• SLA-dashboards: conversão, 'pending→success/expired', latência antes da inscrição.

10) Confecção e relatórios

Logue «paymentId/transactionId» do provedor, «orderId», canal (App2App/QR/Link/POS), número do destinatário, status, soma/moeda, timestamp, UTR.
Do PSP/banco: registros de inscrição/devolução/correção, atualizações de status tardias.
Ative os alertas por rashincrons e anomalias (omissões duplas, pending «pending»).

11) Pattern UX

Mobile-first: auto-leitura do App2App; O desctop é um grande QR dinâmico com timer.
Erros transparentes: limite, falha de BankID, tempo; uma repetição segura e alternativa (cartão/SEPA/A2A de outro provedor).
Recibo: valor, hora, 'transactionId', canal, UTR, contatos de safort.
Tempo de ação para QR/solicitações e cenário de recuperação após expiração.

12) Recurrent e mandatos

O Swish básico é um one-off com SCA. O primeiro pagamento Swish-e-mandate/Auto-Pago/Open-Banking PIS (limite/periodicidade/notificação, tela de gerenciamento de mandato) é aplicado para assinaturas.

13) Vertical de alto risco (incluindo iGaming)

A disponibilidade dos canais e os limites dependem da política do banco/PSP e da lei local.
Espere por liminares reduzidos, KYC estendido e possíveis hold' s.
Planeje roteiros alternativos (mapas, SEPA, outros PIS) e smart-roting em risco/banco/canal.

14) Arquitetura «Swish Gateway»

Camada API (REST/GraphQL) para caixa e bacofis.
As filas de eventos são status → billing/CRM/analista.
Segurança: vault para segredos, IP-allowlist PSP, validação rigorosa de redirect-URI, token anti-replay.
Observabilidade: Conversão por canais (App2App/QR/POS/Link), participação 'pending→expired', tempo até o senslement/retorno.

15) Folha de cheque de saída em proda

1. Ligue PSP/banco com Swish Handel/Företag; alinhar tarifas/SLA e canais (App2App/QR/POS/Link).
2. Implemente 'createPayment' + QR dinâmico/App2App, telas de erro/limite.
3. Conecta webhooks, idempotação, retais e eventos.
4. Configure o recon (daily + full), armazenando UTR/arquivos finos.
5. Inclua partial/full refunds e procedimentos ODR.
6. Execute SLA-dashboards e alertas de conversão/latência/estatais pendentes.
7. Faça testes e2e com os principais bancos/dispositivos, POS (se relevante).

Cartão de referência de limites

Per-txn/24h/7d: armazenado no config e verificado antes do lançamento.
Novos destinatários/merchantes - liminares reduzidos/extrato.
Canais: limites individuais para P2P, e-commerce (App2App/QR), POS, payouts.
Velocity/risco: O antifrode do banco pode desaconselhar/retardar as transações.

Currículos

Para online - App2App + QR dinâmico, para offline - QR/POS (Företag), para traduções - P2P para telefone.
Compartilhe a confirmação online e o crédito final na lógica empresarial; construa em torno de webhooks + recon e refunds parcial.
Não fixe os valores: mantenha os configs de limites em bancos/canais com atualização regular.
Para assinaturas, o primeiro Swish conecta um mandato com gerenciamento transparente e notificações.