La plupart des détaillants omnicanaux reconnaîtront cette configuration : les commandes transitent par le système de gestion des commandes (OMS), les paiements par la plateforme de commerce électronique, et entre les deux, un pont reliant les deux systèmes a été construit. Cela fonctionne, tant que tout va bien. Et, soudainement, ce n'est plus le cas !
Le défi du middleware
Bien sûr, cela n'est pas surprenant, compte tenu des réalités quotidiennes. Une deuxième marque est ajoutée. Un nouveau marché. Un troisième pays. Un nouveau réseau de magasins. Soudain, notre pont transporte bien plus de poids qu'il n'a jamais été conçu pour supporter. Chaque opération post-achat, chaque capture, chaque remboursement et chaque annulation doivent être acheminés à travers différentes plateformes web qui n'ont aucune visibilité sur ce que l'OMS a décidé.
Un ensemble de scénarios familiers suit. Les équipes financières se connectent à quatre back-offices différents pour trouver un statut de paiement. Les commandes fractionnées deviennent un cas spécial. Les remboursements partiels deviennent un ticket de développement. Et chaque nouveau canal de vente signifie que quelqu'un doit réexpliquer la logique d'acheminement à zéro.
Ça semble cassé. Mais, en réalité, ce qui s'est réellement passé, c'est que tout est devenu bien plus complexe.
Comment surmonter les défis du middleware
Pour surmonter ces défis courants, il est judicieux de gérer les opérations post-achat de manière native. OneStock, par exemple, peut être connecté directement à votre fournisseur de paiement, comme Adyen, sans couche e-commerce intermédiaire.
Une approche native signifie aucun middleware, ce qui apporte ses propres avantages supplémentaires. Il n'y a, par exemple, aucun développement personnalisé à maintenir. Pas de cartographie fragile entre les statuts logistiques et les instructions de paiement. À la place, l'OMS et le fournisseur de services de paiement (PSP) s'expriment directement. Ce qui se passe au lieu de traitement se reflète immédiatement dans ce qui se passe au niveau du paiement.
Trois avantages commerciaux immédiats débloqués avec OneStock
1. Requêtes de capture lorsque cela a du sens pour votre entreprise
Vous pouvez placer une demande de capture à n'importe quel point de l'éditeur de flux de commande OneStock : à la confirmation d'expédition, à la livraison, ou à tout statut personnalisé que vous souhaitez définir. En d'autres termes, pas quand le site Web le décide, mais quand vos opérations l'exigent.
Pour les commandes fractionnées, chaque colis déclenche sa propre capture indépendamment.
Cela signifie plus d'approximations, et plus de corrections manuelles en fin de mois.
2. Un écran pour tout ce qui concerne les paiements
OneStock inclut une interface de paiement dédiée : tous les statuts, sur tous les canaux et toutes les commandes, en un seul endroit.
La réconciliation peut être déclenchée lorsqu'une commande est expédiée mais pas encore capturée.
La capture, le remboursement ou le remboursement partiel peuvent tous être exécutés directement à partir de cet écran, sans avoir besoin d'ouvrir une console PSP ou un back-office de marque. Les finances peuvent tracer ce qui se passe. Le service client peut agir en conséquence. Les demandes d'informations internes sont éliminées.
3. Éviter l'expiration des autorisations
Les autorisations de paiement ont une durée de vie limitée. Sur les cycles d'exécution longs, les précommandes, les commandes en rupture de stock ou les flux B2B complexes, cette durée de vie peut expirer avant l'expédition de la commande.
OneStock, en revanche, gère la tokenisation de manière native, de sorte que les autorisations sont automatiquement renouvelées avant leur expiration. Par conséquent, la commande s'expédie, la capture se déclenche, aucune intervention requise.
À quoi ressemble la capture d'ordre en pratique ?
Prenons l'exemple de Maria, directrice omnicanale chez un détaillant de mode européen couvrant quatre pays, deux places de marché et un réseau de magasins ajouté il y a dix-huit mois. Les opérations post-achat étaient gérées de la manière habituelle : les événements logistiques étaient redirigés via la plateforme de commerce électronique, traduits en instructions PSP et surveillés sur trois back-offices distincts.
Cela fonctionnait suffisamment bien quand l'entreprise était plus simple. Mais cela ne fonctionnait plus bien.
Lors des périodes de pointe, l'équipe réconciliait manuellement les statuts de paiement pour une part importante des commandes fractionnées. Cela signifiait recouper l'OMS, le tableau de bord PSP et le back-office de la marque pour déterminer ce qui avait été capturé, ce qui était en attente et ce qui avait besoin d'un remboursement. L'expiration des autorisations sur les précommandes était un casse-tête trimestriel. Et l’équipe technique venait d’apprendre que l’ajout d’un cinquième pays allait désormais nécessiter une nouvelle série de spécifications relatives à l’acheminement des paiements.
Maintenant, avec les connecteurs de paiement natifs d'OneStock, l'opération suit l'événement logistique. Cela se produit automatiquement, pour chaque canal, chaque type de commande et chaque scénario d'exécution. L'équipe de Maria configure le déclenchement de capture une fois par flux. La tokenisation s'exécute en arrière-plan. L'interface de paiement donne aux finances une vue unique de l'ensemble de l'opération.
Le prochain pays n'a pris qu'une semaine à mettre en place, pas tout un trimestre ; un excellent exemple de ce qui est réalisable quand le bon système contrôle les bonnes opérations.
Comment démarrer avec « Direct Payment Connection »
Dans OneStock, la connexion de paiement directe est configurée dans les paramètres du canal de vente et appliquée dans le flux de traitement des commandes. L'interface de gestion des paiements est accessible directement depuis le OneStock .
Des connecteurs natifs sont disponibles pour Adyen et d'autres grands fournisseurs de services de paiement.
👉 Obtenez une démo
