Journal des modifications
Septembre 2026
10 septembre
Le formulaire HTML envoie désormais un conteneur signé. À la place des champs de facture séparés — data (base64url du JSON) et signature (HMAC-SHA256 de la chaîne data). L'endpoint est passé de invoices/createFromForm à invoices/form. Les anciens formulaires ne fonctionnent plus et doivent être reconstruits : voir Signature du formulaire HTML.
8 septembre
Les champs numériques du corps du webhook sont désormais des nombres. Six champs envoyés auparavant comme des chaînes sont maintenant envoyés comme des nombres : project.commissionRate, invoice.commissionFiatUSD, invoice.amountFiatUSD, invoice.amountFiat, invoice.calcAmountFiat, payment.amount. L'ensemble des champs, leurs noms et leur ordre n'ont pas changé.
Gardez à l'esprit : les zéros finaux sont supprimés, un montant de 10.00 arrive donc comme 10. Les montants sous 0.0001 arrivent en notation exponentielle, par exemple 1.0e-6 — l'analyse JSON standard renvoie le bon nombre ; seule l'analyse manuelle de la chaîne casse.
Les notifications construites avant le déploiement et pas encore remises arrivent dans l'ancien format. Le destinataire doit accepter les deux variantes jusqu'à ce que la file se vide — cela ne prend pas plus de deux jours.
6 septembre
Les champs numériques des réponses de l'API sont désormais des nombres. Concerne invoices/list, payments/list et invoices/create.
| Champ | Avant | Après |
|---|---|---|
commissionFiatUSD | "0.10" | 0.1 |
amountFiatUSD | "10.00" | 10 |
amountFiat | "1000.00" | 1000 |
views | "0" | 0 |
payment.amount | "10.500000000" | 10.5 |
Une clé restreinte à un projet applique désormais la restriction dans toutes les méthodes. Auparavant, certaines méthodes ignoraient le projet. Maintenant, c'est un filtre dans les méthodes de liste, et une requête sur la facture ou le portefeuille d'un autre projet est rejetée avec Restricted project. Une méthode qui ne peut pas respecter la restriction de projet est fermée à une telle clé. Les détails sont dans la section « Portée de la clé ».
La liste des paiements renvoie désormais les paiements non associés. Auparavant, payments/list ne renvoyait que les paiements liés à une facture. Maintenant, les résultats incluent tous les paiements de vos portefeuilles ; un paiement non associé n'a pas de bloc invoice. Ce sont exactement les paiements nécessaires à l'association manuelle via invoices/bindPayment.
L'annulation de facture distingue désormais les raisons de refus. Auparavant, une facture absente comme des conditions non remplies renvoyaient un Invoice not found générique. Maintenant, Invoice not found signifie uniquement que la facture n'existe pas, tandis que des conditions non remplies renvoient Invoice cannot be canceled.
Les identifiants mal formés sont désormais rejetés. invoices/list valide invoiceId, invoiceUid et projectId ; payments/list — walletId et invoiceId. Une valeur qui ne convient pas renvoie Parameter is filled in incorrectly avec le nom du champ. Auparavant, un tel paramètre était silencieusement ignoré et les résultats revenaient non filtrés.
Les bornes de période incluent désormais toute la journée nommée. startDate et endDate sont interprétés de 00:00:00 à 23:59:59. Auparavant, le jour de fin était entièrement coupé, et une requête sur une seule journée ne renvoyait que les enregistrements créés exactement à minuit. Concerne invoices/list, payments/list, statistics/invoices et statistics/payments.
Un champ projet a été ajouté à l'historique du solde. Chaque opération de la méthode billing/history porte désormais un champ projectId. Pour les opérations au niveau du compte — recharges et bonus — il vaut null.
4 septembre
La description et les données de service reviennent sous leur forme d'origine. Les champs description et serviceData étaient auparavant stockés encodés, et dans les réponses de l'API un guillemet arrivait comme " et un signe inférieur comme <. Maintenant, c'est exactement ce que le marchand a soumis qui est renvoyé. À l'affichage en HTML, échappez la valeur de votre côté.
Les formulaires HTML n'acceptent que POST. Créer une facture en suivant un lien avec des paramètres dans la barre d'adresse ne fonctionne plus — les paramètres ne sont lus que depuis le corps de la requête. Si vous utilisiez des liens, remplacez-les par un formulaire avec method="post".
3 septembre
Les notifications de webhook sont désormais signées. Les en-têtes X-Timestamp et X-Signature ont été ajoutés ; la signature est calculée en HMAC-SHA256 avec le secret du webhook. Vérifier la signature permet de distinguer une notification authentique d'une contrefaçon. La mécanique et les exemples sont dans la section « Vérification de la signature du webhook ».
Le changement est rétrocompatible : si vous n'ajoutez pas le contrôle, votre gestionnaire continue de fonctionner comme avant.