Bons en espèces et réseaux de détail

1) Qu'est-ce que c'est et quand appliquer

Les bons en espèces et les réseaux eCash vous permettent d'accepter le paiement sans carte bancaire et IBAN. L'utilisateur achète un bon prépayé (PIN) ou reçoit un code à barres/QR (pay-at-store) et paie la commande au point hors ligne du partenaire (kiosque, supermarché, AZS, bureau de poste) ou à la banque en ligne/ATM. L'argent est envoyé au merchant par l'intermédiaire du PSP/fournisseur sur les rails bancaires ; il n'y a pas de charjback, les risques de frod sont minimes.

• Produits numériques/jeux, contenu, abonnements par chèque faible/moyen.
• Régions avec une part élevée d'argent ou de faible pénétration des cartes.
• Auditoires préférant la vie privée/prépayés.

2) Typologie des outils eCash

1. Chèques PIN (codes prépayés) :

Exemples : Paysafecard, Neosurf, Flexepin.
UX : entrez un PIN à 16/10 chiffres sur le formulaire d'hébergement ou payez à partir du portefeuille (myPaysafe/myNeosurf).
Caractéristiques : débits partiels, combinaison de plusieurs PIN, le reste est conservé.

2. Codes à barres/QR « Payer en magasin » (cash payment barcode) :

Exemples : paysafecash, réseaux locaux (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - Ezone U et al.).
UX : Le merchant génère un barcode/QR → le client paie en espèces à la caisse → le fournisseur envoie une confirmation.
Particularités : le chèque est valable pour un temps limité (expiré), le montant est fixe.

3. Référence/Slip pour ATM/banque en ligne (détails de la facture) :

Exemples : Multibanco Références - PT, Konbini - JP.
UX : code/référence + montant, paiement par ATM/banque en ligne/boutique partenaire.
Caractéristiques : minimum de frod, rapprochement strict par référence.

3) Acteurs de l'écosystème

Fournisseur/circuit (eCash/bons) : produit des codes PIN/barcodes, tient des catalogues de vente au détail, KYC/AML, antifrod, donne des API/widgets.
PSP/acquéreur : connecte le merchant, la caisse d'hébergement/SDK, les statuts, les harceleurs Web, les registres et les calculs.
Détail/caisse : réception d'argent/lecture de code à barres, synchronisation avec le fournisseur.
Banque/compensation : règlement et créditation de fonds au merchant.
Merchant : initie le paiement/facturation, traite les statuts, les retours et recon.

4) Flux de paiement

4. 1 bon PIN (Hosted/Redirect)

1. Checkout → la sélection eCash (par exemple Paysafecard/Neosurf).
2. Redirect/Hébergé le formulaire du fournisseur → entrer le NIP/entrer dans le portefeuille → confirmer (SCA/scoring comportemental).
3. Retour au merchant : 'success/pending/failed/canceled/expired'.
4. Le crédit réel est par registre quotidien (T + 1/T + 2).

4. 2 Code à barres/QR « payer en magasin »

1. Merchant crée une facture : somme + barcode/QR + expiry.
2. Le client va au point de vente et paie en espèces → la caisse confirme l'opération au fournisseur.
3. Le fournisseur envoie au merchant le succès en ligne, puis le crédit dans les registres (T + 0/T + 1).

4. 3 Référence/Slip (ATM/online-banking/conbini)

1. Génération de référence (entity/reference/amount) + durée de validité.
2. Paiement par ATM/banque en ligne/boutique partenaire.
3. Statut en ligne 'paid'et settlement ultérieur dans les registres.

5) Statuts et calculs

Statuts en ligne : 'created '/' pending '/' success' paid '/' failed '/' canceled '/' expired '.
Settlement : généralement T + 0/T + 2 jours bancaires (par contrat/canal).
Dans la logique d'entreprise, divisez la confirmation en ligne et le crédit réel.

6) Limites, KYC et risque

• Par transaction, 24h/7d, limite du nombre de NIP par paiement/jour.
• Pour les nouveaux récipiendaires/merchants, les seuils/extraits sont réduits.
• Géo-règles (pays voucher vs localisation client/merchant), velocity, device-signaux.
• Il n'y a pas de Charjback ; les disputes sont sur l'ODR du fournisseur/PSP.
• Recommandation : maintenir les limites par pays/réseau/CUS et ne pas hardcoder les montants.

7) Remboursements et débits partiels

Refund = nouvelle opération de crédit (dans le portefeuille eCash/virement bancaire - selon les règles du fournisseur).
Les fonds partiels sont généralement pris en charge.
Pour les chèques PIN, des prélèvements partiels et une combinaison de NIP sont souvent disponibles ; pour les factures barcode - le montant est fixe.

8) Économie et tarifs

La commission pour le merchant est généralement inférieure au MDR de la carte CNP, mais varie en termes de géo/volume/catégorie.
Dopage : hébergement/SDK, publicité des points de vente, sapport/ODR, traitement 'expired/pending', recon.

9) Modèles UX

Paiement PIN : IU compréhensible pour plusieurs PIN et indicateur de solde ; messages d'erreur : « incorrect/use », « limite dépassée », « région non supportée ».
Barcode/QR : code majeur + minuterie, boutons « imprimer/envoyer à messenger/email ».
Instructions de paiement hors ligne : 3-4 étapes avec les logos des réseaux ; carte des points ou heures d'ouverture les plus proches.
L'état de la commande : "Attend le paiement" avec l'autorénovation; Dans 'expired', le bouton « créer un nouveau code ».
Reçu : montant, heure, 'paymentId', canal (PIN/Barcode/Reference), UTR/ref. du registre, les contacts du Sapport.
Localisation : monnaie/langue/textes fiscaux, marques locales des réseaux.

10) Sécurité et conformité

PII-minimisation : le PIN/portefeuille est introduit du côté du fournisseur (Hosted/Widget).
Web hooks : HMAC/nonce, protection contre le replay, dedup d'événement, journal d'audit.
KYC/AML/GDPR : règles d'âge/limite pour les fonds prépayés, restrictions de sanctions/géo-restrictions.
Antifrod : limites par appareil/session, cooling-off, step-up, surveillance des PIN/barcodes répétitifs.

11) Intégration et architecture

Options de connexion

1. Hosted/Embedded chez PSP/fournisseur - démarrage rapide, la responsabilité minimale pour les données sensibles.
2. Server-to-Server + Hébergé est votre propre checkout avec contrôle de statut, sans traitement de votre PIN.
3. Pay-by-Link/Invoice - paiements de référence et cas de sappport.

Backend minimum

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotentialité ('orderId' + clé), rétroactions exponentielles, DLQ, déduplication Web.
Répertoires : pays/réseaux/limites/niveaux CUS, codes d'erreur, métriques SLA sur les canaux.
Observability : conversion (PIN vs Barcode/Reference), proportion de « pending→expired », temps moyens avant paiement/settlement, géo-anomalie.

12) Notes géographiques (repères)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Asie : Konbini (JP) et réseaux locaux (FamilyMart/Lawson/7-Eleven).

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

1. Sélectionnez le fournisseur/PSP et les réseaux cibles (PIN/Barcode/Reference), acceptez les tarifs/SLA/settlement.
2. Implémentez 'createPayment'createInvoice 'avec expiry, pages d'instructions et script fallback.
3. Connectez les webhooks (HMAC), l'idempotence, les retraits et le dédoublement des événements.
4. Configurez daily auto-recon + full-recon, stockez l'UTR/fin de référence.
5. Inclure les demandes partielles, les procédures ODR et les messages de refus/limites compréhensibles.
6. Lancez les SLA-dashboards (conversion, 'expired', délai de paiement/settlement) et les alertes par dissynchrones.
7. Effectuez des tests e2e : plusieurs PIN, code à barres en retard, montant incorrect, double paiement, remboursement par tranches.

Carte de repères

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Settlement : généralement T + 0-T + 2 par registre PSP/fournisseur.
Chargeback : absent ; refund est une opération de crédit distincte.
Limites/CUS : dépendent du pays/réseau/canal et du profil du client.
Récurrence : premier mandat eCash → (SEPA/Open-Banking/local) pour les débits ultérieurs.

Résumé

Stratégie : eCash-mix (PIN + barcode/QR + référence) pour atteindre un public cash et réduire le MDR.
Architecture autour de webhooks + recon, idempotence stricte et compréhensible UX'pending/expired ".
Configurations limites/CUS et géo-règles - hors code, avec mise à jour régulière.
Pour les abonnements, le premier eCash est un mandat →, une gestion transparente et des notifications pour l'utilisateur.