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.
Boutiques en ligne, places de marché, systèmes de facturation, sites de réservation et toute entreprise qui envoie ses clients payer ailleurs.
Activé sur ce déploiement.
Le problème
Une page qui aligne dix logos et échoue sur huit apprend aux clients à abandonner. Pire, elle échoue après qu’ils se sont engagés, c’est-à-dire au moment le plus coûteux pour les perdre.
Comment cela fonctionne
- Créez une intention de paiement ou une session avec le montant, la devise et votre référence.
- Envoyez le client vers l’adresse retournée, ou affichez le contenu QR retourné.
- La page détermine quels rails peuvent porter ce paiement, pour ce payeur, maintenant — et n’affiche que ceux-là.
- Au paiement, vous recevez une notification signée et le client revient sur votre page de succès.
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 rails proposés sont calculés par paiement, à partir du corridor, de la devise, du payeur et de la santé en temps réel de chaque connecteur.
- Un rail dont le disjoncteur est ouvert n’est pas proposé : un client n’est jamais envoyé sur un chemin qui échoue en ce moment.
- Sous le périmètre d’agrégateur, la page ne propose que le rail du switch et refuse le reste, plutôt que d’afficher des options que la plateforme n’a peut-être pas le droit d’exploiter.
- La session porte les lignes de vente avec la TVA lorsque le marchand les utilise : le client voit ce qu’on lui facture.
Ce que cela coûte
La page hébergée fait partie de la passerelle marchande ; elle n’est pas facturée à part. Vous payez le tarif du rail qui porte le paiement, affiché dans le tableau de bord.
Questions
Puis-je y mettre ma marque ?
La page porte le nom de votre entreprise, votre référence et vos lignes de vente, et renvoie le client vers vos propres adresses de succès et d’annulation.
Que se passe-t-il si un rail tombe en pleine vente ?
Un connecteur dont le disjoncteur s’est ouvert cesse d’être proposé : les nouveaux clients sont déroutés autour de lui plutôt que dedans. Un paiement déjà en cours suit sa propre machine d’états et n’est jamais marqué payé sans confirmation.
Suis-je obligé d’utiliser la page hébergée ?
Non. La même intention peut être affichée en QR, intégrée avec une clé publiable, ou pilotée entièrement depuis l’API si vous voulez construire l’écran vous-même.
À lire ensuite
Paiements BitriQR
Un seul code imprimé qui fonctionne pour un client avec l’application, un client avec seulement un appareil photo, et un client dont la banque n’a jamais entendu parler de BitriPay — parce que le code est de l’EMVCo en dessous et signé au-dessus.
Liens de paiement
Un lien que vous collez dans WhatsApp et qui se comporte comme une vraie page de paiement — réutilisable ou à usage unique, avec une expiration, une référence et une notification quand il est payé.
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.