Paiement sur le site en 2026 : checkout, lien de paiement et une page merci qui ne ment pas

La requête qui amène déjà du monde ici, c’est « paiement bot Telegram ». La suivante est plus calme et plus large : encaisser sur une page à eux. Un numéro de carte en Direct, une capture de virement, un fil « j’ai payé, vérifiez » — ce n’est pas de l’encaissement. C’est de l’exploitation non payée. Un checkout sur le site, c’est le même travail qu’un bot de paiement, dans une URL que Google classe et qu’un inconnu ouvre sans messagerie.

J’ai déjà écrit comment factures et webhooks tournent dans Telegram. Ici, le jumeau site : checkout hébergé, lien de paiement, Apple Pay sur un landing, reçu fiscal après paid. Même backend. Autre porte.

1. Trois formes de paiement sur un site (en choisir une, puis grandir)

Le jour un, pas besoin d’un panier. Un chemin qui crée une commande pending, ouvre une vraie page d’acquiring, et ne revient qu’après le webhook paid.

• Lien de paiement / bouton facture : un SKU, un prix, « Payer » ouvre Monobank ou LiqPay. Pour un prof, un acompte, une heure de conseil. La page est l’offre ; le lien est la caisse.
• Landing + checkout : un cours, un pack, une waitlist qui devient un débit. Nom, e-mail, montant, puis paiement hébergé. Pas encore de catalogue. C’est ça, « il me faut le paiement sur le site ».
• Checkout boutique : catalogue, variantes, panier, livraison, puis payer. Seulement si SKU et expédition existent déjà. Commencer par ça, c’est une marque à quatre produits qui brûle deux mois avant la première commande payée.

2. Ne choisissez pas un logo. Choisissez qui a déjà le portefeuille

Un second bouton que personne n’utilise n’est pas « plus de conversion ». C’est un ticket support. Quel acquiring brancher - Mono, LiqPay, Stripe - je l’ai déjà comparé dans le guide paiement Telegram. Sur un site, la seule décision en plus : l’inconnu venu d’Ads ou Maps paie avec ce qu’il a déjà dans le téléphone. Une méthode pour ce portefeuille. Apple Pay et Google Pay passent dessus ; c’est pour ça qu’un acompte se termine dans le tram au lieu de mourir au numéro de carte.

3. Ce qui casse sur un site et qu’un bot ne voit jamais

Le pipeline facture-webhook-livraison est le même que dans l’article bot. Je ne le recopie pas. Une URL publique ajoute trois pannes qu’un chat n’a pas.

• /success est une page merci, pas payé. J’ai vu des boutiques marquer paid parce que le navigateur y atterrissait après retour arrière, ou parce que l’app banque revenait sur un onglet mort. Affichez « nous confirmons le paiement ». Le webhook bascule le statut.
• Le secret marchand reste sur le serveur. Une page Next.js qui crée la facture dans le navigateur fuit la clé dans le bundle client. C’est un bug de site. Un bot n’envoie pas ce fichier au client.
• Le retour depuis l’app banque peut tuer l’onglet. L’acheteur croit avoir payé ; votre UI a disparu. E-mail ou SMS avec le même id commande, et une page merci qui lit le statut côté serveur, c’est la reprise. Telegram a déjà le fil. Un site non.

4. Un reçu fiscal n’est pas un PDF tapé à la main

Si vous êtes FOP ukrainien et vendez des biens ou beaucoup de services, le webhook banque ne suffit pas. Après paid, le serveur appelle Checkbox ou Vchasno.Kasa, l’acheteur reçoit le PDF fiscal sur la page merci ou par e-mail. Un humain qui tape le РРО après chaque ping Stripe, c’est comme ça que les soirées disparaissent.

5. Pourquoi le checkout meurt sur un téléphone

La plupart du trafic « paiement sur le site » paiera sur un écran de cinq pouces. Les pannes que je répare ne sont pas exotiques.

• Landing lent : si le bouton payer apparaît après trois secondes de layout shift, une part des acheteurs prêts est partie. Les Core Web Vitals sont une feature du checkout.
• Un formulaire qui demande un compte complet avant que le montant soit clair. Nom et téléphone (ou e-mail) suffisent pour le reçu. Un compte, c’est un produit plus tard.
• Pas d’Apple Pay / Google Pay sur iOS et Android. Taper une carte dans Safari dans le tram, c’est comme ça que l’acompte fuit.
• Contre-remboursement par défaut. Ça a l’air gentil. Ça ramène le travail non payé dont vous fuyiez : confirmer, relancer, no-show.

6. Site et Telegram : un grand livre, deux portes

L’article populaire de ce blog, c’est un bot Telegram de paiement. Ce canal reste la bonne boîte en Ukraine. Une mauvaise homepage. Un inconnu venu de Google Ads ou Maps ne lance pas un bot pour apprendre le prix. Il ouvre une page. Qui vous écrit déjà sur Telegram paie dans Telegram. Qui ne connaît pas encore le nom paie sur le site. Les deux tapent le même pipeline : pending → facture → webhook → fiscal → livraison.

Conclusion : mettez la caisse sur une URL à vous

Si l’argent circule encore comme un numéro de carte dans un chat, l’upgrade n’est pas un plugin. Une commande pending, Mono ou LiqPay ou Stripe, Apple Pay sur mobile, un webhook qui fiscalise, une page merci qui ne ment pas. Je construis ça en senior web engineer sur Next.js - le même pipeline peut ouvrir une facture Telegram pour ceux qui vivent déjà dans la messagerie. Écrivez via le formulaire ce que vous vendez et où siège l’acheteur (Ukraine ou étranger). On cadrera le plus petit checkout qui encaisse un vrai paiement ce mois-ci.