Lien de paiement ou checkout : lequel choisir
Deux façons d'encaisser en ligne, deux charges de travail très différentes. Les critères qui tranchent vraiment, sans jargon.
La question revient à chaque intégration : faut-il envoyer un lien de paiement, ou construire un tunnel de commande avec une session de checkout ? Les deux encaissent. Ce qui les sépare, c'est le travail que vous aurez à fournir et le contrôle que vous garderez sur le parcours.
Le lien de paiement : un appel, et vous encaissez
Vous créez un lien avec un montant et une description, vous le partagez, le client paie sur une page hébergée par ChariPay. Vous n'écrivez aucune page de paiement, vous n'hébergez aucune donnée de carte, et vous n'avez rien à faire certifier.
C'est le bon choix quand le paiement est un événement isolé plutôt qu'une étape dans un tunnel :
- une facture envoyée par e-mail ou par WhatsApp ;
- un devis accepté par téléphone ;
- une vente à distance sur les réseaux sociaux ;
- un encaissement au comptoir, avec le QR code ou l'affiche imprimée.
Le lien porte tout ce qu'il faut pour être suivi : votre propre identifiant de commande, une date d'expiration, et le statut de paiement que vous retrouvez dans le portail comme dans l'API.
Un commerçant qui vend sur Instagram et facture par WhatsApp n'a besoin de rien d'autre. Construire un tunnel de commande pour ce cas, c'est payer un mois de développement pour remplacer un copier-coller.
La session de checkout : le paiement dans votre tunnel
Ici, une commande de votre boutique devient une session. Vous redirigez l'acheteur vers la page de paiement, et il revient sur vos URL — une pour le succès, une pour l'échec.
C'est ce qu'il vous faut quand :
- le paiement s'inscrit dans un panier et un tunnel que vous maîtrisez ;
- vous devez afficher une page de confirmation à vous, avec vos produits et votre livraison ;
- votre système de commande doit basculer d'état au moment exact du paiement ;
- vous mesurez un entonnoir et voulez savoir où les acheteurs abandonnent.
La contrepartie est modeste : deux URL à exposer, et un traitement de webhook à écrire.
Le piège commun aux deux : croire la redirection
C'est l'erreur que nous voyons le plus souvent, et elle coûte cher.
Quand l'acheteur revient sur votre URL de succès, cela veut dire qu'il est revenu. Pas que le paiement est acquis. Entre les deux, il y a sa banque, une authentification 3-D Secure, parfois un délai — et un acheteur qui ferme son onglet trop tôt, ou un réseau mobile qui coupe.
La règle est simple et sans exception : la redirection sert à l'affichage, le webhook sert à la décision. Affichez un état d'attente au retour, et ne libérez la commande qu'à réception de l'événement de paiement.
Et le checkout direct ?
Une troisième porte existe : construire votre propre formulaire de carte et appeler directement les endpoints de checkout. Elle est ouverte, mais elle vous fait entrer dans le périmètre de conformité des données de carte — avec tout ce que cela implique en audit, en hébergement et en responsabilité.
Ne la prenez que si vous avez une raison précise que la page hébergée ne couvre pas. Dans la grande majorité des cas, elle n'apporte rien qu'un peu de style et beaucoup d'obligations.
Les critères, un par un
Le volume. Dix ventes par jour se gèrent très bien au lien : la création prend quelques secondes dans le portail. À cent ventes par jour, la création manuelle devient un poste de travail — c'est le signal du checkout, ou au minimum des liens créés par l'API.
Qui conclut la vente. Un humain en conversation avec le client ? Le lien s'insère naturellement dans l'échange. Un site qui vend seul, la nuit comprise ? Le checkout, évidemment.
Le montant. Fixe et connu d'avance — une formation, un abonnement, un produit unique — les deux conviennent. Variable selon le panier : le checkout le calcule ; le lien demanderait une création par vente.
L'équipe disponible. Le lien ne demande aucun développeur. La session de checkout demande une intégration côté serveur — modeste, mais réelle : création de la session, page de retour, traitement du webhook.
Le besoin de personnalisation. Le lien affiche votre nom et votre logo sur une page ChariPay. La session reprend vos couleurs dans votre tunnel. L'API directe, elle, vous laisse dessiner chaque écran — au prix de la responsabilité de l'ensemble.
Migrer de l'un à l'autre
Le choix n'engage pas pour toujours, et la migration est plus douce qu'on ne le croit : les deux produits partagent le même wallet, le même portail, les mêmes webhooks et le même export comptable. Passer du lien au checkout ne change ni votre trésorerie ni votre rapprochement — seulement la façon dont le paiement démarre.
Le chemin habituel : commencer au lien pour valider l'offre, brancher le checkout quand le volume le justifie, garder les liens pour les cas hors tunnel — une commande spéciale, une relance téléphonique, un événement. Les deux coexistent très bien, et c'est d'ailleurs l'état stable de la plupart des commerces : le checkout pour le flux, les liens pour l'exception.
En résumé
| Vous voulez… | Prenez |
|---|---|
| Encaisser une facture, un devis, une vente à distance | Le lien de paiement |
| Un paiement dans le tunnel de commande de votre site | La session de checkout |
| Un encaissement en espèces, en agence | Le lien de paiement, méthode espèces |
| Votre propre formulaire de carte | Le checkout direct — et un projet de conformité |
Dans tous les cas, commencez en sandbox : la clé de test ne peut pas toucher la production, et vous pouvez rejouer un parcours autant de fois que nécessaire avant d'ouvrir la vanne.
Écrit par Équipe ChariPay.