ecoPayz : portefeuille et comptes
1) Contexte et positionnement
ecoPayz (surnommé Payz) est un porte-monnaie électronique multi-devises (ci-après dénommé « portefeuille/compte ») axé sur les services numériques et iGaming (dans les juridictions autorisées). L'utilisateur garde des fonds sur son portefeuille, fait un P2P, paie les merchants, réapprovisionne le solde par différentes méthodes et envoie à la banque/carte/canaux locaux (l'accès dépend du pays/KUS).
Pourquoi le merchant profite-t-il
Plus de conversion grâce à la Hosted/App2App-UX et la reconnaissance dans les segments cibles.
Faible frod (SCA, binding des appareils, scoring des risques).
Une économie flexible (souvent en dessous des cartes CNP), des fonds partiels rapides dans le portefeuille.
2) Produits et rôles
Portefeuille/comptes : bilans multi-devises de l'utilisateur (top-up/consommation/sortie).
Cartes (virtuelles/plastiques sur les rails des schémas de cartes) - pas disponibles dans tous les pays.
Sources de bons (ecoVoucher et équivalents par l'intermédiaire de partenaires) - où autorisé.
PSP/acquéreur : onbording merchant, tarifs/MDR, hébergement/Widget/API, calculs et rapports.
Circuit/émetteur de portefeuille : AUP, KYC/AML, limites, antifrod, portefeuille.
3) Canaux et scripts personnalisés
3. 1 Pay-in (paiement au merchant)
Hosted/Redirect (recommandé) : redirect dans ecoPayz/Payz → login/SCA → confirmation → retour avec statut.
App2App/Deeplink : l'application porte-monnaie s'ouvre sur le mobile, puis retourne à la caisse.
Embedded/Widget : sous réserve des exigences de sécurité du fournisseur.
3. 2 Top-up au portefeuille (chez l'utilisateur)
Cartes (3DS2), A2A/Open services bancaires/transferts locaux, eCash/bons, P2P. L'ensemble des sources dépend du pays et du niveau KYC.
3. 3 Payouts/Withdraw
Paiements du merchant sur les portefeuilles des utilisateurs ; ensuite, le retrait de l'utilisateur à la banque/carte/méthodes locales (disponibilité par pays/CUS).
3. 4 P2P / Request-to-Pay
Virements et demandes de paiement entre portefeuilles (lorsque pris en charge).
3. 5 Carte Portefeuille
Carte virtuelle/plastique (si disponible) : prélèvement sur le solde du portefeuille ; en ligne - SCA/3DS, POS - PIN/NFC.
4) Statuts et calculs
Statuts types : 'created → pending → success | failed | canceled | expired' (+ si nécessaire 'autorisé → captured').
Settlement : Les inscriptions sur les registres PSP/fournisseur sont généralement T + 1/T + 2 (esclave. jours).
En toute logique, partagez le succès en ligne et le crédit réel.
5) Limites, KYC et politiques de risque
Limites per-txn/24h/7d/monthly ; des seuils distincts pour les nouveaux bénéficiaires/merchants et pour les conclusions.
Niveaux KYC (Basic/Extension/VIP) : définissent les maximums de Top-Up/Débit/Sortie et un ensemble de méthodes prises en charge.
Velocity/device/géo-règles, sanctions et limites d'âge (en particulier pour iGaming).
Gardez les limites/règles dans les configues avec possibilité de mise à jour à chaud.
6) Retours, disputes, finalité
Refund est une opération de crédit distincte (full/partial) de retour au portefeuille/source d'origine.
Chargeback : il n'y a généralement pas de chargeback classique pour les chargebacks purement « portefeuille » ; si le rail réel est une carte (COF/carte à l'intérieur du porte-monnaie), des procédures de carte chez l'émetteur sont possibles.
Planifiez les procédures ODR et conservez les logs complets d'émission du service numérique.
7) Économie et commissions
MDR pour le merchant est généralement inférieur aux cartes CNP, mais dépend de la géo/chiffre d'affaires/catégorie.
Suppléments : Hébergement/SDK, support 'pending/expired', ODR/disputes, recon, réserves possibles/hold par risque.
Gérer le coût : stimuler le top A2A et la multivalence (moins de FX), utiliser l'apsail sur le VIP.
8) Pratiques UX
Mobile-first : App2App en priorité ; sur le bureau, un Redirect clair.
Temps d'attente de confirmation ('pending'), répétition sécurisée, suggestions d'alternatives (cartes/A2A).
Erreurs transparentes : limite portefeuille/méthode, échec SCA, temporisation.
Reçu : montant/devise, 'transactionId', canal (App2App/Hosted), référence financière/UTR du registre.
9) Intégration du merchant
Options
1. Hosted/Redirect est un démarrage rapide, une trace PCI/PII minimale.
2. Server-to-Server + App2App/Hosted - UX personnalisé et contrôle dense des statuts.
3. Pay-by-Link/Invoice - pour les paiements différés/recouvrement.
Backend minimum
API: `createPayment`, `authorize/capture` (если требуется), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotentialité ('orderId' + clé), répétitions exponentielles, déduplication des hooks Web entrants.
Webhooks : signature/NMAS, timbres, protection contre le replay.
Recon : daily auto-recon + full-recon, stockage UTR/liens bancaires, alertes par dissynchrones.
Observability : conversion, 'pending→success/expired', settlement-lag, erreurs SCA/limites.
10) Sécurité et conformité
SCA (authentification dans le portefeuille), binding de device, scoring comportemental.
PII-minimisation : Hosted/Widget pour entrer des données sensibles, secrets - dans vault, IP-allowlist sur webhook-endpoints, stricts redirect-URI.
KYC/AML/GDPR, âge, sanctions, filtres géo, jeu responsable.
11) Paiements et affiliation
Les paiements de portefeuille sont souvent commodes (rapides et bon marché), mais segmentez par risque/géo/CUS.
Gardez les alternatives : SEPA/RTP/Push-to-Card/portefeuilles locaux pour les régions contestées ou les sommes importantes.
12) Caractéristiques pour iGaming
Vérifier la validité légale de la géo et de la licence ; inclure le contrôle de l'âge et l'auto-exclusion.
Attendez-vous à ce que les limites soient plus strictes, les hold/réserves possibles, la surveillance accrue des transactions et des paiements.
Planifiez votre routage intelligent (portefeuille ↔ A2A ↔ bons ↔ cartes) en fonction du risque/géo/profil du joueur.
13) KPI et métriques opérationnelles
Taux approval (séparément par App2App/Hébergé).
Pending dwell time и доля `pending→expired`.
Taux de refund/ODR et temps de décision moyen.
Settlement lag (succès → registre → inscription).
Partage FX et marge FX moyenne.
Part VIP/KYC étendu dans le chiffre d'affaires, Cost-to-serve (support/disputes).
14) Chèque-liste de sortie dans la prod
1. Contrat avec PSP/fournisseur : tarifs/MDR, règles FX, SLA par Web hooks/registres autorisés par géo/vertical.
2. Intégration : 'createPayment' + App2App/Hosted, écrans d'erreur/limites/répétitions.
3. Sécurité : signature/NMAS Web hooks, vault secrets, redirect-URI, IP-allowlist.
4. Recon : daily + full, stockage UTR/fin-références, alertes par dissynchrones.
5. Refunds/ODR : partial/full, pleybooks de Sapport, ligament de refund↔order.
6. Configurations : limites/CUS/tarifs/géo - hors code, avec versioning et mise à jour rapide.
7. Dashboards SLA : conversion, 'pending', settlement-lag, retours ; alerte sur les anomalies/geo.
8. E2E tests : App2App mobile, desktop-redirect, temporisation/répétitions, retours partiels, dégradation du fournisseur.
Carte de repères
Statuts : 'created/pending/success/failed/canceled/expired' (+ 'authorize/capture'le cas échéant).
Settlement : généralement T + 1/T + 2 par registre PSP/fournisseur.
Chargeback : inexistant pour le « portefeuille » net ; possible pour le rail de cartes.
Limites/CUS : dépendent du pays/niveau ; stocker dans un configh et mettre à jour régulièrement.
Récurrence : « premier paiement → mandat » (SEPA/Open-Banking/portefeuille-mandat) - si le scénario le supporte.
Résumé
ecoPayz/Payz est un portefeuille mature avec des bilans multi-devises, un UX mobile fort et une opération compréhensible. Intégrez à travers les Hosted/App2App, construisez autour des webhooks + idempotence + recon, gardez les limites/CUS/tarifs/géo dans votre configuration, et pour iGaming - respectez le cadre légal, segmentez les risques et gardez les rails alternatifs (A2A/bons/cartes) avec un routage intelligent sur le profil du joueur et la charge.