GH GambleHub

Bancontact Belgio: mappe e A2A

1) Ecosistema: Bancontact e Payconiq

Bancontact è uno schema nazionale Belga di pagamenti in contanti con forte componente cartuccia (carte di debito, spesso co-badge con Maestro/Debit Mastercard) e supporto e-commerce/POS/NFC.
Payconiq by Bancontact è uno strato A2A/pagamenti mobili (QR/App2App/P2P «per telefono») ampiamente utilizzato in linea e offline.

Proprietà chiave:
  • Due binari: carta (card rails) e banca A2A (Payconiq).
  • Unico marchio sulla cassa: il logo Bancontact/Payconiq è riconoscibile e familiare all'utente.
  • SCA/PSD2: conferma in banca/applicazione, basso frodo.
  • Conferma immediata in linea e calcoli rapidi (vedere sotto).

2) Ruoli e membri

Schema Bancontact/Payconiq: regole, certificazione, routing.
Issuer (banca pagatrice) è l'emittente della mappa e/o dell'account Payconiq, dei limiti e dell'antifrode.
Acquirer/PSP: connette il merchant (scheda/A2A), fornisce API/SDK, report e calcoli.
Merchant: avvia il pagamento, elabora gli stati/rimborsi, controlla.

3) Canali e flow

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

POS/NFC: Pagamento di debito terminale classico; autorizzazioni offline/online per le impostazioni dell'emittente.
E-commerce (CNP) - Pagina host/widget PSP, conferma su SCA (flow simile a 3DS).
Co-badge: con un'applicazione internazionale (Maestro/Debit MC), il terminale/PSP sceglie il percorso.

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

QR per-order: il merchant genera QR dinamico (somma + orderId); l'utente sta scannerizzando Payconiq/banca, confermando che il Merchant è online.
App2App/Deeplink - L'applicazione Web del Merchant apre l'applicazione bancaria direttamente al pagamento.
Pay-by-Link: fattura/collegamento in email/SMS/messaggistica.
P2P per telefono - Traduzioni tra utenti per numero di contatto.

3. 3 Script offline

QR statico (raramente per merchant) - somma manuale, comodo per donati/micropiatti.
SoftPOS: ricezione di carte/Payconiq su smartphone (dove supportato).

4) Limiti e comportamento delle banche

I limiti vengono impostati su emittenti (banca/applicazione) e PSP (payout/rischio):
  • Per-trasmissione/per-day/week-end per la mappa e separatamente per Payconiq.
  • Nuovo destinatario/nuovo merchant - soglie ridotte/estrazione.
  • Regole di canale/velocity: mobile vs web, geo/device, frequenza delle operazioni.
  • P2P/QR/NFC può avere microlimiti separati.
💡 Pratica: Non usare gli importi. Regolamento (CE) n. 152/2006 della Commissione

5) Stati e calcoli

Carte (Bancontact card)

Stato online: «authorized/approved», «declined», «referred», «timeout».
Settement: solitamente T + 1/T + 2 giorni bancari attraverso l'Equatore; possibili regolazioni/reverse.
Chargeback è disponibile secondo le regole delle carte (tempi/codici, prove).

Payconiq (A2A)

Stato online: «success», «pending», «failed», «canceled», «expired».
Settement: credito bancario rapido (spesso T + 0/T + 1, dipende dalla banca/PSP).
Nessun Proveback: restituzione - Nuova operazione Merchant al pagatore (supportata da partial refunds).

6) Tariffe ed economia

Rail di cartuccia: FIX/percentuale MDR all'equatore + 3DS/SCA spese PSP.
Payconiq (A2A) - Generalmente inferiore alle MDR cartucce; è possibile pagare per QR/widget/rapporti.
Fissare il costo del supporto/ODR, l'utilizzo dì pending/expired "e il recon.

7) Restituzioni e display

La mappa: procedure di marceback secondo le regole di cartello; memorizzare proof-delivery/servizi, registri SCA.
A2A: niente Charjback, rifund (full/partial) come operazione separata; tempo T + 0/T + 1/T + 2 a seconda della banca.

8) Sicurezza e compliance

PSD2/SCA in banca/applicazione; device binding e antifrode emittente.
PI-minimizzazione, crittografia del web hook, HMAC/nonce, protezione contro replay, registro di controllo.
GDPR: trasparenza di archiviazione e eliminazione dei dati su richiesta (DSAR).

9) pattern UX

Smart-routing: per default, proporre Payconiq (A2A) per una commissione bassa; fallback - mappa.
Mobile-first: con il traffico mobile - App2App; Il dectop è QR/redirect.
Assegni: importo, data/ora, 'transactionId', canale (Card/Payconiq), UTR/arbitro, contatti di zapport.
Idampotenza: «orderId» + chiave, ripetizioni sicure durante i timeout.
Recovery: «pending/expired» è un pulsante di ripetizione, un'alternativa al metodo.

10) Integrazione del merchant

Opzioni

1. Hosted/Embedded da PSP (scheda + Payconiq): avvio rapido, widget pronti, stati e errori.
2. Server-to-Server + Redirect/App2App/QR: controllo completo UX, scelta di canale personalizzata, QR dinamico per-order.
3. Pay-by-Link/Invoice: conto email/SMS/messaggistica (in particolare per B2V/servizi).
4. POS/SoftPOS: ricezione di carte/NFC e Payconiq-QR nella presa.

Componenti di backend obbligatori:
  • API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
  • Webhooks (HMAC, Retrai, Deadup), tabella Idempotent.
  • Recon: daily auto-recon + full-recon periodico; memorizzazione delle istruzioni UTR/fine.
  • Dashboard SLA: conversione via canale, 'pending→success/expired', latitanza a settlement.

11) Recurrent e mandati

La mappa è la classica carta di credito (network tokens/COF) con SCA al primo pagamento + MIT.
A2A: tramite e-mandate/SEPA DD/open banking mandati: il primo pagamento → il mandato per i prelievi successivi (limite/periodicità/notifica).

12) Verticale ad alto rischio (comprese le iGaming)

Il Belgio ha una regolamentazione rigorosa: la disponibilità dei canali e i limiti dipendono da PSP/banca e diritto locale.
Attenersi limiti ridotti, COS/monitoraggio avanzato, possibili hold's.
Pianificare binari alternativi (mappa, SEPA, altri PIS) e routing su un profilo di rischio.

13) Architettura «Bancontact/Payconiq Gateway»

Livello API (REST/GraphQL) per la cassa e il back-office.
Le code di eventi sono States-Ivent-Billing/CRM/Analista.
Sicurezza: vault per i segreti, IP-allowlist PSP, convalida rigorosa redict-URI, anti-replay.
Affidabilità: retrai esponenziali, DLQ per gli stati instabili, idempotia.
Dati: cataloghi di banche/limiti/codici di errore; il registro ODR e la mappa dei mandati.

14) Assegno foglio di output

1. Selezionare un PSP con supporto per la scheda + Payconiq; concordare tariffe/SLA.
2. Implementare «createPayment» con un canale, App2App/QR per il mobile/offline.
3. Collegare webhooks, timeout, ripetizioni e idempotenza.
4. Configura il recon (daily + full), memorizza le istruzioni UTR/fine.
5. Supportare partial/full refunds, procedure ODR nello zappino.
6. Abilita lo smart-routing (A2A prioritario, la mappa fallback), gli alert di conversione/latenza.
7. Coprire i test e2e banche/piattaforme mobili/POS.

Scheda di riferimento

💡 Vette reali/ETA - in banca/PSP e canale.

States mappa: «authorized/approved», «declined», «timeout».
Статусы A2A: `success`, `pending`, `failed`, `canceled`, `expired`.
Settement: mappa T + 1/T + 2, A2A spesso T + 0/T + 1.
Limiti: per-txn/day/week; per i nuovi destinatari - soglie ridotte.
Recurrent: mappa (COF/MIT) o A2A tramite e-mandate/SEPA DD.

Riepilogo

Il motore di cassa è costruito su due binari: Payconiq-A2A per il basso costo e la carta Bancontact come fallback universale.
Condividiamo la conferma online e il settement nella logica aziendale, includendo partial refunds e un chiaro ODR.
Non fissiamo gli importi, manteniamo i limiti di configura per banche/canali e aggiornamenti regolari.
Per il mobile - App2App/QR, per la presa - NFC + QR dinamico, per le sottoscrizioni - il primo pagamento è un mandato.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.