Sofort/Klarna: pay-by-bank

1) O que é Sofort/Klarna Pay-by-Bank

Sofort (agora Klarna Pay Now/Pay-by-Bank) é uma ferramenta A2A que permite que o cliente pague diretamente a sua conta bancária através de um banco/aplicativo online. O fluxo é tipicamente construído sobre issuer-redirect/App2App, com confirmação por SCA (PSD2), enquanto o merchant recebe autorização online (sucess) e, em seguida, crédito bancário por relatórios/cálculos do provedor.

• Baixo custo em relação a MDR de cartão.
• Status on-line (êxito/não) quase imediatamente, com o depósito de fundos nem sempre momento (normalmente T + 1/T + 2).
• Geografia ampla na UE/EEE (especialmente a Alemanha/Áustria), suporte a dezenas de bancos emissores.
• O mínimo de adereços de pagamento do comprador é a escolha do banco e a confirmação.

2) Papéis e participantes

Klarna/Sofort (esquema/provedor): routing para bancos, estatais, relatórios, cálculos, devoluções.
Issuer (banco pagador): SCA, confirmação de cancelamento, limites/antifrode.
Merchant PSP/Aquirer: conexão de merchant, API/SDK, webhooks e recon.
Merchant (vendedor): iniciação do pagamento, processamento de estatais/reembolsos, acerto.

3) Fluxos de pagamento: Redirect e App2App

3. 1 Classic redirect

1. Checkout Merchant → a seleção «Pay by bank (Sofort/Klarna)».
2. Lista de bancos para banco online (ou para a página hosted do provedor) SCA.
3. O banco confirma o pagamento → o reembolso do Merchant (sucess/failed/canceled/pending).
4. Merchant registra o pedido como «pago/esperando», esperando pelo webhook/relatório de inscrição.

3. 2 App2App / Mobile

Em dispositivos móveis, o Merchant abre um aplicativo bancário deplink/intent → confirmação → retorno acima.
Conversão superior, fricção inferior; mantenha o fallback na web readt.

3. 3 Request-to-Pay/Embedded opções

Vários bancos estão disponíveis request-to-pay/PIS através de interfaces do provedor (o cliente acessa o banco-aplicativo).
Os widgets embedded do PSP simplificam a lista de bancos, erros e estatais.

4) Limites e comportamento dos bancos

• Por-transmissão, por-day/week junto ao banco de pagadores.
• Novos destinatários/merchantes - liminares reduzidos, pode ser suportado.
• Canais (mobyle/web), regras velocity, sinais geo/device.
• Em determinados países/bancos, pode haver liminares de isenção SCA (RA) - dependentes do banco.

5) Estatizações e inscrição (autorization vs masslement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
O pending pode ser verificado se a confirmação ou verificação assíncrona for atrasada.
Senslement: O crédito real vem de acordo com os relatórios do provedor (normalmente T + 1/T + 2 dias bancários; depende do país/banco/esquema de compensação).
Para serviços críticos, use o modelo de autorização ⇒ execução condicional antes de confirmar a inscrição.

6) Devoluções, retornos parciais e displicências

Não existe nenhuma Marceback (como em mapas). O reembolso é um novo empréstimo por meio do provedor ao pagador.
Suportados por partial refunds.
O prazo para a devolução é bancário (T + 1/T + 2).
Os displays/queixas seguem o procedimento ODR do provedor + através do banco pagador; prepare os logs da encomenda, proof-delivery/serviços.

7) Comissões e economia

Normalmente fix/baixa porcentagem com transação + taxa de função de plataforma (hosted checkout, relatórios, ODR).
Leve em conta os custos de suporte (pending/expirias), os incidentes de risco e os custos de operação recon.

8) Compilação e relatórios (reconciação)

Guarde 'paymentId/transactionId' do provedor, 'orderId', banco issuer, marcadores de tempo, estatais.
Inclua webhooks sobre alteração de status e auto-recon diário.
Combine os dados online (sucesso/pending) com os relatórios financeiros (inscrições/restituições/correções).
Guarde a anistia de UTR/banco do relatório de cada transação.

9) Práticas UX

Direy of banks: Prepare a última escolha, arrume a popularidade/lata do dispositivo.
Mobile-first: ofereça App2App, fallback - Web Readt.
Erros e repetição: dê razões claras (limite, falha SCA, timeout), botão de repetição e alternativas.
Idempotidade: 'orderId' + chave de idempotação para repetições seguras.
Recibo: valor, data/hora, 'transactionId', banco, canal (App2App/Redirect).

10) Débitos e mandatos recorrentes

Sofort clássico - one-off. Os modelos recorrentes usam o primeiro pagamento A2A-e-mandate/SEPA DD/Open Banking PIS para o futuro.
Gerencie os mandatos (limite, frequência, notificações) e mantenha os registros de aceitação.

11) Complaens, segurança, dados

PSD2/SCA: confirmação em banco, device binding, antifrode de banco.
PII Minimização: guarde apenas os atributos necessários; criptografar o PII; Assinaturas HMAC de ganchos na Web.
GDPR/Logs: consentimento, permissão de remoção, auditoria de alterações.

12) Vertical de alto risco (incluindo iGaming)

A disponibilidade do Pay-by-Bank para algumas categorias é restrita ao provedor/banco de políticas internas e ao direito local.
Esperem os limites reduzidos, mais COs/finmonitoring, possíveis hold' s.
Mantenha os roteiros alternativos (mapas, SEPA, open banking A2A, vouchers) e segmentação de tráfego.

13) Integração do merchant: opções

1. Hosted/Embedded от PSP/Klarna

Início rápido: widget de seleção de banco, estatais, erros, webhooks «da caixa».

2. Server-to-Server + redirect/App2App

Mais controle: página própria dos bancos, processamento fino de erros, QR/Deep Link.

3. Contas/Request-to-Pay

Enviar solicitação de pagamento (email/SMS/link), conveniente para B2V/serviços.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotidade e tabela dedupe por 'orderId'.
• Retraias por exposição para obter estatais, dead-letter para respostas instáveis.
• Diretórios: bancos/países, limites/códigos de erro, métricas SLA por issuer's.

14) Arquitetura «Sofort/Klarna Gateway»

API camada (REST/GraphQL) para caixa.
As filas de eventos são status → billing/CRM/analista.
Observabilidade: conversão em bancos/canais, 'pending→success/expired', latência, rejeição SCA.
Segurança: vault para segredos, provedor de IP-allowlist, tokens anti-replay, validação rigorosa de redict-URI.

15) Folha de cheque de saída em proda

1. Selecione o PSP/canal Klarna/Sofort com a geografia dos bancos desejada.
2. Implemente 'createPayment' + escolha do banco + redirect/App2App com fallback.
3. Ligue webhooks, idempotação, temporizações e repetição de estatais.
4. Configure o recon (daily + full), armazenando UTR/arquivos finos.
5. Inclua o parcial/full refunds e o regulamento ODR na safra.
6. Prepare cenários UX de falha/limite e métodos alternativos.
7. Teste bancos móveis (iOS/Android) e principais issuer's em países alvos.
8. Mantenha um guia de limites e uma página de status de incidentes.

Cartão de referência

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Senslement: mais frequente que T + 1/T + 2; planeje a «execução condicional» antes do empréstimo.
Limites: per-txn/day/week em issuer 'a; para os novos destinatários - abaixo.
Recurrent: via e-mandate/SEPA DD/Open Banking.

Currículo

Para conversão - App2App/Embedded, para sustentabilidade - webhooks claros + recon.
Compartilhe a confirmação online e o crédito real (T + 1/T + 2) na lógica do negócio.
Não fixe valores rígidos: configs de limite por banco/país + atualização regular.
Para subscrever, use o primeiro pagamento A2A → mandato, com controle UX compreensível e limites.