Laissez l’IAtout brancher.

Tu es mon développeur. Aide-moi à accepter des paiements en crypto sur mon site web avec blockwallets (les clients paient en USDT, USDC, BTC et 14 autres cryptos ; je suis crédité en dollars américains).

## À propos de moi
- Mon site est construit avec : Je ne suis pas sûr. Regarde d’abord mon projet, dis-moi avec quoi il est construit, puis commence.
- Comment je veux encaisser : Crée une facture à la commande et redirige le client vers la page de paiement de blockwallets ; quand l’argent arrive, blockwallets appelle mon serveur, je marque la commande comme payée et je l’expédie.
- Je ne suis pas programmeur. À chaque étape, dis-moi quels fichiers tu as modifiés et ce que je dois faire (par exemple où mettre les variables d’environnement). Ne change pas trop de choses à la fois.
- AGENTS.md à la racine du projet contient les règles d’intégration de blockwallets ; lis-le d’abord, et lis https://blockwallets.io/llms-full.txt pour les détails.

## Lis d’abord la documentation ; ne devine pas l’API de mémoire
- Documentation d’intégration complète (Markdown) : https://blockwallets.io/llms-full.txt
- Règles d’intégration et erreurs courantes : https://blockwallets.io/agents.md
- Si le site utilise déjà Cryptomus, NOWPayments ou Coinbase Commerce, passe-le à l’API compatible correspondante au lieu de le réécrire : https://blockwallets.io/docs/migrate.md?lang=en
- Si tu ne peux pas ouvrir un lien, dis-le-moi et je collerai le contenu.

## Points clés (là où les intégrations déraillent d’habitude)
1. Tous les endpoints sont en POST + JSON sur https://blockwallets.io. En-têtes : merchant = l’UUID du merchant, sign = md5(base64(corps de la requête) + API key). Signe exactement la chaîne JSON que tu envoies ; ne la re-sérialise pas après la signature.
2. Crée une facture avec POST /v1/payment. Obligatoires : amount (une chaîne avec au plus deux décimales, p. ex. "42.00"), currency ("USD"), order_id (mon numéro de commande : lettres, chiffres, - et _, jusqu’à 100 caractères). Passe aussi url_callback (l’URL du webhook) et url_success (où le client revient après le paiement). Redirige le client vers result.url.
3. Un nouvel appel avec le même order_id renvoie la même facture : les nouvelles tentatives sont donc sûres et ne créent jamais une seconde facture.
4. Les signatures des webhooks doivent être vérifiées : analyse le JSON du webhook, retire le champ sign, ré-encode le reste comme le fait json_encode de PHP (compact, caractères non ASCII conservés, / échappé en \/), puis md5(base64(encodé) + API key) doit être égal à sign. Oublier d’échapper / est l’erreur la plus fréquente.
5. Marque la commande comme payée uniquement quand status vaut paid ou paid_over, en utilisant payment_amount_usd. Le même webhook peut arriver plusieurs fois : dédoublonne par uuid + status. Réponds avec un statut 2xx une fois traité.
6. Conserve l’ID du merchant et l’API key dans des variables d’environnement (p. ex. BW_MERCHANT, BW_API_KEY) ; ne les écris jamais en dur dans le code et ne les commite pas. Ajoute d’abord le domaine de l’URL du webhook dans « Domaines du site web », sur la page « Développeurs › Intégration et clés » du tableau de bord.
7. Fais d’abord tout fonctionner avec les identifiants Test (testnets, pas d’argent réel) ; ne passe en Live qu’après ma confirmation.

## Quand tu as terminé, vérifie chaque point et donne-moi le résultat
- [ ] Créer une facture de test avec les identifiants Test et obtenir le lien de la page de paiement (result.url)
- [ ] Ouvrir la page de paiement et cliquer sur « Simuler un paiement » → montant complet
- [ ] Mon serveur reçoit un webhook avec status paid et la signature est vérifiée
- [ ] La commande correspondante est marquée comme payée
- [ ] Le même webhook reçu une seconde fois (renvoyez-le depuis « Développeurs › Journal des webhooks » dans le tableau de bord, ou avec POST /v1/payment/resend) n’expédie pas deux fois

Si un point échoue, dis-moi où ça bloque et le message d’erreur exact avant de changer autre chose.