Bancontact Belgium: maps and A2A

1) Ecosystem: Bancontact and Payconiq

Bancontact is a national Belgian cashless payment scheme with a strong card component (debit cards, often co-badge with Maestro/Debit Mastercard) and e-commerce/POS/NFC support.
Payconiq by Bancontact is an A2A/mobile payment layer (QR/App2App/P2P "on the phone"), widely used online and offline.

• Two rails: card (card rails) and bank A2A (Payconiq).
• Unified brand at the checkout: the Bancontact/Payconiq logo is recognizable and familiar to the user.
• SCA/PSD2: confirmation in the bank/application, low fraud.
• Instant online confirmations and quick settlements (see below).

2) Roles and participants

Bancontact/Payconiq scheme: rules, certification, routing.
Issuer (payer's bank): issuer of the card and/or Payconiq account, limits and anti-fraud.
Acquirer/PSP: connects merchant (card/A2A), gives API/SDK, reports and calculations.
Merchant: initiates payment, processes status/returns, reconciles.

3) Canals and flow

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

POS/NFC: Classic Terminal Debit Payment; offline/online authorization for issuer settings.
E-commerce (CNP): hosted page/PSP widget, SCA confirmation (3DS-like flow).
Co-badge: if there is an international application (Maestro/Debit MC), the terminal/PSP selects the route.

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

QR per-order: merchant generates dynamic QR (sum + orderId); the user scans the Payconiq/bank application → confirms → the merchant receives an online status.
App2App/Deeplink: a banking application is opened from the merchant's web/application immediately on payment.
Pay-by-Link: invoice/link in email/SMS/messenger.
P2P "to phone": transfers between users by contact number.

3. 3 Offline scenarios

Static QR (rarely for merchants) - the amount is manual, convenient for donations/micropayments.
SoftPOS: card acceptance/Payconiq on smartphones (where supported).

4) Limits and behavior of banks

• Per-transaction/per-day/week for the card and separately for Payconiq.
• New receiver/new merchant - reduced thresholds/shutter speed.
• Channel/velocity rules: mobile vs web, geo/device, frequency of operations.
• P2P/QR/NFC may have separate microlimits.

5) Statuses and calculations

Cards (Bancontact card)

Online status: 'authorized/approved', 'declined', 'referenced', 'timeout'.
Settlement: usually T + 1/T + 2 banking days through an acquirer; adjustments/reversals are possible.
Chargeback: available by card rules (terms/codes, evidence).

Payconiq (A2A)

Online status: 'success', 'pending', 'failed', 'cancelled', 'expired'.
Settlement: quick bank credit (often T + 0/T + 1, bank/PSP dependent).
Chargeback - return - new merchant credit transaction to payer (partial refunds supported).

6) Tariffs and economics

Kart rail: fixed/MDR percentage to acquirer + 3DS/SCA costs at PSP.
Payconiq (A2A): Typically below map MDRs; QR/widget/reporting fees are possible.
Put the cost of support/ODR, work with 'pending/expired' and recon.

7) Returns and disputes

Card: chargeback procedures according to card rules; store proof-of-delivery/services, SCA logs.
A2A: no chargeback, refund (full/partial) as a separate operation; terms T + 0/T + 1/T + 2 depending on the bank.

8) Safety and compliance

PSD2/SCA in the bank/application; device binding and issuer anti-fraud.
PII minimization, web hook encryption, HMAC/nonce, replay protection, audit log.
GDPR: storage transparency and on-demand deletion (DSAR).

9) UX patterns

Smart-routing: default to offering Payconiq (A2A) for low fees; fallback - map.
Mobile-first: with mobile traffic - App2App; on the desktop - QR/redirect.
Checks: amount, date/time, 'transactionId', channel (Card/Payconiq), UTR/reference, support contacts.
Idempotence: 'orderId' + key, safe repetitions during timeouts.
Recovery: with 'pending/expired' - one repeat button, an alternative to the method.

10) Merchant integration

Options

1. Hosted/Embedded by PSP (map + Payconiq): fast start, ready-made widgets, statuses and bugs.
2. Server-to-Server + Redirect/App2App/QR: full UX control, native channel selection, dynamic QR per-order.
3. Pay-by-Link/Invoice: email/SMS/messenger account (especially for B2B/services).
4. POS/SoftPOS: accepting cards/NFC and Payconiq-QR at retail.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Webhooks (HMAC, retrai, dedup), idempotency table.
• Recon: daily auto-recon + periodic full-recon; storage of UTR/fin references.
• SLA dashboards: channel conversion, 'pending→success/expired', latency to settlement.

11) Recurrence and mandates

Card: classic tokenized debit (network tokens/COF) with SCA on first payment + MIT.
A2A: through e-mandate/SEPA DD/open-banking mandates: first payment → mandate for subsequent debits (limit/frequency/notifications).

12) High-risk verticals (including iGaming)

Belgium has strict regulation: channel availability and limits depend on PSP/bank and local law.
Expect reduced limits, extended CCM/monitoring, possible holds.
Plan alternative rails (map, SEPA, other PIS) and routing along the risk profile.

13) Bancontact/Payconiq Gateway architecture

API layer (REST/GraphQL) for cash desk and back-office.
Event queues: status events → billing/CRM/analytics.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay.
Reliability: exponential retrai, DLQ for unstable statuses, idempotency.
Data: catalogs of banks/limits/error codes; ODR log and ticket map.

14) Output checklist

1. Select a PSP with card + Payconiq support; agree rates/SLAs.
2. Implement 'createPayment' with channel selection App2App/QR for mobile/offline.
3. Connect webhooks, timeouts, replays and idempotency.
4. Set up recon (daily + full), UTR/fin references storage.
5. Support partial/full refunds, ODR procedures in support.
6. Enable smart-routing (A2A priority, card - fallback), conversion/latency alerts.
7. Cover banks/mobile platforms/POS with e2e tests.

Landmark card

Card statuses: 'authorized/approved', 'declined', 'timeout'.
Статусы A2A: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: T + 1/T + 2 card, A2A often T + 0/T + 1.
Limits: per-txn/day/week; for new recipients - lowered thresholds.
Recurrence: Card (COF/MIT) or A2A via e-mandate/SEPA DD.

Summary

We build the cash register engine on two rails: a Payconiq-A2A for low cost and a Bancontact card as a universal fallback.
We separate online confirmation and settlement in business logic, include partial refunds and clear ODR.
We do not fix amounts: we support limit configs by banks/channels and regular updating.
For mobile - App2App/QR, for retail - NFC + dynamic QR, for subscriptions - the first payment → mandate.