Choisir le checkout d’un site e-commerce

Décrire le panier de référence

Choisissez un panier fréquent et un panier qui contient un cas moins simple : remise, quantité modifiée ou livraison différente. Vérifiez que votre serveur calcule et valide le montant final. La page de paiement doit afficher une devise et un contexte commercial cohérents avec la commande. Si le panier change, précisez quelle version est payable et comment l’ancienne demande devient inutilisable. Une comparaison faite uniquement sur une page de démonstration manque souvent ces transitions, alors qu’elles déterminent une grande partie du travail d’intégration.

Intégration et API

Vérifier les méthodes pour votre compte

Une méthode connue du public n’est pas nécessairement activée pour votre entreprise. Demandez au fournisseur quelles conditions concernent votre activité, les pays desservis et les devises prévues. Distinguez ce qui existe dans son catalogue de ce qui peut être utilisé par votre compte. Dans un checkout hébergé OrsunPay, les choix présentés suivent les méthodes admissibles et la connexion configurée. Ne promettez pas un moyen de paiement local sur la seule base de sa popularité ou d’un logo aperçu sur une autre boutique.

Page de paiement hébergée

Choisir où se déroule la saisie sensible

Le parcours peut utiliser une page hébergée ou un autre mode d’intégration documenté. Décrivez les redirections, le retour et les messages montrés au client. Dans le checkout OrsunPay, les données sensibles de carte sont saisies dans l’interface hébergée par le PSP. Cela ne dispense pas votre équipe de vérifier ses propres responsabilités et sa configuration. Évaluez le parcours complet sur les appareils utilisés par vos clients, y compris la possibilité de fermer la page ou d’interrompre une étape d’authentification.

Décider de la préparation côté serveur

La commande doit devenir préparée ou activée après le résultat vérifié, et non après une animation réussie dans le navigateur. Les guides Stripe et Mollie montrent comment les notifications et le statut serveur complètent le parcours visible. Une réponse tardive ne doit pas laisser une commande définitivement bloquée dans un état d’écran. Définissez un mécanisme de traitement répétable sans double action, ainsi qu’une procédure de recherche lorsque le client signale un paiement que l’équipe ne retrouve pas immédiatement.

Comparer le coût du fonctionnement quotidien

Le prix affiché ne décrit pas tout le travail nécessaire. Demandez comment retrouver une transaction, exporter les informations utiles, gérer les droits d’accès et identifier un incident. Les conditions du PSP et les frais logiciels doivent être évalués séparément. N’appliquez pas un tarif supposé à toutes les méthodes, devises ou opérations. Préparez plutôt un jeu de volumes et de scénarios représentatifs, puis faites confirmer les conditions correspondantes par chaque fournisseur avant de conclure qu’une solution sera moins coûteuse.

Définir une recette avec un responsable

Une recette utile décrit le résultat attendu pour chaque scénario et la personne qui le vérifie. OrsunPay conserve vos propres comptes et contrats PSP ; il apporte une intégration commune, des statuts et des notifications signées. L’offre actuelle ne comprend pas de cascade automatique ni d’optimisation de routage par les coûts. Une solution convient lorsqu’elle répond aux besoins constatés et reste exploitable lors d’un incident, pas lorsqu’elle promet abstraitement une meilleure conversion sans mesure de votre parcours.

• Vérifier le panier et la devise avant toute création.
• Tester une fermeture de page avant le retour.
• Traiter un résultat en attente puis confirmé.
• Empêcher une double préparation après notification répétée.
• Consigner le point de contact technique et le point de contact PSP.

Sources

• Documentation Stripe sur les webhooks
• Documentation Mollie sur les paiements