Aller au contenu principal
NewChargeback Protection + Fee Intelligence for high-volume merchants. Get a savings analysis and a review of your dispute handling.See how it works
Détails

Chargeback Protection + Fee Optimization

See how it works: high-volume merchants get automated dispute evidence, interchange optimization, and real-time savings visibility.

See how it works
Fee Check

PLATEFORME DÉVELOPPEUR

Journal des modifications

Le journal des modifications de RapidCents consigne l’historique des versions de l’API, les nouveaux points de terminaison, les changements de comportement et les avis de dépréciation avec leur fenêtre de migration. Deux types d’entrées y figurent et exigent des réactions différentes : les ajouts vous parviennent sans action, puisqu’une version fixée continue de se comporter comme documenté; les changements incompatibles sont livrés derrière une nouvelle version et restent optionnels jusqu’à ce que vous migriez. Chaque entrée nomme la version concernée et, pour une dépréciation, la date où l’ancien comportement cesse.

  • Sandbox avec cartes test
  • Webhooks signés
  • Erreurs typées et idempotence
  • Support développeur dédié
Demander un accès sandboxS'inscrire
Espace du journal API RapidCents avec chronologie de version, résultat sandbox et terminal bleu
Le journal de l'API RapidCents ouvert à côté d'un résultat sandbox et d'un terminal de test, montrant ce qui a changé dans la dernière version.

Ce qui passe sur le fil

  • Ce qu’une entrée vous dit

    Ce qui a changé, la version d’API concernée, s’il s’agit d’un ajout ou d’une rupture et, pour une dépréciation, la date d’arrêt de l’ancien comportement. Ce qui exige une action le dit explicitement.

  • Ce que porte votre compte

    Une version d’API fixée, envoyée à chaque requête ou définie par défaut. C’est ce point d’ancrage qui décide quelles entrées vous concernent aujourd’hui et lesquelles décrivent un avenir non choisi.

  • Ce qu’implique une migration

    Pointez un client sandbox sur la nouvelle version, rejouez votre suite de régression, comparez les formes de réponse signalées, puis basculez la production. L’ancienne version sert jusqu’à la fermeture de la fenêtre.

Quand l’utiliser

  • Planifier la maintenance

    Vérifiez les dépréciations avant chaque cycle de livraison plutôt qu’après un incident, et ouvrez le billet pendant que la fenêtre est encore confortable.

  • Déboguer un changement de comportement

    Confirmez si une différence observée correspond à un changement documenté avant de chercher un bogue dans votre propre code.

  • Réviser une montée de version

    Une version de SDK vise une version d’API précise : monter le paquet peut vous faire franchir une frontière déjà décrite ici.

Mettre en œuvre Journal des modifications

  1. Abonnez-vous au journal des modifications avant la mise en production, dans un canal réellement lu.

  2. Fixez explicitement votre version d’API au lieu de suivre la plus récente.

  3. Consignez la version envoyée par chaque service : une mise à niveau devient une liste de déploiements connue.

  4. Testez la nouvelle version en sandbox pendant la fenêtre de dépréciation, pas à sa fin.

  5. Montez un service à la fois et validez avec votre propre suite de régression.

Ce qui échoue, et comment vous l’apprenez

  • Suivre la dernière version au lieu de la fixer

    Une intégration non ancrée hérite de chaque changement le jour de sa livraison, y compris ceux qu’il aurait fallu planifier. Le symptôme : une réponse qui change sans aucun déploiement chez vous.

  • Une fenêtre de dépréciation qui se referme en silence

    Les avis sont publiés, mais un abonnement dirigé vers une boîte non surveillée équivaut à aucun abonnement. Acheminez ces entrées là où la garde les voit.

  • Des services sur des versions différentes

    Une même base de code ancrée à deux versions produit un comportement qui dépend du service ayant traité la requête. Inventoriez les ancrages avant une migration.

  • Tout monter d’un coup

    Un déploiement unique qui franchit la frontière pour tous les services n’offre aucun retour arrière partiel. Montez-en un, observez, puis passez au suivant.

Sandbox par rapport à la production

  • Les nouvelles versions se testent avant l’engagement

    Un client sandbox peut viser la nouvelle version pendant que la production reste ancrée : la migration se valide contre votre code plutôt que contre des notes de version.

  • Le sandbox rend une dépréciation peu coûteuse

    Faire tourner l’ancienne et la nouvelle version côte à côte montre exactement quelles assertions changent : c’est la liste que doit contenir le billet de migration.

  • L’ancrage se comporte pareil

    La version fixée est respectée de la même façon dans les deux environnements : une exécution sandbox représente vraiment ce que fera la bascule.

Questions sur Journal des modifications

Quel préavis est donné avant un changement incompatible de l’API?

Les changements incompatibles sont livrés dans une nouvelle version avec une fenêtre de dépréciation publiée, donc les intégrations fixées à la version précédente continuent de fonctionner pendant votre migration.

Suis-je mis à niveau automatiquement?

Non. Les versions sont fixées par compte : une mise à niveau est une action explicite que vous posez après vos tests.

Où les correctifs de sécurité sont-ils annoncés?

Les correctifs de sécurité sans incompatibilité sont appliqués immédiatement et consignés dans le journal des modifications; tout ce qui exige une action de votre part vous est communiqué directement.

Qu’est-ce qui constitue un changement incompatible?

Tout ce sur quoi une intégration existante pourrait raisonnablement s’appuyer : un champ retiré ou renommé, un type restreint, une nouvelle entrée obligatoire, ou un état renvoyé là où il ne l’était pas. Un champ optionnel ajouté ou un nouveau point de terminaison ne l’est pas.

Que se passe-t-il si je ne migre jamais?

La version dépréciée continue de servir jusqu’à la fermeture de la fenêtre publiée, dont l’avis donne la date. Après, les requêtes ancrées à cette version cessent d’être servies : c’est pourquoi la fenêtre est annoncée.

Comment savoir quelle version mon intégration envoie vraiment?

Par vos propres journaux de requêtes, pas par présomption. Des services configurés à des moments différents divergent, et l’ancrage documenté par une équipe n’est souvent pas celui déployé par une autre.

Une montée de SDK change-t-elle ma version d’API?

Elle le peut. Chaque version de SDK vise une version d’API précise : lisez les notes du SDK avec l’entrée du journal et traitez les deux comme une seule migration.

Comment migrer vers une nouvelle version d’API en sécurité?

Pointez un client sandbox vers la nouvelle version pendant que la production reste fixée, exécutez votre suite de régression, comparez les formes de réponse signalées par l’entrée, puis déplacez un service à la fois. L’ancienne version continue d’être servie jusqu’à la fermeture de la fenêtre : rien ne justifie de tout déplacer en un seul déploiement.

Où les entrées du journal des modifications devraient-elles être livrées?

Dans un canal que l’équipe de garde lit réellement. Un abonnement dirigé vers une boîte que personne ne surveille équivaut à aucun abonnement, et une fenêtre de dépréciation qui se ferme en silence est exactement ce qui produit une forme de réponse modifiée sans aucun déploiement de votre côté.

Suite de l’intégration

Prochaine étape

Parlez à un spécialiste RapidCents

Fee Check de RapidCents lit un relevé de traitement et sépare l’interchange de la marge. Téléversez un relevé pour une analyse instantanée, ou ouvrez un compte marchand et commencez à encaisser sur un seul compte.

Vérifier mes fraisCommencer
  • Sans engagement
  • Spécialistes paiement au Canada
  • Téléversement sécurisé