Relier les retours entre boutique, ERP et paiement

Pour relier boutique, ERP et prestataire de paiement, un retour nécessite plus qu’un champ commun « terminé ». L’intégration doit identifier la ligne renvoyée, le mouvement de stock et l’état du remboursement associé. Définissez ces relations avant de développer les interfaces.

Rapprocher un cas complet

Une boutique fictive d’accessoires pour la maison a livré deux vases pour la commande O-86 et reçu le paiement. Un vase revient avec un bord ébréché. Dans cet exemple, un remboursement de 24 EUR est convenu pour ce vase. L’équipe prévoit le rapprochement suivant :

Le lien utilise les références des lignes et des opérations. Un même nom ou code article ne suffit pas lorsque cet article figure dans plusieurs commandes.

Définir un modèle interne d’intégration

L’enregistrement suivant est un modèle conçu pour ce cas fictif, pas un appel API d’un prestataire. Les quantités concernent le retour ; le montant est exprimé en centimes d’EUR.

{
  "returnId": "R-86",
  "orderReference": "O-86",
  "shopOrderLine": "OL-86-A",
  "shopFulfillmentLine": "FL-86-A",
  "erpDeliveryLine": "DL-86-A",
  "receivedQuantity": 1,
  "saleableStockDelta": 0,
  "refund": {
    "paymentReference": "PAY-86",
    "amountMinor": 2400,
    "currency": "EUR",
    "state": "requested"
  }
}

Les références relient la ligne de commande boutique, la ligne de livraison boutique et la ligne de livraison ERP initiale au paiement. Enregistrez aussi sur le dossier la référence de remboursement renvoyée par le prestataire. Si la ligne ne peut être identifiée sans ambiguïté, le dossier doit attendre une clarification au lieu d’être comptabilisé automatiquement par comparaison de noms.

Utiliser la bonne source pour chaque modification

Dans l’exemple, la boutique fournit le lien avec la ligne achetée. L’ERP confirme réception, résultat du contrôle et libération du stock. Le prestataire fournit l’état du remboursement. Le contrat de données précise ces responsabilités ; une autre répartition des systèmes peut nécessiter d’autres responsabilités.

Le ReturnLineItem de Shopify pointe vers une ligne de livraison Shopify ; l’intégration doit établir le lien avec la ligne ERP. La documentation de Refund précise que l’existence d’un enregistrement ne confirme pas à elle seule un mouvement d’argent réussi. Stripe décrit aussi des événements distincts pour création, modification et échec. L’intégration doit rapprocher les états réels du prestataire choisi de son modèle interne.

Un remboursement réussi ne doit donc modifier que l’état du paiement dans cet exemple. Il ne rend pas le vase abîmé vendable. Inversement, la réception de la marchandise ne rend pas automatiquement le remboursement réussi.

Contrôler le résultat attendu

Vérifiez le cas dans un environnement de test adapté : le retour partiel appartient à la bonne ligne, la variation de stock reste à 0 et les 2400 centimes sont liés au bon paiement. Quand le remboursement réussi est confirmé, son état change tandis que la marchandise reste bloquée. Une réponse de paiement ambiguë doit rester visible comme non résolue. Une notification répétée doit mettre à jour le même dossier. Le traitement technique des nouvelles tentatives exige aussi une stratégie d’idempotence adaptée.

Sources

• Shopify — ReturnLineItem, GraphQL Admin API

• Shopify — Refund, GraphQL Admin API

• Stripe — Refund and cancel payments