Bizum Espagne : traductions instantanées

1) Contexte et positionnement Bizum

Bizum est un système de virement et de paiement instantané interbancaire espagnol intégré aux applications des banques locales. Fonctionne 24/7, couvre P2P (par numéro de téléphone), P2M (paiement en e-commerce/hors ligne), ainsi que les dons/donats et les factures à payer. La confirmation est effectuée dans l'annexe bancaire (SCA/PSD2), les fonds circulent sur les rails bancaires avec autorisation immédiate et crédit rapide.

• Adressez-vous par téléphone (alias), sans IBAN à UX.
• L'instantanéité et la finalité du virement (chargeback comme dans les cartes).
• P2M : paiement sur le site, dans l'application, hors ligne (QR/code Bizum).
• Request-to-Pay : « demander de l'argent » aux contacts ou aux clients.

2) Participants et rôles

Le schéma Bizum/pull interbancaire - règles, itinérance, catalogues des participants.
Banques émettrices - applications mobiles, SCA, antifrod et limites.
PSP/acquéreurs - connexion du merchant à Bizum P2M, API/SDK, rapports et calculs.
Merchant : Lance un paiement/demande, traite les statuts, effectue des retours et des rapprochements.
Payeur/bénéficiaire - confirme les transactions dans l'application de la banque.

3) Modes et scripts personnalisés

3. 1 P2P « par téléphone »

L'expéditeur sélectionne le contact (numéro de téléphone) → entre le montant → confirme dans son application bancaire → le destinataire voit un crédit instantané sur le compte.
Des seuils/dopages réduits sont possibles pour les nouveaux bénéficiaires. les contrôles.

3. 2 P2M (paiement au merchant)

E-commerce : le numéro de téléphone Bizum est entré sur la caisse, ou une application bancaire par depplink est ouverte ; la confirmation est push/SCA.
Офлайн/QR : dynamique QR per-order (la somme + orderId), le scanning dans l'application bancaire → la confirmation → le statut en ligne мерчанту.
Code Bizum : le merchant peut afficher un code/alias court à payer au point de vente.

3. 3 Request-to-Pay/Factures

Merchant produit une demande de paiement (montant/destination/durée) → le client confirme dans son application bancaire → les fonds sont crédités comme un virement Bizum normal.

3. 4 Donats et factures à payer

Les codes courts/alias pour la charité et les services publics/petits paiements sont maintenus.

4) Statuts

'initiated' → 'pending' (confirmation/réponse bancaire attendue) → 'success '/' failed '/' canceled '/' expired'.
Pour les requêtes, les états supplémentaires sont « requested »/« expired ».

5) Limites et politiques de risque

Il n'y a pas de plafond « ultra-rapide » unique : les limites sont fixées par les banques et/ou les PSP, souvent dépendantes du niveau KYC, de l'histoire et du canal.

Per-transaction, per-day/24h, parfois weekly/monthly.
Nouveau destinataire/merchant - seuils réduits, extrait ou confirmation.
Canal/script : limites séparées pour P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/device/géo-règles sur le côté de la banque.

6) Économie et commissions

Pour le merchant Bizum est généralement moins cher que la carte MDR, mais les conditions dépendent de PSP/banque.
Planifiez les coûts d'intégration/SDK, de traitement 'pending/expired', de support/ODR et de recon.

7) Retours et disputes

Chargeback (comme dans les cartes) est absent pour A2A. Retour - nouvelle opération de crédit du merchant au payeur (prise en charge des fonds partiels).
Les délais sont bancaires (souvent T + 0/T + 1).
Disputes/plaintes - par le biais des procédures PSP et la banque ; préparer les logs de commande, de confirmation et de communication avec le client.

8) Sécurité et conformité

PSD2/SCA dans l'application bancaire : PIN/biométrie, binding device, authentification risk-based de la banque.
Minimisation des PII : ne stockez que les attributs nécessaires (téléphone/refs), chiffrez les PII, limitez l'accès.
Webhooks : HMAC/nonce, protection contre le replay, journal d'audit et retraits.

9) Intégration du merchant

Options

1. Hosted/Embedded de PSP - démarrage rapide : formulaires Bizum, statuts, erreurs de la boîte.
2. Server-to-Server + App2App/QR est votre propre UX, QR dynamique per-order, gestion profonde des erreurs.
3. Pay-by-Link/Request-to-Pay - compte sur le lien (email/SMS/messager), confirmation auprès de la banque.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Idempotence ('orderId' + clé), rétroactions exponentielles, déduplication d'événements.
• Recon : daily auto-recon + périodique full-recon ; Stockage UTR/finn-références.
• SLA-dashboards : conversion, 'pending→success/expired', latence avant inscription.

10) Rapprochement et établissement de rapports

Loger : 'paymentId/transactionId', 'orderId', canal (P2P/P2M/QR/App2App/Request), banque du payeur, statut, montant/devise, timestamp, UTR/référence bancaire.
Par PSP : registres par inscription/retour/correction, mises à jour tardives des statuts.

11) Modèles UX

Mobile-first : pour mobile - App2App ; pour le desktop, le QR dynamique.
Erreurs transparentes : limite, délai, refus de SCA ; rediffusion sécurisée + alternative (carte/SEPA/autre A2A).
Reçu : montant, temps, 'transactionId', canal, UTR, contacts de support.
Durée de validité de la requête/QR : afficher le minuteur et le script de récupération.

12) Récurrence et mandats

Bizum de base est un-off avec SCA. Pour les abonnements, utilisez le lien : premier paiement Bizum → e-mandate/SEPA DD/Open-Banking pour les débits ultérieurs (limite/fréquence/notifications, écran de gestion de mandat).

13) Verticales à haut risque (y compris iGaming)

L'accessibilité/les limites dépendent de la politique des banques/PSP et du droit local.
Attendez-vous à des seuils réduits, des KYC renforcés, des hold's possibles.
Prévoyez des rails alternatifs (cartes, SEPA, autres DPI) et un routage intelligent selon les risques.

14) Architecture « Bizum Gateway »

Couche API (REST/GraphQL) pour la caisse et le backoffice.
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, jetons anti-replay.
Observability : métriques sur les canaux (App2App/QR/Request), 'pending→success/expired', temps jusqu'à settlement.

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

1. Signer le canal Bizum avec PSP/banque ; sélectionnez les canaux (App2App/QR/Request).
2. Implémentez 'createPayment '/' requestToPay', QR dynamique, écrans d'erreur/limites.
3. Connectez webhooks, idempotence, retraits et dedup d'événements.
4. Configurez recon (daily + full), stockage UTR/fin-références.
5. Soutenez les procédures partial/full refunds et ODR.
6. Lancez les SLA-dashboards et les alertes de conversion/latence.
7. Effectuez des tests e2e avec les banques/appareils principaux.

Carte de référence par limite

Per-txn/24h/7d : stocker dans un configh, vérifier avant le démarrage.
Nouveaux récipiendaires/merchants : seuils réduits/vitesse d'obturation.
Canaux : limites séparées pour P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/risque : l'antifrod de la banque peut légèrement rejeter/ralentir les opérations.

Résumé

Pour en ligne - App2App + QR dynamique, pour hors ligne - QR/code Bizum, pour les traductions - P2P par numéro.
Partagez la confirmation en ligne et le crédit final dans la logique ; construisez autour de webhooks + recon et refunds partiels.
Ne fixez pas les montants : maintenez les limites configues sur les banques/canaux et mettez à jour régulièrement.
Pour les abonnements, le premier Bizum → un mandat avec une gestion et des notifications transparentes.