E-commerce

Paiements crypto pour les boutiques de biens numériques

Comment une boutique de clés, comptes, téléchargements et abonnements accepte la crypto : livraison, paiements partiels, webhooks répétés et promesses aux clients.

Une boutique qui vend des clés de licence, des comptes de jeu, des téléchargements ou des accès a une propriété inhabituelle : le produit est livré à l'instant où l'argent arrive, sans personne entre les deux. C'est précisément pour cela que la crypto lui convient, et précisément pour cela que les détails du flux de paiement comptent. Ce guide explique ce qui change, comment relier la livraison au statut du paiement et quelles erreurs font perdre du stock aux boutiques numériques.

Pourquoi biens numériques et crypto vont ensemble

Trois propriétés des biens numériques correspondent au fonctionnement des paiements crypto :

  • La livraison est instantanée, le paiement doit donc l'être aussi. Un client qui attend sa clé ne veut pas attendre le règlement d'une banque. Un paiement crypto est définitif une fois confirmé par le réseau, et votre système peut livrer immédiatement.
  • L'audience est déjà là. Les acheteurs de clés logicielles, d'objets de jeu, d'accès VPN, d'hébergement et de produits similaires détiennent souvent des stablecoins et préfèrent les utiliser pour payer, y compris des clients de pays où les cartes de votre marché ne fonctionnent pas.
  • Pas de rétrofacturations par carte. L'expéditeur ne peut pas annuler un transfert crypto. Pour une boutique qui a été échaudée par des paiements par carte contestés sur des articles bon marché livrés instantanément, c'est un vrai changement. Cela signifie aussi qu'un remboursement est une décision de votre part et un transfert que vous envoyez vous-même ; rédigez donc votre politique de remboursement avant le lancement.

Le prix reste simple : vous le fixez en dollars américains et le client paie l'équivalent dans l'actif et le réseau qu'il choisit sur la page de paiement.

Le flux du panier au produit livré

Le parcours d'une commande ressemble à ceci :

  1. Le client ajoute un produit et saisit une adresse e-mail (ou se connecte).
  2. À la caisse, il choisit « Payer en crypto ». Votre serveur crée un paiement pour la commande et reçoit un lien vers la page de paiement hébergée.
  3. Vous redirigez le client vers cette page. Il choisit un actif et un réseau et paie le montant exact depuis son propre portefeuille.
  4. Lorsque le paiement est terminé, la passerelle appelle votre webhook.
  5. Votre serveur marque la commande comme payée, prend une clé ou accorde l'accès, puis l'envoie par e-mail et l'affiche sur la page de commande.

Votre boutique ne génère jamais d'adresse, ne surveille aucune blockchain et ne compare aucun montant. Elle fait deux choses : créer un paiement et réagir au statut final. La version pas à pas avec du code se trouve dans comment accepter les paiements crypto sur un site web.

Créez le paiement avec votre propre numéro de commande

Créez le paiement depuis votre backend avec un seul POST vers https://api.qvard.com/api/v1/payment. La requête contient votre clé dans l'en-tête Authorization: Bearer et un JSON avec le numéro de commande dans id, le price en dollars américains et, en option, un paymentSystemId si vous voulez que la page s'ouvre avec un actif et un réseau précis. La réponse est 201 avec un redirectUrl.

Utilisez un numéro de commande qui existe dans votre système avant le paiement, et un seul par achat. Si la requête expire et que vous la renvoyez avec le même id pour le même moyen de paiement, vous récupérez le paiement existant au lieu d'en obtenir un second ; réessayer est donc sans risque.

Ne créez le paiement qu'une fois que le client a cliqué sur payer, pas à la constitution du panier. Sinon vos paniers abandonnés apparaissent comme un tas de paiements impayés.

Livrez seulement à paiement complet, et une seule fois

C'est la règle qui protège votre stock. Un paiement a quatre statuts : wait (créé), partial (le client a envoyé moins que requis), completed (le montant complet est arrivé) et rejected. Qvard appelle votre webhook lorsqu'un paiement est terminé, avec l'id que vous avez envoyé et le status.

Deux exigences en découlent pour votre gestionnaire :

  • N'agissez que sur completed. Ne remettez jamais une clé parce que le client est revenu sur votre site, ni pour un montant partiel. La preuve du paiement, c'est le webhook, pas le navigateur.
  • Soyez idempotent. Le webhook est renvoyé jusqu'à ce que votre point de terminaison réponde avec exactement HTTP 200 (cinq tentatives en environ six minutes), et une nouvelle tentative peut arriver après la réussite de la première. Remettez la clé et marquez la commande comme livrée dans une seule transaction de base de données, et ignorez les commandes déjà livrées. Sinon, un paiement peut vous coûter deux clés.

Vérifiez la signature X-Qvard-Signature de chaque webhook : HMAC-SHA256 avec votre clé secrète, comparée en temps constant ; rejetez ce qui ne correspond pas. Plus de détails dans comment sécuriser les webhooks de paiement crypto.

Node.jsdeliver.js
// Called from the Qvard webhook handler after the X-Qvard-Signature check.
async function onQvardEvent({ id, status }) {
  const order = await db.orders.findById(id);
  if (!order) return;                          // unknown order: ignore

  if (status !== 'completed') return;          // deliver only on a full payment
  if (order.deliveredAt) return;               // the webhook can arrive twice

  // One transaction: take a key and mark the order, so a retry cannot take a second key.
  await db.transaction(async (tx) => {
    const key = await tx.licenseKeys.takeFree(order.productId);
    await tx.orders.update(order.id, { state: 'paid', deliveredAt: new Date(), keyId: key.id });
    await mailer.send(order.email, 'Your purchase', 'Key: ' + key.value);
  });
}

Montrez au client ce qui se passe

Les URL de retour après paiement ne sont pas encore disponibles ; le client qui a payé revient donc sur votre site de lui-même, souvent quelques secondes avant que votre webhook soit traité. Préparez ce moment :

  • Donnez à chaque commande une page qui affiche le statut actuel : en attente de paiement, payée et livrée, ou un problème.
  • Faites en sorte que la page se rafraîchisse seule tant que le statut est en attente, pour que la clé apparaisse sans recharger.
  • Envoyez aussi la clé par e-mail. Les gens ferment les onglets, et l'e-mail est la copie qu'ils chercheront plus tard.
  • Si la commande n'est pas encore marquée payée, dites-le clairement et demandez au client de ne pas payer deux fois.

La plupart des tickets de support dans les boutiques numériques sont « j'ai payé et je n'ai rien reçu ». Une page de statut et un e-mail les réduisent plus que tout.

Sous-paiement et commandes expirées

Les clients crypto envoient parfois un peu moins que requis, parce que des frais de retrait d'une plateforme d'échange ont été déduits du montant, ou parce qu'ils paient plus tard que prévu. Décidez quoi faire avant que cela n'arrive.

  • Paiement partiel. Le statut est partial. Ne livrez pas. Le choix habituel est de garder la commande ouverte et de demander au client d'envoyer le reste, ou de rembourser et d'annuler. Choisissez une option et informez le client sur la page de commande.
  • Taux et durée. Le taux de la page de paiement est fixé pendant une heure, le montant ne bouge donc pas pendant que le client paie. Réservez le stock de la commande au moins aussi longtemps et libérez-le si la commande n'est jamais payée.
  • Stock limité. S'il ne reste qu'une clé, réservez-la à la création du paiement et libérez-la à l'expiration ; sinon, deux clients peuvent payer la même clé.

Gardez une logique simple. Une boutique à exactement trois issues (payé, partiel, non payé) est plus facile à gérer qu'une boutique avec une douzaine de cas particuliers.

Que dire aux clients

Une page de paiement claire convertit mieux qu'une page ingénieuse. Près du bouton, indiquez :

  • quels actifs et réseaux vous acceptez (voir les monnaies prises en charge) et que le client doit payer sur le réseau choisi sur la page de paiement ;
  • que la livraison est automatique une fois le paiement terminé, et où la clé apparaîtra ;
  • votre règle de remboursement en une phrase, puisque le client ne peut pas annuler un paiement crypto.

Indiquez aussi le prix en dollars et laissez la page de paiement afficher le montant exact dans l'actif choisi. N'affichez pas vous-même le montant en crypto sur la fiche produit ; il varie avec le taux.

Ce qui est prêt chez Qvard aujourd'hui, et ce qui ne l'est pas

Soyez lucide sur ce que vous intégrez. Qvard fonctionne via son API : votre boutique crée le paiement et reçoit le webhook. Il n'existe pas encore de plugin prêt à l'emploi pour les plateformes de boutique, les liens de paiement et un sandbox séparé sont en développement, et les clients reviennent sur votre site d'eux-mêmes après avoir payé. Pour une boutique qui dispose d'un développeur, ou d'une heure de freelance, c'est un petit morceau de code. Consultez la documentation développeur et l'aperçu des intégrations, et ouvrez une facture de démonstration pour voir ce que verra votre client.

Côté argent, les fonds restent sur votre solde Qvard et vous les retirez vers votre propre portefeuille ; le retrait ne coûte que les frais de réseau, et il n'y a pas d'abonnement. Le retrait vers un compte bancaire en monnaie fiat n'est pas disponible.

FAQ

Puis-je livrer le produit automatiquement après un paiement crypto ?

Oui. Qvard appelle votre webhook lorsque le paiement est terminé, et votre serveur peut alors prendre une clé ou accorder l'accès et l'envoyer au client. Ne livrez que sur le statut completed et faites en sorte que le gestionnaire puisse s'exécuter deux fois sans risque.

Que se passe-t-il si le client envoie moins que le montant complet ?

Le paiement reçoit le statut partial et aucun webhook de fin n'est envoyé. Ne livrez pas. Demandez au client d'envoyer le reste ou remboursez-le, selon votre politique.

Y a-t-il des rétrofacturations avec les paiements crypto ?

Non. L'expéditeur ne peut pas annuler un transfert crypto. Cela vous protège des paiements par carte contestés, mais cela signifie aussi que c'est à vous d'envoyer les remboursements ; définissez donc une politique de remboursement dès le départ.

Puis-je fixer les prix en dollars ?

Oui, le prix est fixé en dollars américains. Le client paie l'équivalent dans l'actif et le réseau qu'il choisit sur la page de paiement, à un taux fixé pendant une heure.

Existe-t-il un plugin pour ma plateforme de boutique ?

Pas encore. Aujourd'hui l'intégration passe par l'API : une requête pour créer un paiement et un webhook pour recevoir le résultat.

Articles similaires

Articles similaires