Il n’existe pas de « meilleur modèle de portefeuille » indépendamment de l’architecture de la plateforme. Le choix entre portefeuille unique et portefeuille de transfert dépend du système de soldes existant, du traitement des exceptions, des processus de rapprochement et du périmètre de changements acceptable.
Cet article explique des décisions d’achat et d’architecture. Il ne contient ni points de terminaison, ni protocoles de rappel, ni signature, ni identifiants, ni configuration de production.
Qu’est-ce qu’un portefeuille unique ?
Un portefeuille unique est souvent appelé portefeuille sans couture. En pratique, la plateforme continue de gérer le solde principal du joueur, tandis que la collaboration concernant les soldes de jeu, débits, paiements ou annulations s’effectue au moyen de processus convenus par les deux parties.
Les achats doivent notamment confirmer :
- Si l’interface de portefeuille de la plateforme peut répondre aux exigences de collaboration en temps réel ;
- comment les requêtes dupliquées ou échouées sont traitées ;
- comment les soldes, transactions et enregistrements de jeu sont rapprochés ;
- qui détermine l’incident et l’escalade lorsqu’une exception survient côté plateforme ou fournisseur.
Un portefeuille unique ne signifie pas automatiquement « zéro risque » ou « aucune modification ». Il impose des exigences plus claires en matière de stabilité d’interface, de traitement des doublons et de responsabilités liées aux exceptions.
Qu’est-ce qu’un portefeuille de transfert ?
Un portefeuille de transfert transfère généralement d’abord un solde du côté de la plateforme vers celui du fournisseur de jeu, puis le retransfère ou traite le solde restant selon le processus convenu par les deux parties lorsque le joueur quitte le jeu.
Les achats doivent notamment confirmer :
- Comment les dépôts, retraits et états de solde sont enregistrés ;
- comment les interruptions ou défaillances sont traitées ;
- comment le solde de la plateforme et celui du fournisseur sont rapprochés ;
- si le parcours du joueur et l’expérience actuelle de la plateforme peuvent intégrer des étapes supplémentaires.
Un portefeuille de transfert ne signifie pas non plus automatiquement « plus simple ». Il déplace une partie de la complexité vers les transferts de solde, les états et les processus de rapprochement.
Que comparer entre les deux modèles ?
| Élément de comparaison | Priorité du portefeuille unique | Priorité du portefeuille de transfert |
|---|---|---|
| Architecture existante | Capacité du portefeuille de la plateforme à collaborer de façon fiable | Existence de mécanismes matures de transfert et de gestion des statuts |
| Traitement des exceptions | Doublons, délais d’attente, défaillances et cohérence des soldes | Interruptions de transfert, état incertain et reprise |
| Rapprochement | Enregistrements de transaction, de manche et de solde | Soldes de la plateforme et du fournisseur, et enregistrements de transaction |
| Parcours du joueur | Collaboration en temps réel pendant le jeu | Effet des dépôts et retraits sur l’expérience |
| Périmètre technique | Exigences de rappel et d’idempotence | Exigences relatives au transfert de solde et à la machine à états |
Ce tableau sert à organiser des discussions techniques. Il ne représente aucun engagement d’AG concernant une mise en œuvre, une performance ou une capacité d’automatisation précise.
Que doit couvrir la phase de test ?
Quel que soit le modèle choisi, le seul parcours de réussite ne doit pas être vérifié. Il est conseillé de confirmer au minimum :
- Les parcours normaux de lancement et de transaction ;
- le solde insuffisant, les requêtes échouées ou les exceptions de session ;
- les requêtes dupliquées ou la remise répétée d’un même statut ;
- la manière dont les enregistrements, manches ou écarts de solde sont rapprochés ;
- les éléments de preuve relatifs aux incidents, les responsables et les méthodes d’escalade.
Quelles questions ne peuvent pas être tranchées par un article public ?
Les protocoles d’interface complets, domaines d’environnement, mécanismes de signature, champs de rappel, identifiants, listes d’autorisation, latence, capacité, stabilité, conditions de marché et conditions commerciales doivent tous être confirmés dans un processus de projet contrôlé.
AG peut actuellement confirmer que les documents commerciaux existants couvrent deux sujets d’intégration : le portefeuille unique et le portefeuille de transfert. L’approche de compatibilité précise, l’environnement de test et le périmètre de livraison dépendent toujours de l’architecture de la plateforme et du résultat de la confirmation du projet.
Transformer ce guide en plan de projet ?
Ce contenu aide à préparer une évaluation. Il ne remplace pas la confirmation technique, contractuelle, de certification ou de droit local applicable au projet.