Le flux en un coup d’œil
- Configuration du compte et du paiement
- Vérification de transaction
- Commande, remboursement et réconciliation
Prérequis avant réalisation
- Compte marchand Viva.com
- Extension officielle ou API compatible
- Règles de stock et de remboursement
En un coup d’œil
La connexion Viva.com organise le paiement et informe correctement la boutique du résultat de la transaction.
Ce que couvre l’intégration
Viva.com propose des extensions officielles pour WooCommerce, Shopify, PrestaShop, OpenCart, Magento et d’autres plateformes. Le choix dépend de la version et du compte marchand. Les méthodes affichées sont confirmées dans l’environnement réel. Une installation réussie ne termine pas les tests de commande. Il faut décrire le fonctionnement de l’entrepôt, de l’ERP et des notifications après succès, échec ou attente.
Le flux de données en pratique
La commande est liée à l’identifiant de transaction et le résultat vérifié selon la solution choisie. Seul un état autorisé déclenche les tâches suivantes, comme réservation et préparation. Les remboursements ont leur propre contrôle et ne se réduisent pas à changer le statut de commande. Lors d’une migration, l’équipe doit savoir gérer les anciennes transactions sans laisser deux options actives contradictoires pour les nouveaux achats.
Erreurs et méthode de reprise
Le problème apparaît souvent lorsqu’un client paie sans revenir à la dernière page. La commande ne doit pas dépendre uniquement du navigateur. Il faut vérifier le résultat, contrôler les attentes et éviter la double exécution. Un remboursement ne peut dépasser le montant autorisé pour sa transaction. Le service client voit clairement paiement et commande pour ne pas redemander un paiement qui nécessite seulement une réconciliation.
Définir le cadre opérationnel
La migration vers Viva.com doit inclure anciennes et nouvelles transactions. L’équipe documente la solution de chaque paiement et sa procédure de remboursement. Le nouveau parcours est testé sans confusion avec les réglages historiques. Montant, référence et statut sont lisibles par le service client. Sans retour à la confirmation, le contrôle convenu intervient. Changer de prestataire ou d’extension ne justifie ni perte d’historique ni nouvelle facturation pour corriger une attente interne.
Exemple : nouveau paiement, anciens remboursements
Une boutique de vêtements change de paiement tout en recevant des retours d’anciennes commandes. Les anciennes références restent accessibles par le bon outil. Un nouvel achat utilise la configuration active sans options contradictoires. Si le navigateur ferme après paiement, la vérification actualise l’achat indépendamment de la navigation. Le remboursement partiel est un mouvement distinct. Le service client voit payé, remboursé et montant associé au statut actuel.
Tests de paiement et de transition
Nous testons succès sans retour du navigateur, transaction échouée et notification répétée. L’achat doit déclencher une seule fois les tâches convenues et préserver la référence. Pour une migration, nous testons séparément remboursements anciens et nouveaux, complets et partiels si prévus. L’entrepôt ne prépare rien depuis un état non confirmé. L’équipe approuve visibilité des données et droits de remboursement. Une procédure traite les paiements réussis n’ayant pas encore actualisé la commande.
Contrôles d’acceptation avant exploitation
- Statut correct sans redirection du navigateur
- Une exécution par paiement
- Contrôle des anciennes et nouvelles transactions
DU GUIDE À LA PRATIQUE
Un plan concret pour votre plateforme.
Dites-nous où votre plateforme rencontre des difficultés et ce qui doit être amélioré. Notre équipe relie le diagnostic à des interventions précises sur le code, les performances et l’infrastructure.
Examinons votre plateforme