Smart Route
Un routage noté à partir des taux de succès mesurés, du coût et de la latence par connecteur, avec un disjoncteur qui retire un rail défaillant avant que vos clients ne le trouvent.
Commerçants qui perdent des ventes à cause de paiements échoués, et développeurs qui construiraient sinon leur propre bascule.
Fait partie de la plateforme elle-même : présent partout où BitriPay tourne.
Le problème
La plupart des intégrations figent un seul prestataire. Quand il se dégrade, chaque paiement se dégrade avec lui, et l’entreprise l’apprend par ses clients plutôt que par un tableau de bord.
Comment cela fonctionne
- Les connecteurs candidats sont rassemblés parmi ceux qui peuvent réellement porter ce paiement.
- Chacun est noté sur son taux de succès mesuré, son coût total et sa latence observée.
- Le disjoncteur retire un connecteur qui échoue, et le réadmet progressivement une fois rétabli.
- Une politique de commerçant peut orienter le choix vers le moins cher, le plus rapide ou le plus fiable.
Ce que vous pouvez vérifier
Des faits sur la plateforme en fonctionnement, pas des adjectifs. Chacun est visible dans le produit, dans la référence de l’API ou dans le grand livre.
- Les notes viennent d’une télémétrie conservée par tranches de quinze minutes sur vingt-quatre heures, éventuellement indexée par tranche de montant et par préfixe, plutôt que d’une liste de préférences figée.
- Le disjoncteur passe de fermé à ouvert après des fautes consécutives, puis à demi-ouvert après un délai, puis à fermé au succès suivant : un rail qui se rétablit est testé avec un paiement et non avec tous.
- La santé est un état par connecteur — sain, dégradé, indisponible, en maintenance — déduit du disjoncteur, de la dernière sonde et des succès récents.
- La bascule n’a lieu que pour les erreurs qui garantissent qu’aucun argent n’a bougé ; tout ce qui est ambigu déclenche d’abord une vérification de statut.
- Un commerçant peut orienter le routage vers le moins cher, le plus rapide ou le plus fiable, paiement par paiement.
Ce que cela coûte
Inclus. Vous payez le tarif du rail qui a porté le paiement, et le tableau de bord indique lequel l’a fait.
Questions
Une nouvelle tentative pourrait-elle facturer mon client deux fois ?
La bascule n’a lieu que pour les erreurs qui garantissent qu’aucun argent n’a bougé. Pour tout ce qui est ambigu — un dépassement de délai, un code inconnu — le statut est vérifié d’abord. Ne pas réessayer vaut mieux que réessayer vers un double débit.
Puis-je forcer un rail particulier ?
Vous pouvez orienter la politique de routage vers le moins cher, le plus rapide ou le plus fiable, et restreindre les rails qu’un paiement peut utiliser. Ce que vous ne pouvez pas faire, c’est forcer un rail dont le disjoncteur est ouvert, qui est tout l’intérêt d’en avoir un.
Comment savoir quel rail a été utilisé ?
Chaque paiement enregistre le connecteur qui l’a porté, ainsi que les tentatives précédentes. Le tableau de bord montre le chemin réellement emprunté, pas celui qui était prévu.
À lire ensuite
L’API de la passerelle
Une API de paiement dont la documentation est produite à partir de la même table qui sert les requêtes : la référence ne peut donc jamais décrire un point de terminaison que la plateforme n’a pas.
Page de paiement hébergée
Une page de paiement qui ne propose au payeur que les rails capables de conclure réellement son paiement, décidés au moment où il arrive plutôt qu’énumérés avec optimisme sur une page.
Raccordement au switch national
Un adaptateur écrit contre un contrat interne plutôt que contre un protocole, avec un simulateur qui reproduit les cas pénibles — un dépassement de délai après un effet financier, un rejet tardif contradictoire — avant qu’un raccordement réel n’existe.