Skip to main content
L’API v1 est figée depuis le 14 novembre 2026. Une intégration qui fonctionne aujourd’hui continue de fonctionner sans modification.

Ce qui ne change jamais en v1

  • Les chemins des endpoints et leurs méthodes.
  • Le nom, le type et le sens d’un champ existant.
  • Les valeurs d’un champ à liste fermée, comme status d’un paiement ou d’un retrait. Aucune nouvelle valeur n’y apparaît sans préavis.
  • Le format des erreurs (error.code, error.message, error.doc_url) et les codes d’erreur existants.
  • La signature des webhooks (en-tête MercyPay-Signature) et la forme des événements existants.
  • Le format des identifiants (pay_…, cs_…, po_…).

Ce qui peut arriver à tout moment

Ces ajouts ne cassent pas une intégration bien écrite. Votre code doit les accepter sans erreur :
  • un nouvel endpoint ;
  • un nouveau champ dans une réponse ou dans un événement ;
  • un nouveau paramètre optionnel dans une requête ;
  • un nouveau type d’événement webhook. Un endpoint ne le reçoit que si vous l’ajoutez à sa liste d’événements ;
  • un nouveau code d’erreur pour un cas qui échouait déjà ;
  • une limite de débit plus large.
Ignorez les champs que vous ne connaissez pas au lieu de les refuser, et prévoyez une branche par défaut quand vous lisez un type d’événement.

Quand un changement cassant est nécessaire

Cela reste exceptionnel, par exemple pour corriger une faille de sécurité. Dans ce cas :
  1. Nous l’annonçons au moins 90 jours avant, dans le journal des changements, avec la mention À vérifier.
  2. Nous écrivons au contact technique de votre boutique. Renseignez-le dans Réglages, rubrique Informations de l’entreprise. Sans contact technique, nous écrivons au propriétaire.
  3. Pendant ces 90 jours, l’ancien et le nouveau comportement coexistent.
Seule exception à ce délai : une faille de sécurité grave, corrigée tout de suite et annoncée le jour même.