Caisse hébergée ou caisse sur mesure pour les paiements crypto
Caisse hébergée ou sur mesure pour les paiements crypto : ce que chacune implique, pourquoi Qvard passe par une page hébergée et ce que vous pouvez concevoir autour.
Tout service de paiement est confronté au même choix de conception : les clients paient-ils sur une page hébergée par le prestataire, ou dans une caisse que vous construisez vous-même ? Pour la crypto, la seconde option est bien plus lourde que pour les cartes. Ce guide explique la différence, pourquoi Qvard propose aujourd'hui une page hébergée, ce que vous pouvez encore façonner autour d'elle et ce qui doit exister pour qu'une caisse entièrement sur mesure ait du sens.
Deux façons de prendre un paiement
- Caisse hébergée. Vous créez un paiement et envoyez le client vers une page que gère le prestataire. Le prestataire affiche l'adresse, le montant exact et le statut ; vous recevez le résultat par notification.
- Caisse sur mesure. Le formulaire de paiement se trouve dans votre propre site ou application. Vous affichez les détails du paiement, suivez le statut et gérez chaque état que le client peut atteindre.
La caisse hébergée est plus rapide à lancer et moins risquée. La caisse sur mesure donne le contrôle total de l'apparence et du parcours, au prix de la construction et de la maintenance de tout ce que la page hébergée fait pour vous.
Ce qu'une caisse crypto doit faire
Une caisse par carte collecte surtout quelques champs et appelle une API. Une caisse crypto a davantage de tâches :
- afficher une adresse de paiement pour l'actif et le réseau choisis, avec le réseau à côté ;
- afficher un montant exact, figé assez longtemps pour que le client l'envoie ;
- laisser le client choisir un actif et un réseau, et expliquer la différence ;
- suivre le paiement sur la blockchain, y compris les paiements insuffisants et tardifs ;
- gérer des erreurs comme le mauvais réseau, avec un message clair.
Chacun de ces points est un endroit où une erreur coûte de l'argent au client. C'est l'argument le plus fort en faveur d'une page hébergée.
Pourquoi Qvard fonctionne aujourd'hui avec une page hébergée
Le parcours de paiement de Qvard est construit autour de la page hébergée. Vous créez un paiement avec un seul POST vers https://api.qvard.com/api/v1/payment, et la réponse contient un redirectUrl, l'adresse de cette page. Le client y choisit l'actif et le réseau, voit l'adresse et le montant exact, et paie ; le taux est fixé pendant une heure. Voir comment fonctionne redirectUrl dans la caisse crypto.
L'API publique est petite : elle crée un paiement, vérifie si un moyen de paiement est prêt et envoie un paiement sortant. Elle ne vous remet pas d'adresse de dépôt à afficher vous-même, et ne propose aucune route pour lire le statut d'un paiement ; vous ne pourriez donc pas suivre un paiement depuis votre propre page. La caisse intégrée et les SDK sont prêts ; cette API ne prend toujours pas en charge de caisse crypto entièrement sur mesure, avec votre propre affichage d'adresse et suivi de statut.
Ce que vous pouvez encore concevoir vous-même
La page hébergée fait la partie difficile. L'expérience autour est la vôtre :
- L'étape d'avant. Le choix « Payer en crypto », l'explication de ce qui va se passer, les frais et la règle de remboursement, avec vos mots et votre design.
- L'étape d'après. Une page de commande qui affiche le statut réel (en attente, insuffisant, payé), se rafraîchit pendant l'attente et dit au client quoi faire ensuite. Les URL de retour ne sont pas encore disponibles ; c'est donc par cette page que le client revient.
- Les messages. Les e-mails que vous envoyez quand la commande est passée, payée ou que le paiement est insuffisant.
- La logique métier. Quels statuts libèrent la marchandise, ce que vous faites d'un paiement insuffisant, comment vous remboursez.
Si c'est bien fait, le client voit une boutique cohérente avec une page de paiement au milieu, et c'est ce dont la plupart des commerçants ont besoin.
Comment choisir
- Choisissez la caisse hébergée si vous voulez lancer bientôt, si votre équipe est petite, si vous ne voulez pas être responsable des cas limites de la blockchain, ou si vous avez simplement besoin que cela marche. C'est ce que Qvard prend en charge aujourd'hui.
- Utilisez la caisse intégrée si une expérience fluide dans la page est essentielle à votre produit. Sa logique de facture est la même que sur la page hébergée : la logique de commande, le webhook et la page de commande restent inchangés.
- Ne développez pas votre propre génération et surveillance d'adresses pour obtenir un aspect sur mesure. C'est la façon la plus lourde et la plus risquée d'acheter un design.
Quoi que vous choisissiez, le côté serveur est le même : créer un paiement avec votre numéro de commande comme id, ne marquer la commande comme payée qu'à partir du webhook (exactement HTTP 200, sans danger en cas de double exécution) et effectuer le rapprochement. Voir comment accepter les paiements crypto sur un site web et API de paiement crypto pour les développeurs. Une facture de démonstration montre la page hébergée.
FAQ
Puis-je intégrer le formulaire de paiement Qvard dans ma propre page ?
Oui. La caisse intégrée ouvre la fenêtre de paiement Qvard au-dessus de votre page, en modale ou en bloc intégré. La page de paiement hébergée reste disponible.
Puis-je afficher l'adresse de paiement sur ma propre page ?
L'API ne renvoie pas d'adresse de dépôt à afficher, et ne propose aucune route pour lire le statut du paiement ; l'adresse et le statut vivent donc sur la page hébergée.
Que puis-je personnaliser ?
Les étapes avant et après la page de paiement : le choix à la caisse, les explications, la page de statut de commande et vos e-mails, ainsi que votre propre logique métier.
Passer plus tard à une caisse intégrée cassera-t-il mon intégration ?
Prévoyez que le côté serveur reste le même : créer le paiement avec votre id de commande, marquer les commandes payées depuis le webhook et rapprocher. Seule la partie front-end autour du paiement changerait.
