iDEAL Holanda: pagamentos A2A

1) Contexto e posicionamento iDEAL

iDEAL é um esquema nacional de pagamentos em dinheiro A2A (conta-to-score) nos Países Baixos. O comprador paga a compra diretamente da sua conta bancária através do banco online/aplicativo móvel do banco emissor. O fluxo foi construído sobre issuer-redirect (redirecionamento para o banco) ou na abertura de um aplicativo bancário por deplink/App2App. Cálculo rápido, comissão para merchant inferior a MDR de cartão, finalidade como transferência de crédito bancário.

• Interoperabilidade via bancos emissores (ING, Rabobank, ABN AMRO, etc).
• SCA/PSD2 - confirmação em banco (PIN/biometria).
• Autorização instantânea (status sucess online) e crédito final através do equador/banco destinatário.
• Metadados ricos para comprimir (purchaseId/orderId, descrição, reference).

2) Papéis dos participantes

iDEAL (esquema) - regras, certificação, orientação aos bancos emissores.
Issuer (banco pagador) - Autenticação do cliente, confirmação do pagamento, status.
Acquirer/CPSP (Payment Service Provider) - Conexão de merchant, API/SDK, relatórios e cálculos.
Merchant - inicia o pagamento, recebe estatutos/fundos, faz reembolsos e acerto.

3) Opções de fluxo de pagamento

3. 1 Issuer-redirect (classic)

1. Checkout Merchant → uma seleção de banco do Issuer Diretoria.
2. Redirect ou App2App no banco → SCA → confirmação.
3. Retorno ao merchant com 'transactionId' e status (sucess/failed/canceled/open/expired).

3. 2 App2App / Embedded

Em dispositivos móveis, o Merchant abre uma aplicação bancária de deplink/intent (melhor UX, menos atrito).
Embedded/Hosted: O provedor fornece um widget pronto para a lista de bancos, gerenciamento de rediretos, processamento de erros.

3. 3 iDEAL QR (offline/online)

QR per-order dinâmico com soma embutida e reference; O comprador analisa a câmera do aplicativo bancário e confirma o pagamento.
QR estático (raro para merchantes; mais para P2P/donats) - o valor é digitado manualmente pelo usuário.

3. 4 Recurring/mandates

Modelo «first payment + e-mandate»: primeiro cancelamento por iDEAL com SCA explícito → criação de um mandato e-mail (geralmente leva a SEPA Direto Debit para os seguintes débitos dentro dos limites/periodicos acordados). Adequado para assinaturas.

4) Limites e políticas dos bancos

• Por transferência (no máximo, uma operação).
• Per-day/24h e semana (soma e/ou quantidade de transações).
• Novo beneficiário/novo merchant - pode ter liminares reduzidos e/ou extrato.
• Regras de canais/risco (celular vs desctop, velocity, geo/device).

Prática: Não invista números - mantenha o guia de limites dos bancos e mostre ao usuário o erro compreensível «ultrapassado o limite do banco» com alternativas (torção, outro método, repetir mais tarde).

5) Comissões e economia

• Taxas de provimento (gateway, widget, hosted checkout),
• custo de reembolso/transação do ODR,
• apoio e investigação de incidentes.

6) Estatais, cancelamentos, devoluções

Os estados de transação são 'sucess', 'open', 'failed', 'canceled', 'expired'.
Cancelamento antes da confirmação pelo cliente (no banco) ou pelo tempo expired.
Os Charjbacks não estão nos mapas. A devolução é um novo empréstimo de merchant para o pagador (refund) e pode haver devoluções parciais.
O prazo de retorno depende do PSP/banco; muitas vezes T + 0/T + 1 por transferência bancária.

7) Segurança e conformidade

SCA no banco emissor + device binding e política antifrod do lado do banco.
O nome/IBAN display de alguns emissores reduz o risco de misdirecção.
PSD2/DPR: PII minimizado, HMAC (HMAC), registo de auditoria.

8) Confecção e relatórios

Mantenha 'transactionId' (iDEAL), 'purchaseId '/' orderId', time, issuer, status final, UTR/anistia bancária dos relatórios PSP.
Configure o daily auto-recon e o full-recon periódico (translação, retornos, ajustes).
Os relatórios do PSP incluem opções de pedido de origem, estatais, atualizações tardias (por exemplo, 'open → sucess/expired'), movimentos de retorno.

9) Pattern UX

Diretory → Bank pick: Preencham e classifiquem os bancos em termos de popularidade/última escolha.
Mobile-first: ofereça automaticamente App2App, fallback - web-rerect.
Retry/recovery: Quando falhar, mostre uma repetição simples e métodos alternativos.
Idempotency: 'orderId' + chave de idempotação para repetições seguras.
Cheques: especifique o valor, data/hora, 'transactionId', reference, canal (QR/App2App/Redirect).

10) Débitos recorrentes via e-mandatos

O cenário «primeiro pagamento iDEAL → o mandato para futuros débitos» (normalmente através do SEPA Direto Debit).
O mandato fixa o limite per debit, a frequência, o direito de cancelamento.
A interface contém a tela de gerenciamento de mandatos (pause/cancel/update) e as notificações antes do cancelamento.

11) iDEAL e iGaming/categorias de alto risco

A disponibilidade de iDEAL para algumas verticais é restrita aos bancos/PSP sobre políticas de risco e direito local.
Para iGaming, espere: verificações mais rigorosas, limites reduzidos, complacência local obrigatória e OPR transparente/Refund-flow.
Planeje roteiros alternativos (mapas, SEPA, open-banking A2A) e segmentação de tráfego.

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

1. Hosted/Embedded iDEAL Checkout от PSP

Lançamento rápido, atualização automática da lista de bancos, estatais e erros.

2. Servidor-to-Server + Redirectos

Controle UX flexível: página própria de seleção de banco, geração QR, integração profunda no caixa.

3. iDEAL QR

Para POS/offline: QR per-order dinâmico com soma/rótulos, melhor para comprimidos e suporte.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotidade e tabela dedupe por 'orderId'.
• Webhooks com assinatura HMAC, retraí por exposição, pool-interrogação por degradação.
• Diretórios: bancos/limites/códigos de erro; Métricas SLA por emissor.

13) Esquema arquitetônico «iDEAL Gateway»

API camada: REST para caixa + integração com PSP/iDEAL API.
As filas de eventos são status → billing/CRM/analista.
Observabilidade: métricas de conversão em bancos/canais (Redirect/App2App/QR), participação 'open→expired', latência média até sucess.
Segurança: segredos em vault, IP-allowlist de PSP, protecção de URL de redireção, anti-replay de token.
Dados: registros de pagamentos/reembolsos, diário ODR, cartão de mandatos.

14) Folha de cheque de saída em proda

1. Selecione PSP/Equeyer com iDEAL (Hosted/Embedded/App2App/QR).
2. Implemente 'createPayment' + redirectos/Arr2Arr, tela de seleção de banco.
3. Inclua os ganchos da Web, a idempotação, os temporizadores e as repetições de estatais.
4. Configure recon (daily + full), descarga e alertas por raio.
5. Suporte a partial/full refunds e o regulamento do ODR na safra.
6. Adicione UX-fallback (métodos alternativos, repetição), cheque com 'transactionId'.
7. Teste o App2App/QR nos principais bancos (iOS/Android/desktop).
8. Prepare um guia de limites para bancos e uma página de status de incidentes.

Cartão de referência de limites

Per-txn/24h/7d: armazenamento em configh; verificar antes de iniciar o Redirect.
Novos beneficiários/merchants: limites iniciais reduzidos e/ou atrasos.
Canal: No App2App móvel, os limites/políticas de frod podem ser diferentes do Web.
Mandatos: limites/frequência definidos em um mandato (para cancelamentos recorrentes).

Currículo

Aposte no App2App/Embedded para conversão e no QR dinâmico para offline.
Mantenha os limites e as regras comportamentais para bancos.
O processo é construído em torno de webhooks + recon, estatais claras e refunds partidários.
Para assinaturas, primeiro pagamento iDEAL → mandato e; gerencie os limites e as notificações de forma transparente.