Bancontact Belgique : cartes et A2A

1) Écosystème : Bancontact et Payconiq

Bancontact est le système national de paiement en espèces de Belga avec une forte composante de carte (cartes de débit, souvent co-badge avec Maestro/Debit Mastercard) et le support e-commerce/POS/NFC.
Payconiq by Bancontact est une couche de paiement A2A/mobile (QR/App2App/P2P « par téléphone ») largement utilisée en ligne et hors ligne.

• Deux rails : carte (card rails) et banque A2A (Payconiq).
• Marque unique à la caisse : le logo Bancontact/Payconiq est reconnaissable et familier à l'utilisateur.
• SCA/PSD2 : confirmation dans la banque/l'application, faible frod.
• Confirmations instantanées en ligne et calculs rapides (voir ci-dessous).

2) Rôles et participants

Circuit Bancontact/Payconiq : règles, certification, itinérance.
Issuer (banque du payeur) : émetteur de la carte et/ou compte Payconiq, limites et antifrod.
Acquirer/PSP : connecte le merchant (carte/A2A), donne API/SDK, rapports et calculs.
Merchant : initie le paiement, traite les statuts/retours, effectue un rapprochement.

3) Canaux et flow

3. 1 Carte Bancontact (POS/e-commerce/NFC)

POS/NFC : paiement de débit classique par terminal ; Autorisation hors ligne/en ligne sur les paramètres de l'émetteur.
E-commerce (CNP) : page d'accueil/widget PSP, confirmation par SCA (flow comme 3DS).
Co-badge : si une application internationale (Maestro/Debit MC) est disponible, le terminal/PSP sélectionne l'itinéraire.

3. 2 Payconiq (A2A: QR/App2App/Link)

QR per-order : Le merchant génère un QR dynamique (somme + orderId) ; l'utilisateur scanne l'application Payconiq/banque → confirme → le merchant obtient le statut en ligne.
App2App/Deeplink : à partir de l'application Web/Merchant, une application bancaire s'ouvre dès le paiement.
Pay-by-Link : facture/lien dans l'email/SMS/messager.
P2P « au téléphone » : traductions entre utilisateurs par numéro de contact.

3. 3 Scénarios hors ligne

QR statique (rarement pour les merchants) est une somme manuelle, pratique pour les donats/micropaiements.
SoftPOS : accepter les cartes/Payconiq sur les smartphones (où pris en charge).

4) Limites et comportement des banques

• Per-transaction/per-day/week pour la carte et séparément pour Payconiq.
• Nouveau destinataire/nouveau merchant - seuils réduits/vitesse d'obturation.
• Règles de canal/velocity : mobile vs web, géo/device, fréquence des opérations.
• P2P/QR/NFC peuvent avoir des microlimites distinctes.

5) Statuts et calculs

Cartes (Bancontact card)

Statut en ligne : 'autorisé/approuvé', 'declined', 'referred', 'timeout'.
Settlement : Généralement T + 1/T + 2 jours bancaires par l'intermédiaire de l'acquéreur ; des ajustements/inversements sont possibles.
Chargeback : disponible selon les règles des cartes (délais/codes, preuves).

Payconiq (A2A)

Statut en ligne : 'success', 'pending', 'failed', 'canceled', 'expired'.
Settlement : crédit bancaire rapide (souvent T + 0/T + 1, dépendant de la banque/PSP).
Il n'y a pas de chargeback : le retour est une nouvelle opération de crédit du merchant au payeur (soutenu par les partenaires).

6) Tarifs et économie

Rail de carte : fix/pourcentage MDR à l'acquéreur + 3DS/SCA frais de PSP.
Payconiq (A2A) : généralement en dessous des MDR de carte ; des frais de QR/widgets/reporting sont possibles.
Fixez le coût du support/ODR, travaillez avec 'pending/expired' et recon.

7) Retours et disputes

Carte : procédures de chargeback selon les règles de la carte ; stocker proof-of-delivery/services, journaux SCA.
A2A : il n'y a pas de chargback, faites refund (full/partial) comme une opération distincte ; T + 0/T + 1/T + 2 selon la banque.

8) Sécurité et conformité

PSD2/SCA en banque/annexe ; binding et antifrood de l'émetteur.
Minimisation PII, cryptage Web, HMAC/nonce, protection contre le replay, journal d'audit.
RGPD : transparence du stockage et de la suppression des données à la demande (DSAR).

9) Modèles UX

Routage intelligent : par défaut, proposez Payconiq (A2A) pour une faible commission ; fallback est une carte.
Mobile-first : avec le trafic mobile - App2App ; sur le bureau, QR/redirect.
Chèques : montant, date/heure, 'transactionId', canal (Card/Payconiq), UTR/reperence, contacts Sappport.
Idempotence : 'orderId' + clé, répétitions sécurisées pour les temporisations.
Récupération : dans 'pending/expired' - un bouton de répétition, une alternative à la méthode.

10) Intégration du merchant

Options

1. Hosted/Embedded by PSP (carte + Payconiq) : démarrage rapide, widgets prêts à l'emploi, statuts et erreurs.
2. Server-to-Server + Redirect/App2App/QR : contrôle UX complet, sélection de canal native, QR dynamique par ordre.
3. Pay-by-Link/Invoice : compte email/SMS/messager (en particulier pour les services B2V/).
4. POS/SoftPOS : Acceptez les cartes/NFC et Payconiq-QR au détail.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Webhooks (HMAC, Retrai, dedup), tableau d'idempotence.
• Recon : daily auto-recon + périodique full-recon ; Stockage UTR/finn-références.
• Dashboards SLA : conversion par canaux, 'pending→success/expired', latence à settlement.

11) Récurrence et mandats

Carte : débit tokénisé classique (tokens réseau/COF) avec SCA au premier paiement + MIT.
A2A : via e-mandate/SEPA DD/open-banking mandats : premier paiement → mandat pour les débits ultérieurs (limite/périodicité/notifications).

12) Verticales à haut risque (y compris iGaming)

En Belgique, la réglementation est stricte : la disponibilité des canaux et les limites dépendent de la PSP/banque et du droit local.
Attendez-vous à des limites réduites, un CUS/surveillance élargi, des hold's possibles.
Prévoyez des rails alternatifs (carte, SEPA, autres PIS) et un routage par profil de risque.

13) Architecture « Bancontact/Payconiq Gateway »

Couche API (REST/GraphQL) pour la caisse et le back-office.
Files d'attente d'événements : États-participants → facturation/CRM/analyse.
Sécurité : vault pour les secrets, IP-allowlist PSP, validation stricte de redirect-URI, anti-replay.
Fiabilité : rétroactions exponentielles, DLQ pour les statuts instables, idempotence.
Données : catalogues de banques/limites/codes d'erreur ; Journal ODR et carte des mandats.

14) Chèque-liste de sortie dans la prod

1. Sélectionnez un PSP compatible carte + Payconiq ; accepter les tarifs/SLA.
2. Implémentez 'createPayment' avec la sélection du canal App2App/QR pour mobile/offline.
3. Connectez les webhooks, les délais, les répétitions et l'idempotence.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Soutenir partial/full refunds, procédures ODR dans le saphport.
6. Incluez smart routing (A2A en priorité, carte en fallback), alertes de conversion/latence.
7. Couvrez avec e2e tests banques/plateformes mobiles/POS.

Carte de repères

Statuts de la carte : 'autorisé/approché', 'declined', 'timeout'.
Статусы A2A: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement : carte T + 1/T + 2, A2A souvent T + 0/T + 1.
Limites : per-txn/day/week ; pour les nouveaux bénéficiaires, des seuils réduits.
Récurrence : carte (COF/MIT) ou A2A via e-mandate/SEPA DD.

Résumé

Le moteur de la caisse est construit sur deux rails : un Payconiq-A2A à faible coût et une carte Bancontact comme un fallback universel.
Nous partageons la confirmation en ligne et le settlement dans la logique d'entreprise, incluons les partenaires partiels et un ODR clair.
Nous ne fixons pas les montants : nous maintenons les limites des banques/canaux et l'actualisation régulière.
Pour mobile - App2App/QR, pour le commerce de détail - NFC + QR dynamique, pour les abonnements - le premier paiement → le mandat.