Les identifiants ne correspondent pas parce que Shopify et Stripe n'exportent pas la même chose.
Les exports CSV de commandes Shopify décrivent des commandes. Les exports CSV de transactions Stripe décrivent des paiements, des captures, des remboursements ou des mouvements de solde. Si vous tentez de faire correspondre #1042 de Shopify avec ch_3P8x... de Stripe, les fichiers ne sont pas en cause. Vous comparez un numéro de commande à une ligne de paiement.
Pour rapprocher des commandes Shopify et des transactions Stripe en CSV, il faut d'abord trouver la clé commune aux deux fichiers. Le rapprochement des lignes ne vient qu'ensuite.
Quelles valeurs peuvent réellement se correspondre
Avant de nettoyer les colonnes ou d'écrire des formules, identifiez les champs que vous comparez.
| Ce que vous voyez à l'écran | Tel que Shopify le stocke | Tel que Stripe le stocke | Résultat du rapprochement |
|---|---|---|---|
#1042 | Name dans l'export de commandes Shopify | id du type ch_3P8x... | Aucune correspondance. Le premier est un numéro de commande. Le second est un identifiant de prélèvement. |
6721948832513 | Id dans l'export de commandes Shopify ou Order dans l'historique des transactions | id du type ch_3P8x... | Aucune correspondance. L'identifiant interne de commande Shopify n'est pas le même objet que l'identifiant de transaction Stripe. |
c1027508764856.2 | Une entrée dans Payment References | La même référence de prestataire dans un export lié à Stripe ou un champ de métadonnées | Correspondance directe, si cette référence exacte existe des deux côtés. |
1042 | Numéro de commande Shopify nettoyé depuis Name après suppression du # | metadata[order_number] ou champ de métadonnées Stripe équivalent | La correspondance fonctionne si les métadonnées ont été écrites et exportées. |
$84.20 le même jour | Total et Paid at | Amount et Created | Risqué. Les commandes en double, les nouvelles tentatives, les remboursements et les décalages horaires génèrent de fausses correspondances. |
Ce tableau résume le problème dans son ensemble.
La plupart des rapprochements échouent parce que l'on utilise la première ligne du tableau en s'attendant à ce qu'elle se comporte comme la troisième ou la quatrième.
Shopify propose plusieurs références de commande
Shopify exporte plusieurs identifiants, et chacun a une fonction différente.
| Champ Shopify | Ce qu'il représente | Quand l'utiliser |
|---|---|---|
Name | Le numéro de commande visible dans Shopify, souvent précédé de # | À utiliser quand les métadonnées Stripe stockent le numéro de commande, ou quand vous avez besoin d'une référence lisible |
Id | L'identifiant interne de commande Shopify | À utiliser uniquement si ce même identifiant interne a été transmis aux métadonnées Stripe ou à un autre champ relais |
Payment ID | Un identifiant côté paiement envoyé par Shopify pour les paiements aboutis ou en attente | À utiliser quand votre export Stripe inclut la même référence côté paiement |
Payment References | Tous les identifiants de paiement liés à la commande, y compris les paiements refusés, les remboursements et les captures | À utiliser quand une commande comporte plusieurs événements de paiement et que vous avez besoin de l'historique complet, pas seulement du dernier paiement abouti |
C'est pourquoi deux personnes qui exportent la même commande depuis Shopify peuvent obtenir des résultats de rapprochement différents.
Un export est structuré autour des commandes. Un autre est structuré autour des transactions. L'export de l'historique des transactions donne une ligne par événement de paiement capturé, pas une ligne par commande. Il ne couvre pas non plus tous les états possibles de la passerelle de paiement. Si vous comparez des autorisations, des nouvelles tentatives ou d'autres événements de paiement absents de cet export, le fichier Shopify que vous avez téléchargé ne fonctionne pas au même niveau de détail.
La première décision n'est donc pas « Quelle formule dois-je utiliser ? » C'est « Est-ce que je rapproche des lignes de commandes avec des lignes de commandes, ou des lignes de paiements avec des lignes de paiements ? »
Si vous ignorez cette question, vous vous retrouvez dans la même situation que celle décrite dans pourquoi le rapprochement des commandes Shopify avec les virements Stripe est si long, où un fichier est groupé par commande et l'autre par activité de règlement.
Stripe exporte les objets de paiement, pas les commandes Shopify
Les CSV Stripe sont généralement construits autour des identifiants propres à Stripe :
- les identifiants de prélèvement
- les identifiants d'intention de paiement
- les identifiants de remboursement
- les identifiants de transaction de solde
- les enregistrements liés aux virements
Ce sont des identifiants valides. Ce ne sont pas des identifiants de commandes Shopify.
Cette distinction est importante parce qu'une commande Shopify peut générer plusieurs enregistrements Stripe :
- une tentative de paiement échouée
- un prélèvement abouti
- une capture
- un remboursement
- un litige ou un ajustement
Si votre fichier Shopify contient une ligne de commande et votre fichier Stripe en contient trois pour cette même commande, le rapprochement ligne par ligne échouera, même si les données sont exactes.
C'est là que les métadonnées deviennent essentielles. Si Stripe dispose d'un champ de métadonnées tel que shopify_order_id ou order_number, ce champ peut servir de pont vers Shopify. Mais certains exports Stripe n'incluent pas les métadonnées par défaut : la valeur peut exister dans l'objet Stripe et être absente du CSV téléchargé.
C'est ce qui mène à une conclusion erronée répandue :
« Stripe n'a pas la référence Shopify. »
Parfois, Stripe l'a bien. C'est simplement votre export qui ne l'inclut pas.
Constituez la table de correspondance avant de commencer tout rapprochement
Un rapprochement fiable nécessite une clé commune stable. Sans elle, vous ne rapprochez pas des enregistrements. Vous supposez en vous basant sur les montants et les dates.
La bonne méthode consiste à commencer par construire une petite table de correspondance.
| Colonne de travail | Source | Utilité |
|---|---|---|
shopify_order_number_clean | Champ Name de Shopify, sans le # | Permet de comparer avec les métadonnées Stripe qui stockent 1042 plutôt que #1042 |
shopify_internal_order_id | Champ Id de Shopify ou Order de l'historique des transactions | Utile uniquement si le même identifiant interne existe côté Stripe |
shopify_payment_reference_single | Une valeur isolée depuis Payment References | Évite qu'une cellule Shopify contenant plusieurs références ne masque plusieurs tentatives de paiement |
stripe_transaction_id | Champ id de Stripe | L'identifiant natif de la transaction Stripe |
stripe_metadata_order_number | Export des métadonnées Stripe, si disponibles | Souvent le chemin le plus direct vers le champ Name de Shopify |
stripe_metadata_shopify_order_id | Export des métadonnées Stripe, si disponibles | Chemin direct vers l'identifiant interne de commande Shopify |
amount et timestamp | Les deux fichiers | Champs de vérification seulement, jamais votre clé de liaison principale |
Trois règles font fonctionner cette approche.
1. Divisez `Payment References` en une référence par ligne.
Si Shopify vous donne c1027508764856.1 + c1027508764856.2, ce n'est pas une référence. C'en est deux. L'une peut représenter une tentative échouée et l'autre le paiement abouti. Si vous les laissez dans une seule cellule, vous ne pouvez plus rapprocher chaque événement correctement.
2. Gardez le numéro de commande lisible séparé des identifiants de paiement.
#1042 est utile pour la vérification. Ce n'est pas la même catégorie d'identifiant que ch_3P8x.... Ne remplacez pas l'un par l'autre dans une colonne « nettoyée ». Conservez les deux.
3. Normalisez le format sans perdre le sens.
Supprimez le # des numéros de commandes Shopify si les métadonnées Stripe stockent des chiffres seuls. Supprimez les espaces superflus. Conservez les caractères initiaux dans les références de paiement. Une valeur qui commence par c ou ch_ vous indique le système qui l'a générée. Ne la tronquez pas.
L'ordre de rapprochement qui fonctionne en pratique
Une fois la table de correspondance constituée, rapprochez dans cet ordre.
1. Rapprochez les références de paiement entre elles
Si le champ Payment ID de Shopify ou une valeur isolée de Payment References apparaît du côté Stripe, utilisez-la en premier. C'est ce qui se rapproche le plus d'une véritable clé de transaction inter-systèmes.
C'est le cas idéal, car il relie directement l'événement de paiement sans avoir à supposer quoi que ce soit à partir des montants.
2. Rapprochez l'identifiant interne de commande Shopify avec les métadonnées Stripe
Si les métadonnées Stripe contiennent l'identifiant interne de commande Shopify, rapprochez le champ Id de Shopify ou Order de l'historique des transactions avec ce champ de métadonnées.
C'est une méthode solide parce que les identifiants internes sont stables. La limite : le champ doit avoir été écrit dans Stripe au moment du paiement et inclus dans l'export.
3. Rapprochez le numéro de commande Shopify avec les métadonnées Stripe
Si les métadonnées Stripe stockent le numéro de commande plutôt que l'identifiant interne, nettoyez le champ Name de Shopify pour que #1042 et 1042 ne divergent pas à cause du format seul.
Cette approche convient bien à la vérification et aux rapports destinés aux clients, car le numéro de commande est lisible. Elle est moins fiable qu'un identifiant interne quand différents systèmes formatent les noms de commandes différemment.
4. Utilisez les montants et les horodatages uniquement pour vérifier les lignes restantes
C'est là que la plupart des feuilles de calcul déraillent.
Les montants et les dates ne sont pas des clés de liaison fiables dans les fichiers Shopify et Stripe, parce que :
- le même montant peut apparaître plusieurs fois dans une journée
- une commande peut avoir plusieurs tentatives de paiement
- les remboursements peuvent intervenir longtemps après la vente initiale
- l'horodatage de la commande et celui du paiement ne correspondent souvent pas au même événement
- la gestion des fuseaux horaires peut décaler la date sans modifier le paiement
Si les dates font partie de votre passe de vérification, traitez-les comme des éléments de confirmation. Ne les élevez pas au rang de clé de liaison principale, surtout si vous observez déjà le phénomène décrit dans les décalages entre les horodatages Stripe en UTC et les dates du relevé bancaire CSV.
Pourquoi des données correctes semblent ne pas correspondre
Quand un classeur indique que les lignes ne s'alignent pas, l'une de ces situations est généralement en cause.
Vous avez rapproché des données au niveau commande avec des données au niveau paiement.
Une commande Shopify peut correspondre à plusieurs enregistrements Stripe. Le fichier n'est pas en cause. Le niveau de granularité, si.
L'export Stripe n'inclut pas le champ de liaison.
Les métadonnées peuvent exister dans Stripe, mais le CSV exporté peut les omettre. Si la clé de liaison est absente du fichier, le rapprochement échouera, même si l'objet de paiement sous-jacent la contient.
`Payment References` contient plusieurs valeurs.
Une commande Shopify peut contenir plusieurs identifiants de paiement. Si vous traitez toute la cellule comme une seule clé, aucun des événements de paiement individuels ne correspondra correctement.
Vous utilisez `Name` parce qu'il vous est familier.
C'est le piège le plus courant. #1042 est facile à lire, alors on essaie de tout ramener à ce numéro. Les fichiers de transactions Stripe ne sont pas construits autour de ce qui est le plus lisible. Ils sont construits autour des objets de paiement.
Les remboursements sont rapprochés avec la ligne de vente initiale.
Les remboursements nécessitent leur propre logique de traitement. Ce ne sont pas des copies négatives de la ligne d'export de la commande initiale.
Les horodatages diffèrent même quand le paiement est identique.
La création de la commande Shopify, la capture du paiement et la création de la transaction Stripe peuvent survenir à des instants différents. Si vous imposez une correspondance exacte sur la date, des données correctes peuvent sembler erronées.
À quoi ressemble un résultat de rapprochement fiable
Quand le rapprochement est juste, votre fichier de travail doit pouvoir répondre à ces questions sans fouiller manuellement :
| Question | Le fichier doit répondre avec |
|---|---|
| À quelle commande Shopify appartient cette transaction Stripe ? | Numéro de commande et identifiant interne de commande |
| Quel événement de paiement Stripe appartient à cette commande Shopify ? | Identifiant de transaction ou référence côté paiement |
| Cette ligne est-elle une vente, une nouvelle tentative, un remboursement ou une capture ? | Type d'événement clairement distingué |
| La correspondance a-t-elle été établie par clé directe ou par vérification ? | Colonne indiquant la méthode de rapprochement |
| Quelles lignes restent sans correspondance ? | Une courte liste des lignes non rapprochées, avec la raison |
Si votre feuille ne peut pas répondre à ces cinq questions, elle n'est pas terminée. Elle a peut-être aligné la plupart des lignes, mais elle n'est pas encore assez fiable pour être réutilisée le mois prochain.
À faible volume, vous pouvez tenir cette table de correspondance manuellement.
À volume récurrent, le travail réel cesse d'être du jugement de rapprochement pour devenir de la maintenance de fichiers :
- diviser les références de paiement à valeurs multiples
- normaliser les numéros de commandes
- réexporter Stripe avec les bons champs
- reconstruire les mêmes jointures
- retraiter les mêmes cas particuliers non résolus
C'est le moment où la question n'est plus « Que signifie cet identifiant ? » mais « Pourquoi est-ce que je fais encore ce travail de correspondance d'objets dans un tableur chaque mois ? »
