Comment Tester une Passerelle de Paiement Crypto Avant de Lancer

Vous ne pouvez pas tester une passerelle de paiement crypto dans un bac à sable sur Payora, car Payora n'en a pas : pas de mode testnet, pas de clés API en mode test, pas de fausses factures. Ce que vous faites à la place, c'est inspecter le véritable paiement à la caisse hébergée à /demo, rejouer un webhook que vous avez signé vous-même contre votre propre gestionnaire, puis envoyer un vrai paiement d'environ un dollar à votre propre facture sur un réseau bon marché. Cette dernière étape coûte une petite somme et prouve une chose qu'un bac à sable n'a jamais pu prouver.

Pourquoi il n'y a pas de bac à sable, et pourquoi ce n'est pas le problème que vous pensez

Un bac à sable est un simulateur. Il vous permet de répéter votre code contre une fiction écrite par la passerelle. C'est vraiment utile pour les processeurs de cartes, où l'acquéreur, le moteur de risque et les rails de règlement sont tous opaques et vous n'avez pas d'autre moyen d'accès.

La crypto est différente. La partie qui casse en production n'est presque jamais l'appel API. C'est la chaîne : un paiement qui atterrit sur le mauvais réseau, un verrouillage de taux qui a expiré pendant que l'acheteur copiait l'adresse, une politique de confirmation que personne n'a lue, une adresse que le serveur a dérivée de la mauvaise clé. Un bac à sable crée une facture payée de toutes pièces. Cela ne vous dit rien sur tout cela. Pire, cela vous dit que tout va bien, ce qui est le mensonge le plus coûteux qu'un test puisse produire.

Donc, la manière honnête de tester une passerelle de paiement crypto est une échelle : tout ce que vous pouvez vérifier gratuitement d'abord, puis un petit paiement réel qui exerce toute la chaîne de bout en bout. Voici l'ordre dans lequel je le ferais.

1. Regardez le véritable processus de paiement avant d'écrire une ligne de code

Ouvrez /demo. Cela génère une facture en direct sur le véritable processus de paiement hébergé, la même page que vos acheteurs verront. Pas de compte, pas de code. Regardez ce qui se passe réellement : comment se comporte le sélecteur de pièces, à quoi ressemble la fenêtre de verrouillage du taux, ce que l'acheteur voit pendant qu'une transaction est encore non confirmée, ce qui se passe lorsque le minuteur expire.

Cinq minutes ici évitent une dispute plus tard, car la plupart des bugs d'intégration commencent leur vie comme un mauvais modèle mental du flux. Lisez /docs à côté et associez chaque écran aux champs de la facture derrière. Ensuite, créez votre compte sur /register et obtenez votre clé API et api_secret.

2. Exercez votre gestionnaire de webhook sans rien dépenser

C'est le gros morceau. Votre gestionnaire est le code qui transforme "l'argent est arrivé" en "le client a reçu son article", et c'est la partie que vous pouvez tester de manière exhaustive gratuitement, car vous détenez le secret qui signe le webhook. Tout ce que Payora peut signer, vous pouvez le signer.

Le schéma est un HMAC simple. La signature est hex(hmac_sha256(timestamp . '.' . rawBody, api_secret)), envoyée dans X-Payora-Signature, avec le même horodatage dans X-Payora-Timestamp. L'horodatage doit être dans ±120 secondes par rapport à maintenant, et chaque livraison porte un Idempotency-Key en-tête qui reste stable lors des nouvelles tentatives du même événement. Signez le brutoctets du corps, pas un tableau ré-encodé — le ré-encodage est la raison classique pour laquelle une signature correcte échoue.

<?php
// Sign a webhook exactly the way Payora signs one, and POST it at your own endpoint.
$secret = 'YOUR_API_SECRET';                          // the secret your handler verifies with
$url    = 'https://yoursite.com/payora-webhook.php';  // your endpoint, on your dev host

$body = json_encode([
    'event'      => 'invoice.paid',
    'invoice_id' => 'inv_local_1',
    'order_id'   => '1001',
    'status'     => 'paid',
    'amount'     => '1.00',
    'currency'   => 'USD',
    'asset'      => 'USDT',
    'network'    => 'tron',
], JSON_UNESCAPED_SLASHES);

$ts  = (string) time();
$sig = hash_hmac('sha256', $ts . '.' . $body, $secret);   // lowercase hex

$ch = curl_init($url);
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => $body,          // send the RAW body you signed
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER     => [
        'Content-Type: application/json',
        'X-Payora-Timestamp: ' . $ts,
        'X-Payora-Signature: ' . $sig,
        'Idempotency-Key: whk_local_1',
    ],
]);
$out  = curl_exec($ch);
$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
echo "$code\n$out\n";

Pointez cela vers votre propre point de terminaison de développement et vous avez un générateur de webhook qui ne coûte rien et fonctionne en boucle. Le côté vérification — comparaison en temps constant, vérifications de fenêtre, pourquoi vous devez lire le flux d'entrée brut — est couvert en détail dans vérification de la signature du webhook avec HMAC-SHA256.

3. Les tests qui attrapent réellement des bugs

Exécutez chacun de ces tests contre votre gestionnaire et vérifiez le base de données, pas seulement le statut HTTP. Les résultats attendus ne sont pas des notes de bas de page ; ce sont le test.

• Signature valide → 200, commande marquée comme payée, exactement une fois.
• Le même webhook livré deux fois (même Idempotency-Key) → toujours exactement une commande payée. Pas de double crédit, pas de deuxième clé de licence, pas de deuxième étiquette d'expédition. C'est le bug réel le plus courant dans les intégrations de paiement, et les nouvelles tentatives sont normales, pas exceptionnelles.
• Corps altéré avec l'ancienne signature — changer amount de 1.00 à 1000.00, garder la signature → rejeté, commande NON payée.
• Signature incorrecte ou absente → rejeté. Un vide X-Payora-Signature doit échouer exactement comme un incorrect.
• Horodatage périmé — réglez-le sur dix minutes auparavant → rejeté sur la fenêtre, même si le HMAC lui-même est valide.
• Identifiant de facture inconnu ou étranger → rejeté proprement. Pas d'erreur fatale, pas de 500, pas de ligne à moitié écrite.
• Votre point de terminaison renvoie 500 → la nouvelle tentative qui suit ne doit pas être appliquée deux fois. Tuez la connexion à la base de données en plein traitement si vous voulez être sûr.
• Comparaison en temps constant — utilisez hash_equals(), jamais ==. Et ne journalisez jamais le api_secret, pas au niveau de débogage, pas tronqué, pas une seule fois.

Si les huit passent, votre gestionnaire est en meilleure forme que la plupart des intégrations en direct. Maintenant, remarquez ce que aucun d'eux n'a prouvé : que l'argent peut réellement vous atteindre.

4. Un petit paiement réel à vous-même

Maintenant, dépensez un dollar. Créez une facture via l'API ou un lien de paiement depuis /accept-payments, ouvrez le paiement, et payez-le de votre propre portefeuille, à votre propre facture, avec environ 1 $.

Choisissez un réseau bon marché et rapide afin que cela coûte des centimes plutôt que des dollars : TON (Gram), Tron et Solana confirment tous en quelques secondes pour une fraction de centime. Ne faites pas cela sur le réseau principal de Bitcoin à moins que Bitcoin ne soit spécifiquement ce que vous expédiez — vous attendrez dix minutes par tentative et paierez pour le privilège.

Ce paiement unique est le seul test qui exerce la chaîne complète : verrouillage de taux, détection on-chain, confirmation à la politique de cet actif (voir combien de confirmations sont sûres), webhook signé, votre base de données. Si cela fonctionne, votre intégration fonctionne. Si cela ne fonctionne pas, l'échec est réel et spécifique — ce qui est exactement ce que vous voulez découvrir un mardi tranquille et non lors d'un lancement.

5. Prouvez que vous pouvez retirer l'argent

Tout le monde saute cette étape. C'est l'étape qui fait mal.

Avant de prendre le paiement d'un seul client, retirez ce dollar vers un portefeuille que vous contrôlez. Vérifiez /balance, effectuez un retrait ou un transfert, regardez-le arriver. Si vous prévoyez de payer des fournisseurs ou des affiliés, poussez un lot à travers /mass-payouts avec deux lignes et des montants triviaux, et confirmez que l'étape de signature hors ligne fonctionne sur votre machine réelle avec votre matériel de clé réel — pas en théorie, sur la machine.

Une passerelle dans laquelle vous pouvez recevoir mais dont vous ne pouvez pas retirer n'est pas une passerelle. C'est un piège avec une belle page de paiement. Découvrir cela avec 1 $ coincé est une histoire que vous raconterez plus tard. Le découvrir avec 40 000 $ coincés est un après-midi très différent.

6. Vérifiez que les adresses dérivées vous appartiennent réellement

Celle-ci est spécifique aux configurations non-custodiales et elle est non-négociable. Payora dérive les adresses de réception uniquement à partir de matériel de clé publique — votre xPub ou clé publique maître. Les clés privées ne touchent jamais le serveur. C'est tout le modèle de sécurité, et cela implique une exigence stricte : le xPub que vous avez collé doit être celui que votre portefeuille possède réellement.

Alors vérifiez-le de manière indépendante. Prenez une adresse que le serveur a dérivée pour une facture, dérivez le même index à partir de votre xPub vous-même — dans votre logiciel de portefeuille, ou avec n'importe quelle bibliothèque de portefeuille HD hors ligne — et comparez les chaînes caractère par caractère. S'ils correspondent, chaque paiement atterrit quelque part d'où vous pouvez dépenser. S'ils ne correspondent pas, chaque paiement est perdu, silencieusement, avec un paiement vert et une commande payée pour vous tenir compagnie. Le xPub et l'explication du portefeuille HDexplique la dérivation.

Faites cela avant de passer en production. Pas après la première plainte.

Le compromis, dit honnêtement

Pas de bac à sable signifie que votre premier vrai test coûte un peu d'argent et un peu de soin. C'est un coût réel et je ne vais pas faire semblant du contraire. Ce que vous obtenez en échange est un test qui était vrai. Un bac à sable vous aurait donné une coche verte pour l'appel API et ne vous aurait rien dit sur le verrouillage des taux, la politique de confirmation, le chemin de retrait, ou si les adresses étaient les vôtres — les quatre choses qui décident réellement si vous êtes payé.

Un dollar, un après-midi et une liste de contrôle battent un simulateur qui est d'accord avec vous.

Prêt à le faire ? Créez un compte gratuit sur /register, créez votre première facture depuis /accept-payments, et travaillez sur la liste. L'ensemble de l'échelle prend environ une heure et environ un dollar.