La caisse, et tout ce qu’il y a derrière.
Configurez les prestataires de paiement par marque et suivez chaque étape du parcours de paiement.
Cette page décrit le fonctionnement des paiements dans Callisto : comment le prestataire de paiement est déterminé pour une marque et une méthode, ce qui se passe entre le clic sur « déposer » et le mouvement d’un solde, comment les retraits sont retenus puis approuvés, comment la crypto est créditée selon ce qui est réellement arrivé, et comment tout le parcours se teste avant la signature du moindre contrat prestataire.
De la demande de dépôt au solde du wallet.
Quatre étapes, chacune susceptible d’échouer et chacune consignée. Rien du parcours n’est caché à l’opérateur qui devra l’expliquer ensuite.
Le prestataire de paiement de la marque est déterminé
Un dépôt désigne une marque et une méthode de paiement, et la plateforme détermine quel processeur traite cette combinaison pour cette marque. Deux marques sur une même installation peuvent utiliser des processeurs entièrement différents pour la même méthode.
Le joueur est conduit chez le processeur
Le prestataire renvoie une redirection que la caisse ouvre — page hébergée ou cadre, selon ce que le processeur prend en charge. Cartes, wallets, méthodes locales, bons, paiements assistés par un agent et écritures manuelles suivent chacun la forme que leur méthode autorise.
Le verdict arrive par un webhook signé
Le processeur répond sur un point d’entrée dont la frontière est une signature sur le corps brut, et non une clé de plateforme : une société externe ne détient jamais un identifiant ouvrant les services internes. Les renvois sont ordinaires, donc une livraison est reconnue par un index et non par une lecture que deux rappels concurrents passeraient tous les deux.
Le solde n’est crédité qu’une seule fois
Un paiement réglé publie un événement de solde, que le wallet applique en concurrence optimiste. La même livraison reçue deux fois ne crédite pas deux fois ; cette garantie est dans la base, pas dans un chemin de code dont quelqu’un doit se souvenir.
Des méthodes, dans la forme qu’elles ont vraiment.
Les types de méthode sont numérotés une fois pour toute la plateforme, si bien que la même valeur signifie la même chose dans le backoffice, la caisse et les rapports. Lesquelles une marque propose, et dans quel ordre, relève de sa configuration.
Pages hébergées ou session ouverte côté serveur, pour garder le joueur dans votre caisse là où le processeur le permet.
Facturée sur une adresse avec une échéance, puis surveillée on-chain.
Les wallets qu’attend un marché, chacun derrière sa propre intégration.
Y compris les rails locaux qu’une caisse limitée aux cartes laisse de côté.
Pour les marchés où un réseau d’agents alimente le joueur, avec son wallet et ses règlements.
L’écriture manuelle est réservée à l’administration, jamais visible côté joueur, et chacune porte la personne qui l’a faite.
Les méthodes d’une marque, leur ordre dans la caisse et leurs limites se configurent par skin — ajouter une méthode est de la configuration, ajouter un processeur est une classe derrière une interface plus une ligne.
Chaque retrait mis en attente indique clairement la raison.
Les retraits sont l’endroit où une plateforme a une politique ou en improvise une. Callisto en a une : un retrait peut être jugé au moment où le joueur le demande, et la réponse est écrite sur le paiement lui-même.
Jugé à la demande, pas après le mouvement d’argent
Interroger le moteur de risque au règlement est trop tard : le retrait qu’il devait arrêter a déjà eu lieu. La demande est donc évaluée quand le joueur la formule, et le blocage est inscrit sur le paiement au lieu d’être déduit après coup d’un statut.
Le motif est une colonne, pas un statut
Un retrait retenu porte ce qui le retient. Qui ouvre la file voit pourquoi celui-ci attend, au lieu de le déduire de l’ordre des lignes.
L’inconnu retient plutôt qu’il ne libère
Si une vérification ne peut aboutir — service injoignable, statut illisible — le retrait attend une personne. Traiter une question sans réponse comme un feu vert est précisément l’erreur que cette règle empêche.
L’approbation est la décision de quelqu’un, et elle est signée
Approbations manuelles, refus et ajustements consignent qui les a faits et quand, dans une piste inaltérable. Un retrait qui a bougé sans personne derrière est exactement ce sur quoi porte un audit.
Crédité selon ce qui est arrivé, pas selon ce qui était demandé.
Un dépôt crypto est facturé sur une adresse avec une échéance, puis surveillé. Le joueur est crédité de ce qui a réellement été réglé on-chain, seul chiffre qui soit vrai : les factures sont sous-payées, surpayées et payées en retard, et créditer le montant de la facture revient à créditer un souhait. Sous-paiement et surpaiement ont donc des issues définies au lieu de devenir un ticket de support, et le dépôt se rapproche de la chaîne plutôt que de l’intention.
Tester la caisse sans rien signer.
Un simulateur de paiement est livré avec la plateforme, et ce n’est pas un bouchon qui renvoie « succès » : il emprunte le même chemin de webhook qu’un vrai processeur, de sorte que ce qu’on répond à votre code est ce qu’un prestataire aurait répondu.
Dépôts et retraits de bout en bout
Un cycle complet — demande, redirection, rappel, mouvement de solde — avant même qu’un PSP soit choisi, et a fortiori intégré. Généralement des mois avant que ces tests soient possibles autrement.
Les échecs, pas seulement le chemin heureux
Refus, expirations, rappels malformés et signatures falsifiées sont des scénarios que vous pouvez demander. Une signature falsifiée est réellement rejetée, parce que le simulateur passe par la vraie vérification et non à côté.
Sans danger à côté d’un vrai prestataire
Une marque n’obtient le simulateur qu’en étant configurée pour lui, et le chemin de webhook refuse une livraison dont le prestataire n’est pas le sien. Une marque pointée sur un vrai processeur ne peut pas être pilotée depuis le simulateur.
Ajoutez des processeurs de paiement sans repenser la plateforme.
Un processeur est une implémentation derrière une interface plus sa ligne de configuration : identifiants par marque, chiffrés, jamais renvoyés par l’API. Rien au-dessus de cette couture ne change, et c’est ce qui fait de « notre acquéreur sur ce marché » une question de configuration plutôt qu’une question de roadmap. Vos équipes peuvent en ajouter un sans nous : le code est à vous, et les implémentations existantes sont les exemples travaillés.
Nous ne publions pas de mur de logos. Avoir écrit une intégration et l’avoir vue régler de l’argent réel pour votre marque sont deux affirmations différentes, et le choix des processeurs relève du contrat de chaque marque. Demandez-nous directement : vous aurez une réponse nette sur ce qui a tourné en conditions réelles et ce qui ne l’a pas fait — y compris là où la réponse est « pas encore ».
Questions sur les paiements.
Ce qui remonte dès que la caisse cesse d’être un schéma.
Des intégrations pour un certain nombre de processeurs sont livrées dans le code — cartes, crypto, e-wallets et méthodes locales — et en ajouter un autre est une classe derrière une interface plus une ligne de configuration, pas une modification de plateforme. Nous ne publions pas la liste comme un mur de badges, parce que « l’intégration existe » et « elle a réglé de l’argent pour votre marque » sont deux énoncés différents et que seul le second compte pour vous. Dites-nous avec quels acquéreurs et PSP vous avez des contrats, et nous vous dirons clairement ce qui est déjà implémenté, ce qui a tourné en conditions réelles, et ce qu’implique le raccordement du reste.
Oui, et c’est la configuration normale. Le prestataire est déterminé par marque et par méthode de paiement : une même installation peut servir une marque européenne chez un acquéreur et une marque latino-américaine chez un autre, avec des méthodes différentes dans chaque caisse. Les identifiants appartiennent à la marque, sont stockés chiffrés et ne sont jamais renvoyés par l’API.
Un retrait est jugé quand le joueur le demande, et non après le mouvement d’argent ; le blocage est écrit sur le paiement avec le motif qui l’a causé. Si une vérification ne peut aboutir, le retrait attend une personne au lieu de passer par défaut. Approbations manuelles et ajustements consignent qui les a faits, dans une piste inaltérable.
Il est crédité de ce qui est réellement arrivé on-chain, et non du montant facturé. Sous-paiement et surpaiement ont des issues définies au lieu de devenir un ticket de support, et le dépôt se rapproche de la chaîne — le seul enregistrement qui ne soit pas une déclaration d’intention.
Oui, et c’est l’un des éléments les plus utiles de la livraison. Un simulateur de paiement est livré avec la plateforme et emprunte le même chemin de webhook qu’un vrai processeur, refus, expirations, corps malformés et signatures falsifiées compris. Vos équipes peuvent dérouler un cycle complet de dépôt et de retrait des mois avant qu’un contrat existe, et une marque pointée sur un vrai processeur ne peut pas être pilotée depuis le simulateur.
Non, et délibérément pas. Les wallets sont multidevises et chaque montant reste dans la devise où il s’est produit ; il n’y a pas de source de taux de change sur la plateforme, car convertir au taux du jour ferait juger le même montant différemment à deux dates. Là où un seuil ou un rapport a besoin d’une devise, il est défini par devise plutôt que converti dans une seule.
Gardez les acquéreurs et PSP avec lesquels vous travaillez déjà.
Dites-nous avec quels processeurs vous avez des contrats et quels marchés vous ouvrez. Nous vous dirons ce qui est déjà implémenté, ce qui a tourné en conditions réelles, et ce qu’implique réellement le raccordement du reste.
Nous répondons sous un jour, le plus souvent le jour même.
Voir la plateforme