Tester une intégration de paiement crypto consiste à prouver que la bonne commande est exécutée une seule fois, uniquement après vérification du paiement, et pas simplement qu’une page de paiement s’ouvre. Distinguez les tests d’acheminement des messages, les tests des états de commande de votre application et toute vérification de recette autorisée avec des fonds réels. Chacun répond à une question différente.
Cette liste s’adresse aux développeurs et aux commerçants qui préparent le lancement d’un parcours de paiement, y compris en USDC ou en USDT lorsque l’actif et le réseau sélectionnés sont effectivement disponibles. Il s’agit d’une procédure de test recommandée, et non d’un rapport attestant que Yolfi a réussi ces tests pour votre application ou propose un parcours de paiement complet sur un réseau de test.
Identifiez le type de test que vous réalisez
Une notification de paiement simulée n’est pas un transfert sur la blockchain. Un transfert sur un réseau de test n’est pas un paiement sur le réseau de production. Une redirection réussie du navigateur ne correspond à aucun de ces deux cas.
| Niveau de test | Ce qu’il permet d’établir | Ce qu’il ne permet pas d’établir |
|---|---|---|
| Tests applicatifs avec des données contrôlées | Transitions des commandes, règles de rejet et gestion des doublons | Que le fournisseur peut joindre votre récepteur déployé |
| Webhook de test du fournisseur | Accessibilité du point de réception et traitement des données de test du fournisseur | Que des fonds ont été transférés ou qu’une facture réelle a été payée |
| Transfert sur un réseau de test, si explicitement pris en charge | Comportement sur ce réseau de test précis | Disponibilité de l’actif en production ou règlement sur le réseau principal |
| Vérification de recette autorisée en production | Résultat observé pour un paiement réel en production | Que tous les réseaux, jetons et cas d’échec fonctionnent |
Le guide des réseaux d’Ethereum explique que les soldes des comptes et l’historique des transactions ne sont pas partagés entre des réseaux indépendants. Une adresse identique en apparence ne rend pas les fonds d’un réseau de test utilisables sur le réseau principal. Consultez la documentation actuelle du fournisseur plutôt que de supposer qu’un test générique de portefeuille s’applique à son service de paiement.
Commencez par délimiter les tests par écrit
Consignez l’environnement de l’application, le compte fournisseur, l’URL du récepteur, l’emplacement du secret de signature, les identifiants des commandes et les effets attendus avant tout envoi. Utilisez des fiches clients jetables et désactivez les livraisons réelles, les accès payants et les courriels aux clients pour les scénarios simulés.
Séparez les configurations de test et de production. Ne copiez jamais un secret de signature dans un article, une capture d’écran, un ticket ou une transcription de conversation. Vos preuves de test doivent identifier la version du secret utilisée, sans en révéler la valeur. Ne demandez pas à un acheteur sa phrase de récupération ni ses clés privées pour analyser un test qui a échoué.
Pour une vérification avec des fonds réels, obtenez une autorisation interne explicite concernant le montant, les frais, la destination et la personne responsable. Utilisez un portefeuille contrôlé par l’entreprise et un montant que vous pouvez vous permettre de perdre. N’envoyez pas d’argent vers une adresse ou un réseau au seul motif qu’ils figuraient dans une ancienne capture d’écran, une page générée sur une cryptomonnaie ou des instructions de test non officielles.
Prouvez que le serveur détermine le montant de la commande
Avec Yolfi API Checkout, le serveur du commerçant crée une Checkout Session avec le montant définitif et la devise. L’acheteur sélectionne ensuite un réseau et un jeton pris en charge, ce qui crée une Invoice à partir de cette session. Un Paylink réutilisable répond à un autre besoin qu’une commande dynamique dont le prix est fixé par le serveur.
Pour un panier dynamique, testez le calcul du prix et l’association de la session sur votre propre serveur avant de tester les mouvements de fonds :
- Modifiez un total transmis par le navigateur et confirmez qu’il ne peut pas remplacer le prix de référence de la commande.
- Essayez d’utiliser la référence de commande d’un autre client et confirmez que l’application refuse l’accès non autorisé.
- Actualisez ou rouvrez le parcours de paiement et vérifiez que les tentatives répétées restent associées à la commande prévue.
- Modifiez le panier après la création de la session et confirmez que l’application dispose d’une règle explicite pour remplacer ou rejeter l’ancienne tentative de paiement.
Il s’agit de critères de recette de l’application, pas d’affirmations selon lesquelles un point d’accès du fournisseur rejette toutes les requêtes possibles. Conservez ensemble la référence de commande du serveur et la référence de session renvoyée. N’inventez pas de champ d’API et ne supposez pas qu’un identifiant contrôlé par le navigateur prouve que la commande appartient à l’utilisateur.
Envoyez un webhook de test sans créer de vente réelle
La documentation actuelle des webhooks de Yolfi décrit un événement de test envoyé depuis l’interface d’administration par le même circuit d’acheminement, le même adaptateur et le même en-tête de signature que les événements réels. Ses données contiennent livemode: false et un identifiant d’événement evt_test_. Le test ne crée ni factures, ni événements de paiement, ni abonnements, ni fiches clients.
Utilisez cet événement pour vérifier l’acheminement et le traitement des données, pas le règlement. Un récepteur qui renvoie 200 OK peut tout de même accorder un accès à tort ou supprimer silencieusement le message. Examinez l’état obtenu dans l’application ainsi que le résultat de l’envoi.
Vérifiez les signatures avec la procédure documentée et le secret de signature propre au point de réception, et non avec la clé d’API de l’organisation. Confirmez que votre processus d’exécution des commandes en production ne peut pas traiter un événement de test comme une commande payée. Si vous testez l’exécution avec des données contrôlées dans un environnement de test isolé, utilisez des enregistrements jetables et examinez-les séparément de ceux de production.
Yolfi exige une destination HTTP ou HTTPS publique et ne suit pas les redirections. Pour le développement local, sa documentation recommande un tunnel HTTPS public. Vérifiez l’URL finale exacte du récepteur : une requête réussie vers un autre chemin ou une adresse accessible uniquement en local ne prouve pas que le fournisseur peut acheminer ses messages.
Utilisez une matrice d’échecs, pas seulement une capture du scénario idéal
Exécutez des tests avec des données contrôlées dans votre propre environnement de test isolé pour les cas que l’émetteur de test du fournisseur ne permet pas de reproduire. Présentez-les clairement comme des tests applicatifs ; ne faites pas passer des événements fournisseur fabriqués pour des preuves de paiements réels.
| Scénario | Observation requise dans votre application |
|---|---|
| Événement de test valide | Enregistré comme test ; aucune livraison réelle ni reçu de paiement |
| Signature absente ou invalide | Rejet avant toute modification d’une commande |
| Paiement initié mais non confirmé | La commande reste impayée |
| Paiement confirmé pour une commande inconnue | Mis en attente d’analyse ; aucune association à un client au hasard |
| Même événement signé reçu deux fois | Un seul résultat métier persistant, sans double livraison |
| Deux processus traitent le même événement | Une seule décision d’exécution malgré le traitement simultané |
| Récepteur indisponible, puis rétabli | Reprise constatée sans double exécution de la commande |
| Fermeture du navigateur avant le retour | Le traitement du paiement ne dépend pas de la page de retour |
Chez Yolfi, invoice.created signale le démarrage ; payment.confirmed est le déclencheur documenté de l’exécution de la commande. Ne marquez pas une commande comme payée au seul motif que le premier message est arrivé. Le guide des webhooks idempotents traite de la déduplication persistante ; cette liste vise à réunir des preuves que votre implémentation se comporte effectivement ainsi.
Testez délibérément la reprise après incident. Un processus qui renvoie une réponse positive avant d’enregistrer un événement peut perdre du travail s’il s’interrompt brutalement. Un processus qui livre des biens avant de consigner la fin de l’opération peut répéter la livraison lors d’une nouvelle tentative. Choisissez une architecture de traitement persistante, puis testez les points d’interruption au lieu de supposer qu’une seule requête réussie prouve la fiabilité.
Vérifiez les instructions de l’acheteur et le traitement des paiements non résolus
Ouvrez le véritable parcours de paiement sur un téléphone et un ordinateur. Vérifiez que le montant affiché, l’actif sélectionné, le réseau, la destination et les informations d’expiration sont compréhensibles avant un transfert. Testez les commandes de copie et la lecture du code QR sans supposer qu’un code QR configure automatiquement chaque portefeuille émetteur de manière correcte.
N’envoyez pas de jeton non pris en charge, n’utilisez pas délibérément le mauvais réseau et n’effectuez pas de transfert irréversible uniquement pour tester un message d’erreur. Répétez plutôt ces situations d’assistance avec des enregistrements contrôlés. Le guide de prévention des erreurs de réseau explique les vérifications à présenter à l’acheteur.
Simulez une commande impayée ou expirée : l’acheteur doit recevoir un statut clair et une prochaine étape sûre, pas une promesse de récupération sans fondement. Utilisez la procédure pour les factures expirées afin de déterminer les vérifications à effectuer avant de demander un autre paiement. Un second paiement ne doit pas devenir la réponse automatique à une première tentative au résultat incertain.
Si vous y êtes autorisé, documentez une vérification de recette en production
Ne poursuivez qu’après avoir confirmé que l’actif et le réseau de production choisis sont disponibles dans le parcours réel. Tenez compte des frais de réseau nécessaires et conservez la destination sous le contrôle de l’entreprise. Un webhook de test du fournisseur ne justifie pas l’envoi de fonds réels par une voie non vérifiée.
Consignez les références de commande et de paiement, l’actif et le réseau réellement utilisés, le montant, la confirmation observée, les preuves du portefeuille récepteur et l’état d’exécution obtenu. Ne promettez pas un nombre universel de confirmations ni un délai de règlement fixe. Vérifiez le résultat réellement observé, pas seulement une capture de portefeuille.
Rapprochez ensuite ce paiement des enregistrements de commande et de reçu. La liste de rapprochement des paiements aide à distinguer les fonds entrants de leur affectation aux commandes et des frais. Si vous prévoyez de rembourser le paiement de recette, autorisez et vérifiez le remboursement séparément ; ne supposez pas qu’il s’agit d’une annulation automatique.
Une vérification réussie établit le fonctionnement d’une voie observée à un instant donné. Répétez les tests de recette pertinents lorsque la logique de paiement, le déploiement du récepteur, les secrets ou les voies prises en charge changent. Ne généralisez jamais un unique paiement en USDC pour affirmer que tous les réseaux USDT fonctionnent.
Conservez un dossier de preuves pour la mise en production
Enregistrez un rapport concis précisant la version de l’application testée, l’environnement, les scénarios, les résultats attendus, les résultats réels et les problèmes non résolus. Ajoutez des liens vers des journaux privés et des fiches de commande plutôt que de publier des identifiants clients ou des historiques complets de portefeuilles.
Bloquez le lancement si un événement de test peut déclencher l’exécution d’une commande réelle, si un doublon peut provoquer une double livraison, si des signatures invalides peuvent modifier l’état ou si les paiements confirmés ne peuvent pas être associés en toute sécurité. Attribuez chaque point non résolu à un responsable. Un indicateur d’acheminement vert ne remplace pas ces résultats métier.
Questions fréquentes
Un webhook de test de Yolfi déplace-t-il des cryptomonnaies ?
Non. Le test documenté valide l’acheminement et le traitement des données sans créer de factures ni d’enregistrements de paiement. Il ne prouve pas qu’un paiement réel sur la blockchain a abouti.
Un paiement sur un réseau de test équivaut-il à un environnement de test d’un service de paiement ?
Non. Un réseau de test est un réseau blockchain distinct. L’environnement de test d’un fournisseur est propre à son service. Vérifiez si le fournisseur prend en charge le mode précis dont vous avez besoin ; cet article n’établit pas l’existence d’un parcours de paiement Yolfi sur un réseau de test.
Puis-je lancer le service dès que la page de paiement redirige correctement ?
Pas sur cette seule preuve. Vérifiez le traitement des paiements côté serveur, l’association aux commandes, la protection contre les doublons et la reprise après incident. L’acheteur peut fermer le navigateur avant qu’une page de retour ne s’ouvre.
Dois-je tester chaque échec en envoyant de l’argent réel ?
Non. Utilisez des tests applicatifs isolés et les simulations documentées du fournisseur pour la gestion des échecs. Toute vérification de recette en production nécessite une autorisation et une voie prise en charge vérifiée, pas des transferts délibérés vers de mauvais réseaux.
Conclusion : testez le résultat métier avant le lancement
Commencez par un périmètre clair, prouvez le traitement des commandes côté serveur et distinguez un événement simulé de fonds vérifiés. Utilisez les liens de paiement Yolfi pour les offres à prix fixe adaptées ou le parcours API documenté pour les commandes dynamiques, puis conservez des preuves que le traitement du paiement, et non la redirection du navigateur, commande l’exécution.
