Skrill : portefeuille et cartes

1) Qu'est-ce que Skrill et quand le choisir

Skrill est un portefeuille électronique (stored-value) du groupe Paysafe avec une large couverture pour les produits numériques et iGaming. L'utilisateur garde le solde, fait le P2P, paie les merchants et peut également utiliser la carte Skrill (virtuel/plastique sur les rails Mastercard - la disponibilité dépend du pays). Pour le merchant, Skrill donne une conversion élevée grâce à App2App/Hosted-chekout, bas frod (SCA, device binding, risque scoring) et un public fidèle (status VIP).

• Contenu numérique, jeux, abonnements, gembling (dans les juridictions autorisées/par contrat).
• Un border de paiement croisé lorsque vous avez besoin d'un retour rapide au portefeuille/paiement aux joueurs.
• Comme un « deuxième portefeuille » dans un mélange de méthodes à côté des cartes et A2A.

2) Écosystème et rôles

Skrill (circuit/émetteur de portefeuille) : règles de l'AUP, limites, KYC/AML, risque-scoring, portefeuille.
PSP/Acquirer (etc Paysafe) : onbording merchant, tarifs, hébergement/Widget/API, rapports et calculs.
Merchant : initie le paiement/retour/paiement, traite les statuts, maintient un rapprochement.
Payeur : S'identifie en Skrill/App2App, confirme SCA, gère le solde/carte.

3) Produits et scénarios

3. 1 Pay-in (portefeuille)

Hosted/Redirect (recommandé) : sur checkout → redirect dans Skrill → login/SCA → confirmation → retour au merchant.
App2App/Deeplink : l'application Skrill s'ouvre sur mobile ; Retour sans soudure à la caisse.
Embedded/Widget : le widget est intégré dans votre page (avec attention aux exigences de sécurité).

3. 2 sources Top-up dans le portefeuille (chez l'utilisateur)

Les cartes (3DS2),

A2A/open-banking (les options dépendent du pays),

eCash/bons (localement),

P2P à l'intérieur de Skrill.
Le recrutement dépend du risque/géo et du niveau KYC.

3. 3 Payouts / Withdraw

Paiements sur le portefeuille Skrill (déboursés/payants affiliés).
Conclusion de l'utilisateur : à la banque (SCT/ACH/local), à la carte ou en espèces/agents - où disponible.

3. 4 P2P/Request-to-Pay

Transferts entre portefeuilles par email/ID ; des scripts R2P (demande de paiement) sont possibles.

3. 5 Carte Skrill (Mastercard)

Carte virtuelle/plastique, paiements hors ligne/en ligne ; la radiation vient du solde du portefeuille.
3DS/SCA en ligne, NIP/NFC pour POS ; cache-out aux guichets automatiques avec le soutien.

4) Statuts, calculs et finances

4. 1 Modèle type des statuts

`created → pending → success | failed | canceled | expired`

En option : 'autorisé → captured' (si une autorisation séparée est utilisée).

4. 2 Settlement et rapports

Fincredit au merchant : généralement T + 1/T + 2 jours ouvrables selon les registres PSP.
Le succès en ligne n'est pas égal à l'inscription comptable : gardez daily auto-recon et périodique full-recon.

4. 3 Retours et disputes

Refund est une opération de crédit distincte (full/partial) de retour au portefeuille/source.
Chargeback : pour les paiements à partir du solde du portefeuille - il n'y a généralement pas de chargback de carte classique ; si le paiement a été effectué sur des rails de cartes (COF/carte dans Skrill), une procédure de carte de l'émetteur est possible.
ODR/plaintes : sur les procédures Skrill/PSP ; stocker les logs d'exécution du service.

5) Limites, KYC et politique de risque

Per-transaction, per-day/24h, parfois weekly/monthly ; abaisser les seuils pour les nouveaux bénéficiaires/boursiers.
Les niveaux KYC de l'utilisateur (basic/extended/VIP) définissent les limites pour le top-up/débit/sortie.
Velocity/device/géo-règles et terreur avec restrictions.
Pour iGaming - exigences séparées par licence/géo-filtres/âge.

6) Économie et tarifs

La commission pour le merchant est généralement inférieure aux cartes CNP ; dépend de la géographie/chiffre d'affaires/catégorie (MCC).
Dopage : Hébergement/SDK, support 'pending/expired', ODR/sapport, recon, rétention/réserves (par risque).
Les programmes de Skrill VIP stimulent l'activité de portefeuille → augmentent la conversion et la LTV sur certains marchés.

7) modèles UX affectant la conversion

Mobile-first : proposez un App2App, sur le bureau - Redirect compréhensible.
Minuteurs d'attente de confirmation ('pending'), bouton « refaire ».
Erreurs claires : limite de portefeuille/méthode, échec SCA, délai ; proposer immédiatement des alternatives (cartes/A2A).
Reçu : montant, devise, 'transactionId', canal (App2App/Hosted), UTR/fin-ref des registres.

8) Intégration du merchant

8. 1 Options

1. Hosted/Redirect - démarrage rapide et trace PCI/PII minimale.
2. Server-to-Server + App2App/Hosted PIN-entry - votre UX, contrôle des statuts ; il est essentiel de respecter les exigences de sécurité.
3. Pay-by-Link/Invoice - paiements de référence/différés, collecte.

8. 2 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 : auto-rapprochement sur les registres quotidiens + périodique full-recon ; conserver le lien bancaire/UTR.
Observability : conversion, 'pending→success/expired', latence à settlement/refund, erreurs SCA/limites.

8. 3 PCI/sécurité

Dans le script Hosted, la charge PCI est minimale (vous ne traitez pas les PAN/secrets).
Secrets/clés dans vault, IP-allowlist à vos endpoints callback, stricte redirect-URI.

9) Antifrod et signaux comportementaux

Profilage de l'appareil et du comportement, géo-anomalies, tentatives échouées répétées.
Restrictions sur les nouveaux bénéficiaires/paiements, cooling-off, step-up-authentification.
Pour les produits numériques : émission différée jusqu'à ce que settlement/passer des chèques risque, protection contre les bonus-abyse.

10) Caractéristiques pour iGaming et verticales « sensibles »

Vérifiez la validité de la géo et des licences, respectez le contrôle de l'âge, Responsible Gaming.
Attendez-vous à des limites plus strictes, hold/réserves possibles, surveillance élargie.
Prévoyez des rails alternatifs (A2A/portefeuille local/bons) et un routage intelligent selon le risque, la géo et le profil du joueur.
Les paiements aux joueurs via Skrill sont généralement confortables, mais respecter les limites/segmentation des risques.

11) Comparaison « portefeuille vs carte Skrill »

• Paiement à partir du solde, SCA dans l'application/cabinet.
• Refund - instantanément dans le portefeuille ; Il n'y a pas de solde de portefeuille classique.
• Convient pour les paiements répétés, P2P, retours partiels rapides.

• Paiement sur les rails de cartes ; accessibilité par pays.
• Les règles de cartes s'appliquent (3DS, chargeback possible par carte).
• Facile à utiliser pour les achats hors ligne et universels en ligne.

12) KPI et métriques opérationnelles

Taux approval et conversion sur les canaux (App2App/Hosted).
Proportion de « pending→expired » et temps moyen de confirmation.
Refund rate/ODR et le temps avant la décision.
Settlement lag (succès → registre → inscription).
Cost-to-serve (temps de sappport par case), part VIP et sa contribution au chiffre d'affaires.

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

1. Contrat avec PSP/Skrill : tarifs, SLA, géo/vertical, politique de remboursement/paiement.
2. Choix d'intégration : Hosted/App2App ; implémentez 'createPayment', écrans d'erreur/limites/répétitions.
3. Connectez webhooks (signature/NMAS), idempotence et retraits, déduplication des événements.
4. Configurez daily recon + full-recon ; stocker UTR/finn-reference, alertes par dissynchrones.
5. Inclure les partenaires partiels, les règlements ODR ; la délivrance différée de marchandises à risque.
6. Dashboards SLA : conversion, 'pending', settlement lag, retours ; alerte sur les anomalies/geo.
7. 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'si nécessaire).
Settlement : Plus souvent T + 1/T + 2 par registre.
Chargeback : pour l'équilibre du portefeuille - généralement pas ; pour le rail de carte - il y en a.
Limites/CUS : dépendent du pays et du niveau ; Gardez-le dans votre flig.
Récurrence : premier paiement → mandat (SEPA/Open-Banking/portefeuille-mandat) ou COF à la carte.

Résumé

Skrill est un portefeuille solide pour les produits numériques et iGaming avec une bonne conversion et une opération mature. Intégrez à travers les Hosted/App2App, construisez autour des webhooks + idempotence + recon, gardez les limites/CUS/erreurs dans le configue et surveillez 'pending→success/expired'. Pour les segments à haut risque - utiliser des rails alternatifs et le routage intelligent, et pour les retours - s'appuyer sur les fonds partiels et les journaux d'opérations de qualité.