PLATEFORME DÉVELOPPEUR
État du système
La page d’état de RapidCents rapporte en temps réel la disponibilité du traitement des paiements, de la passerelle de paiement, des webhooks, du tableau de bord et de la connectivité des terminaux, avec l’historique des incidents et un avis par abonnement. Les composants sont rapportés séparément à dessein, car la panne qui coûte cher est rarement totale : une livraison de webhooks en retard pendant que les autorisations passent normalement semble correcte sur un indicateur global unique, et ne l’est pas du tout dans une chaîne de commandes.
- Sandbox avec cartes test
- Webhooks signés
- Erreurs typées et idempotence
- Support développeur dédié
Ce qui passe sur le fil
Ce qui est rapporté
Un état par composant plutôt qu’un seul pour la plateforme, avec l’incident ouvert. Traitement, passerelle, livraison des webhooks, tableau de bord et connectivité des terminaux tombent indépendamment.
Ce que porte un incident
Ce qui est touché, ce qui ne l’est pas, l’heure de début, ce qui est établi à ce stade, et des mises à jour confirmées plutôt que supposées. La note de résolution suit une fois la cause comprise.
Ce qu’il faut corréler
Vos propres codes d’erreur et identifiants de requête. La chronologie de l’incident jointe à vos journaux distingue un événement de plateforme d’un déploiement fait une heure plus tôt et déjà oublié.
Quand l’utiliser
Pendant un incident
Confirmez l’état de la plateforme avant d’escalader un bogue d’intégration, et avant d’annuler une livraison qui n’y est pour rien.
En vérification diligente
L’historique des incidents montre comment les problèmes sont communiqués et résolus, ce qui informe davantage qu’un chiffre de disponibilité isolé.
En rédigeant votre plan de garde
La granularité par composant indique lesquels de vos systèmes se dégradent ensemble, donc quels replis méritent d’être construits.
Mettre en œuvre État du système
Abonnez votre canal de garde aux avis d’état avant d’en avoir besoin.
Vérifiez l’état des composants avant d’ouvrir un billet de support.
Corrélez vos codes d’erreur et identifiants de requête avec la chronologie de l’incident.
Décidez d’avance ce que fait votre application quand la livraison des webhooks se dégrade.
Lisez la note post-incident pour toute action requise de votre côté.
Ce qui échoue, et comment vous l’apprenez
Lire un seul indicateur et s’arrêter là
Une plateforme dite opérationnelle peut avoir un composant dégradé. Vérifiez celui dont dépend votre intégration : pour la plupart des applications, la livraison des webhooks plutôt que l’autorisation.
Aucun plan pour les événements retardés
Si la livraison ralentit, les paiements passent quand même et vos commandes attendent toujours. Sans file ni requête de rattrapage, impossible de reprendre le retard.
Escalader sans preuve
Un billet disant que les paiements échouent se traite plus lentement qu’un billet portant identifiants de requête, codes d’erreur et plage horaire. La page d’état dit ce que le support sait déjà.
N’alerter que sur la panne totale
La plupart des incidents apparaissent d’abord dans vos métriques : taux de refus qui monte, écart croissant entre paiements créés et événements traités. Alertez là-dessus et servez-vous de l’état pour expliquer.
Sandbox par rapport à la production
L’état couvre la production
La page rapporte l’environnement où se trouvent vos clients. La disponibilité du sandbox n’est pas la mesure d’un incident : une défaillance sandbox n’en indique pas la portée.
La dégradation se répète en sandbox
On ne planifie pas un incident de production, mais on peut pointer une intégration sandbox vers un point de terminaison volontairement brisé et observer le comportement pendant que les événements s’accumulent.
L’engagement est délimité
L’API de la passerelle porte un niveau de service de disponibilité de 99,9 %. Les autres composants sont rapportés à la page d’état selon leurs propres termes, et l’historique des incidents en est le relevé honnête.
Questions sur État du système
Où puis-je vérifier si RapidCents est en panne?
La page d’état rapporte chaque composant séparément : traitement, passerelle, webhooks, tableau de bord et terminaux, donc une dégradation partielle est visible au lieu d’être masquée derrière un seul indicateur global.
Puis-je m’abonner aux avis d’incident?
Oui. Les mises à jour peuvent être livrées dans un canal d’équipe, pour que la garde voie l’état de la plateforme sans avoir à l’interroger.
L’historique des incidents est-il conservé?
Oui, avec les notes de résolution, ce que les revues de vérification diligente demandent habituellement.
Existe-t-il un engagement de disponibilité à présenter aux achats?
L’API de la passerelle porte un niveau de service de 99,9 % de disponibilité. La portée compte : ce chiffre vise l’API de la passerelle, et la page d’état fait foi pour les autres composants.
Que faire quand la livraison des webhooks se dégrade?
Continuez d’accepter les paiements, écrivez votre propre enregistrement à partir de la réponse synchrone, puis rapprochez par l’API au retour de la livraison. Rien n’est perdu pendant un retard : la reprise est un rattrapage.
Comment distinguer un incident de plateforme d’un problème chez moi?
Vérifiez si le composant concerné est signalé comme dégradé, puis si vos échecs commencent à une frontière de déploiement. Si vos erreurs précèdent la fenêtre de l’incident, celui-ci n’est pas la cause.
Un incident prolonge-t-il une dépréciation ou un délai de support?
Non, et ces éléments sont suivis séparément. Les dates de dépréciation viennent du journal des modifications et les engagements de réponse de votre palier; un incident ne touche ni l’un ni l’autre.
Faut-il alerter sur la page d’état ou sur mes propres métriques?
Sur vos propres métriques d’abord. La plupart des incidents se manifestent par un taux de refus qui monte ou un écart croissant entre les paiements créés et les événements traités, avant toute publication. Servez-vous de la page d’état pour expliquer ce que votre surveillance a déjà détecté, pas pour le détecter.
La page d’état couvre-t-elle le sandbox?
Non. Elle rapporte l’environnement où se trouvent vos clients : une panne en sandbox pendant un incident ne dit rien de sa portée. La dégradation vaut quand même la peine d’y être répétée : pointez une intégration sandbox vers un point de terminaison de webhook volontairement brisé et observez ce que fait votre application pendant que les événements s’accumulent.
Suite de l’intégration
Un poste de support développeur RapidCents suit une requête de paiement en direct, tableau de bord et terminal de test à côté. Support développeur
Canal de support développeur avec paliers de service pour les intégrations en production.
Découvrir
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. Journal des modifications
Historique des versions de l’API, changements incompatibles et avis de dépréciation.
Découvrir
La documentation développeur RapidCents ouverte : référence API, exemple prêt à copier, et un terminal pour le parcours en personne. Documentation
Documentation complète des API, des webhooks, des terminaux et du sandbox.
Découvrir
Une chronologie de livraison webhook RapidCents à côté du paiement qui l'a déclenchée, un terminal de test sur le bureau. Webhooks
Événements webhook signés pour le cycle de vie des paiements, traités de façon idempotente.
Découvrir
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.
- Sans engagement
- Spécialistes paiement au Canada
- Téléversement sécurisé
