La boutique est en ligne depuis trois semaines et les premières commandes arrivent. Puis un client de Genève appelle pour signaler qu'il ne trouve pas Twint parmi les moyens de paiement et qu'il a renoncé à valider son panier. Un client français s'étonne d'un montant qui ne correspond pas à ce qu'il attendait. Un troisième constate que la page de paiement lui propose une devise qu'il n'utilise pas. Le dirigeant regarde alors son thème et se demande ce qui cloche dans le design, alors que le problème ne se situe pas là du tout.
Ces incidents ne relèvent pas de l'apparence du site. Ils relèvent de trois décisions qui se prennent avant de choisir un thème : dans quelles devises vous encaissez, quels moyens de paiement vos clients attendent réellement de chaque côté de la frontière, et comment vos ventes se déclarent selon le pays de l'acheteur. Le choix entre WooCommerce et Shopify se tranche largement sur ces trois points, bien plus que sur le nombre de fiches produits.
Précisons d'emblée notre périmètre. Nous construisons et nous maintenons votre boutique, nous branchons les modules de paiement et nous testons les parcours d'achat réels. Nous ne sommes ni votre banque, ni votre fiduciaire, ni votre expert-comptable. Les obligations déclaratives, les taux applicables et le traitement des ventes transfrontalières se valident avec votre conseil, et nous refusons de donner un avis sur ces sujets. Les comptes chez les prestataires de paiement s'ouvrent à votre nom, avec vos coordonnées bancaires, et nous ne citons pas leurs commissions puisqu'elles ne sont pas nos prix.
Ce qui se décide avant de choisir un thème
Quatre sujets doivent être arbitrés par écrit, et ils conditionnent la suite du projet.
La première décision porte sur les devises. Vous affichez une seule devise, ou deux devises avec le même montant affiché, ou deux devises avec un taux de change réellement appliqué à l'encaissement. Ces trois options n'ont pas le même coût de mise en œuvre. Nous appliquons pour nos propres prestations la deuxième logique, où seul le symbole change, et nous l'expliquons dans notre article sur le fait de facturer en euros ou en francs. Votre boutique peut avoir besoin de la troisième, avec une conversion réelle, et les plateformes de commerce en ligne savent le faire à condition de le configurer.
La deuxième décision porte sur le traitement fiscal. Selon que votre acheteur se trouve en France ou en Suisse, selon la nature du produit et selon votre propre statut, le traitement diffère. Votre expert-comptable ou votre fiduciaire vous indique les règles applicables, et nous les traduisons ensuite en configuration dans la boutique. Cet ordre est important : nous ne devinons pas ces règles, nous les appliquons.
La troisième décision porte sur les moyens de paiement attendus. La carte bancaire, généralement via une passerelle de paiement, constitue le socle des deux côtés de la frontière. En Suisse, l'absence de Twint dans le tunnel de commande fait renoncer une partie des acheteurs, simplement parce qu'ils sont habitués à ce geste. Le virement ou la facture restent pertinents en vente entre professionnels, avec des délais de règlement à gérer. Chaque moyen ajouté représente un module à configurer, à tester et à surveiller dans le temps.
La quatrième décision porte sur la livraison transfrontalière. Un colis qui traverse la frontière suppose des documents, des délais et des frais qui ne se devinent pas et qu'aucune extension ne règle automatiquement. Si vous expédiez dans les deux pays, la question se traite en amont avec votre transporteur et votre conseil. Nous accompagnons ce type d'activité, et notre page consacrée aux e-commerçants frontaliers décrit la façon dont nous intervenons.
Les erreurs de configuration que nous corrigeons le plus souvent
Nous reprenons régulièrement des boutiques déjà en ligne, et les mêmes défauts reviennent d'un dossier à l'autre.
- Le compte du prestataire de paiement a été ouvert au nom personnel du gérant, avec son adresse privée et son compte bancaire personnel. Cela fonctionne au démarrage, puis cela devient un problème comptable, et un problème d'accès le jour où cette personne quitte l'entreprise.
- La boutique a été créée avec une devise par défaut qui n'est ni l'euro ni le franc, souvent parce que le modèle installé venait d'un catalogue international. Le changement de devise après les premières commandes est nettement plus délicat qu'avant.
- Le traitement fiscal a été laissé sur une valeur unique appliquée à tous les clients, sans distinction du pays de livraison. Le site encaisse alors des montants incohérents, et la régularisation se fait dans la douleur plusieurs mois plus tard.
- Le module de paiement est resté en mode test, ou a basculé en erreur après une mise à jour, et personne ne l'a remarqué parce que les commandes continuaient d'arriver par un autre canal. Les acheteurs, eux, sont partis sans rien dire.
- Le tunnel de commande a été alourdi par une dizaine d'extensions ajoutées au fil des mois, avec pour conséquence des pages lentes et des abandons de panier. Le sujet de la performance est traité dans notre article sur le score PageSpeed, et il vaut particulièrement pour une page de paiement.
- Les tests ont tous été effectués avec un montant symbolique, dans une seule devise, depuis un seul pays. Un tunnel qui fonctionne pour une commande à un euro peut échouer sur un panier réel, avec des frais de port et une adresse étrangère.
Nous posons volontairement peu d'extensions. Chaque module ajouté au tunnel de commande représente une dépendance supplémentaire, une mise à jour à suivre et un point de rupture possible le jour où son auteur cesse de le maintenir.
Ce que la plateforme prend en charge, et ce qui reste à votre charge
Une boutique hébergée en mode service intègre l'infrastructure, les mises à jour et une partie de la conformité technique du paiement. Vous payez un abonnement et vous vous occupez moins de la plomberie. Une boutique installée sur votre propre hébergement vous laisse la maîtrise complète du code et des données, au prix d'un suivi que quelqu'un doit assurer réellement.
Cette différence a une conséquence directe sur le contrat. Une boutique auto-hébergée exige une maintenance à 500 HT / an qui couvre le cœur, le thème, les extensions de paiement et la vérification périodique du tunnel. Une boutique en mode service demande moins de maintenance technique, mais elle demande toujours une surveillance fonctionnelle, parce qu'une mise à jour de la plateforme peut modifier le comportement d'un module. Nous précisons lequel des deux régimes s'applique avant la signature, et non après.
Notre méthode pour mettre en service les paiements
Nous commençons par un entretien de cadrage auquel nous vous demandons d'associer votre expert-comptable ou votre fiduciaire. Cette réunion produit un document court qui fixe les devises, le traitement fiscal par pays de livraison, les moyens de paiement retenus et les règles d'expédition. Sans ce document, la configuration se fait au jugé, et le jugé finit toujours par coûter plus cher que la réunion.
Nous ouvrons ensuite les comptes chez les prestataires de paiement à votre nom, avec vos identifiants et vos coordonnées bancaires. Vous en restez propriétaire, et notre accès reste révocable. Nous configurons la boutique en environnement de test, puis nous exécutons de vraies commandes : un panier français, un panier suisse, chaque moyen de paiement, un remboursement, une commande annulée. Nous vérifions au passage que les mails de confirmation partent effectivement et arrivent, ce qui n'est jamais acquis, comme nous l'expliquons dans notre article sur les formulaires dont le mail n'arrive pas.
Nous basculons enfin en production, avec une commande réelle de contrôle passée par vous, et nous mettons en place un point de vérification périodique dans le contrat de maintenance. La création se fait à distance, partout en France et en Suisse, à partir de 900 HT pour le socle du site et de 1000 HT pour la boutique elle-même, et notre page dédiée aux boutiques en ligne détaille les prestations disponibles.
Si votre tunnel de commande échoue côté suisse ou côté français, décrivez-nous précisément les deux tentatives, avec la devise, le moyen de paiement et le message affiché. Nous analysons le journal du module concerné et la réponse du prestataire de paiement, plutôt que de réinstaller le thème en espérant que le problème disparaisse.