Ce qui casse entre le devis et la conversion : 17 modes de défaillance de la conversion d'un devis Shopify B2B

Entre le moment où un acheteur accepte un devis et le moment où une commande provisoire Shopify existe pour lui, dix-sept choses peuvent changer sous les chiffres acceptés : le prix catalogue, le stock, la variante elle-même, la taxe, le tarif de livraison, la devise, les remises, les conditions du site, l'identité de l'acheteur, l'expiration du devis, et l'appel d'API qui porte tout cela.

Aucune n'est un bug de Shopify. Chacune est Shopify qui recalcule ce qu'il possède au moment où la commande provisoire est créée, pendant que la couche de devis détient encore ce qui a été convenu. Une conversion qui n'attend pas cet écart expédie la mauvaise commande sans que personne ne s'en aperçoive avant la facture.

Cette page liste les écarts un par un - ce que fait Shopify dans chaque cas, ce qu'une couche de devis doit faire, et quoi vérifier - puis les deux mécanismes qui transforment ces surprises en états : un calcul préalable comparé à la version scellée, et une conversion qui peut être relancée sans créer une seconde commande provisoire. Elle s'adresse à l'agence qui construit ou évalue l'étape de conversion, le point où la couche de devis touche le plus Shopify et où ce qui vit où et ce qu'est une commande provisoire cessent d'être de l'architecture et deviennent un ticket de support un mardi matin.

Tout ce qui concerne Shopify ci-dessous a été vérifié sur les pages de Shopify le 22 septembre 2026 en version d'API 2026-07 ; les sources sont à la fin. Là où la page décrit comment QuotWay traite un cas, c'est une mise en œuvre du schéma, étiquetée comme telle.

Pourquoi l'écart existe

Un devis enregistre un prix sur lequel les deux parties se sont entendues. Une commande provisoire enregistre ce que Shopify facturera. Le premier est un instantané ; la seconde est un calcul, et Shopify le refait à chaque fois - draftOrderCalculate « calcule les propriétés d'un DraftOrder sans le créer », en renvoyant les totaux de lignes, les tarifs de livraison, les remises et les taxes pour l'entrée que vous lui donnez maintenant, contre le catalogue, le stock, les réglages fiscaux et les tarifs de livraison tels qu'ils sont maintenant. La commande provisoire est ensuite créée à partir des mêmes entrées, et le paiement recalcule une fois de plus quand l'acheteur paie.

Il y a donc trois moments - la proposition, la conversion, le paiement - et Shopify possède l'état aux deux derniers. La couche de devis possède exactement une chose sur les trois : l'enregistrement scellé de ce qui a été accepté, avec le prix de chaque ligne, la quantité, la devise, les conditions et les totaux tels que l'acheteur les a vus. Convertir, c'est demander à Shopify d'honorer cet enregistrement, et découvrir ce qui a bougé depuis.

Les modes de défaillance

Le tableau est la page. Chaque ligne est une condition qui peut être vraie au moment de la conversion sans l'avoir été au moment de la proposition, ce que Shopify en fait, ce que la couche de devis doit faire, et comment l'attraper. « Calcul » désigne draftOrderCalculate, qui ne coûte rien et ne crée rien.

Condition	Ce que fait Shopify	Ce que la couche de devis doit faire	Comment l'attraper
Prix catalogue modifié depuis la proposition	Une ligne sans remplacement prend le prix catalogue à la création ; une ligne avec priceOverride garde son remplacement. Une commande provisoire B2B dont les prix étaient verrouillés garde le prix verrouillé	Envoyer chaque ligne de variante négociée avec priceOverride dans la devise de présentation, depuis la version scellée, jamais depuis le catalogue en direct. Montrer au marchand la référence d'où la négociation est partie à côté du prix écrit	Calcul : comparer originalUnitPriceSet de chaque ligne à la référence stockée au moment de la proposition ; une différence est une information pour le marchand, pas une modification de la commande
Stock épuisé	Un brouillon ne réserve rien sauf si reserveInventoryUntil est défini. Le brouillon est créé quand même ; le paiement de l'acheteur échoue ensuite avec une erreur de rupture de stock, sauf si la variante autorise la survente. Les unités réservées passent en « engagées » jusqu'à l'échéance que vous fixez	Décider par affaire s'il faut réserver, et pour combien de temps, à la conversion - pas à la proposition, où rien ne doit être retenu. Dire à l'acheteur lequel des deux	Calcul : une erreur utilisateur liée au stock sur l'appel est le signal ; la traiter comme un écart à montrer au marchand, pas comme un échec de la conversion
Variante supprimée ou produit dépublié	La ligne ne peut être ni chiffrée ni vérifiée en stock ; il n'y a pas de variante à laquelle rattacher le remplacement	Résoudre chaque identifiant de variante avant de calculer ; une ligne qui ne se résout plus est remplacée par le marchand (ligne personnalisée ou variante successeur) ou retirée avec l'accord de l'acheteur - ce qui est une nouvelle version, pas une modification	Résoudre d'abord ; une résolution échouée est un arrêt net avant le calcul
Taxe recalculée	Les taxes suivent les réglages fiscaux de la boutique et l'adresse de livraison du client ; l'exonération d'un site s'applique via purchasingEntity ; taxExempt peut être posé sur le brouillon ; le paiement recalcule encore	Chiffrer une estimation et le dire ; reporter l'exonération du site sur le brouillon ; comparer la taxe calculée à l'estimation et retenir la conversion quand la différence est significative	Calcul : totalTaxSet contre l'estimation de taxe de la version acceptée, en pourcentage ; un seuil décide si quelqu'un regarde
Livraison	Les tarifs viennent d'availableShippingRates, qui exige une adresse de livraison valide et une ligne ; ou d'une shippingLine personnalisée ; un produit ajouté après la facture ne met pas le tarif à jour	Reporter un tarif final chiffré comme ligne de livraison personnalisée ; quand le tarif est resté en attente, en choisir un parmi ceux de Shopify à la conversion ; ne jamais laisser partir la facture avec le tarif de la proposition si les lignes ont changé	Calcul : totalShippingPriceSet et la liste des tarifs contre le montant chiffré ; montrer la différence, laisser le marchand choisir
Devise	Un presentmentCurrencyCode par brouillon ; priceOverride est dans cette devise ; currencyCode est la devise de la boutique dans laquelle le calcul a tourné ; un brouillon multidevise avec conditions de paiement ne peut être encaissé que par carte ou marqué payé	Fixer la devise du devis à la création d'après le marché de l'acheteur et ne jamais la convertir ensuite ; créer le brouillon dans la même devise ; garder un instantané du taux de change pour le reporting seulement	Vérifier que presentmentCurrencyCode égale la devise du devis avant la création ; refuser sinon
Remises cumulées	acceptAutomaticDiscounts applique les remises automatiques au calcul ; allowDiscountCodesInCheckout laisse l'acheteur ajouter un code au paiement ; appliedDiscount ajoute une remise personnalisée sur la commande ou une ligne	Un prix négocié est déjà la remise. Décider explicitement si les remises automatiques et les codes au paiement s'appliquent par-dessus - la valeur par défaut devrait être non - et reporter une remise de niveau devis comme un seul appliedDiscount, réparti par brouillon quand le devis se scinde	Calcul : platformDiscounts et totalDiscountsSet doivent se rapprocher de ce que dit la version ; tout surplus est un cumul
Lignes personnalisées	Pas de variante, pas de stock, pas de page produit ; inutilisables par l'exécution automatisée ou les applications de livraison ; prix depuis originalUnitPriceWithCurrency ; taxable et requiresShipping depuis l'entrée	Envoyer le prix convenu et les indicateurs ; prévoir une exécution manuelle pour ces lignes ; ne pas essayer de les réserver	Relecture : un brouillon avec des lignes personnalisées a besoin d'une personne à l'exécution
Conditions de paiement	Les conditions sont posées sur le brouillon comme un modèle plus un échéancier (issuedAt pour les échéances nettes, dueAt pour une date fixe) ; un brouillon porte ses propres conditions, et la valeur par défaut du site s'applique là où le brouillon n'en a pas	Écrire les conditions convenues pour l'affaire, pas la valeur par défaut actuelle du site ; si l'affaire n'en avait pas, laisser le site décider	Vérifier que le GID du modèle sur la version acceptée existe encore ; un modèle supprimé est un arrêt net
Acompte	Un pourcentage sur le brouillon (deposit), disponible sur Shopify Plus ; le paiement l'encaisse et échelonne le solde	Reporter le pourcentage négocié depuis la version acceptée ; refuser de créer un brouillon avec acompte sur une boutique hors Plus	Calcul : amountDueNowSet doit égaler la part d'acompte de totalPriceSet
Site d'entreprise manquant ou modifié	purchasingEntity est un client ou une entreprise acheteuse, jamais les deux ; le catalogue, les conditions, l'exonération et les réglages de paiement du site ne s'appliquent que si le site est sur le brouillon ; DraftOrderInput.customerId est déprécié en 2026-07	Stocker les identifiants d'entreprise, de site et de contact sur le devis et les résoudre avant la création ; un contact qui a changé de site, ou un site supprimé, est un arrêt, pas un repli vers un brouillon D2C	Résoudre les trois identifiants ; comparer le site résolu à celui d'où le prix a été dérivé
Règles de quantité	Les règles sont par variante et revalidées au paiement ; une quantité sous le minimum, au-dessus du maximum ou hors de l'incrément échoue là	Valider les quantités contre les règles du site à la proposition, et de nouveau à la conversion parce que les règles peuvent changer	Lire quantityRule via contextualPricing pour le site ; une violation est un arrêt avant la création
Devis expiré, ou brouillon purgé	Un brouillon créé le 1er avril 2025 ou après est supprimé après un an sans modification ; un devis expiré est l'état de la couche de devis	Convertir à l'acceptation, une fois ; ne pas créer de brouillons par anticipation à la proposition, où ils resteraient impayés et vieilliraient	Un brouillon sans commande après N jours est un cas de réconciliation, pas une attente
Acceptation partielle et scissions	Chaque commande provisoire est indépendante : ses propres totaux, taxe, ligne de livraison et conditions	Un brouillon par sous-ensemble accepté ; livraison et taxe réparties sur chacun au prorata du sous-total, ou remplacées par brouillon par le marchand ; les lignes encore ouvertes restent sur le devis	Additionner les sous-totaux des brouillons jusqu'à celui du sous-ensemble accepté ; la différence est un arrondi ou un bug
L'appel de création échoue en cours de route	draftOrderCreate ne prend pas de clé d'idempotence ; un second appel est un second brouillon	Réserver la conversion avant d'appeler, enregistrer l'identifiant du brouillon dès qu'il revient, et ne jamais relancer automatiquement une création dont l'issue est inconnue - la faire remonter	Réconciliation : une conversion avec un calcul mais sans identifiant de brouillon et sans mouvement depuis quelques minutes est un cas pour une personne
La commande revient en retard, en double, ou jamais	La commande est créée quand l'acheteur paie ; orders/create est livré avec un délai de connexion d'une seconde et cinq secondes au total, relancé 8 fois sur 4 heures, sans garantie, éventuellement en double	Écrire l'identifiant de commande depuis le webhook, rattaché au brouillon par un attribut que vous y avez mis ; rendre le handler idempotent ; lancer une réconciliation qui demande à Shopify si un brouillon a une order	Réconciliation : facture envoyée, pas de commande après une semaine → interroger le brouillon
Le brouillon a été modifié après la facture	draftOrderUpdate remplace l'entrée en bloc et dissocie un paiement en cours ; la commande peut alors être créée tandis que le brouillon reste ouvert	Ne jamais modifier un brouillon après l'envoi ; un changement après acceptation est une nouvelle version, une nouvelle acceptation et un nouveau brouillon	Une règle de la couche de devis elle-même ; rien à attraper si elle tient

Trois lignes méritent l'explication plus longue ci-dessous, parce que c'est là qu'un projet n'a le plus souvent aucune conception du tout : l'écart de taxe, l'appel de création et le webhook.

Deux nombres, un seuil

Chaque ligne du tableau qui dit « calcul » est le même mécanisme : exécuter draftOrderCalculate avec exactement l'entrée que vous allez créer, et comparer son résultat à la version scellée. Cela donne deux nombres par grandeur - ce qui a été accepté et ce que Shopify facturera - et la question de conception est quoi faire quand ils diffèrent.

La réponse qui fonctionne est un seuil fixé par le marchand, appliqué à la taxe, parce que la taxe est la grandeur que Shopify recalcule en silence et que l'acheteur n'a jamais négociée. Sous le seuil, la différence est journalisée sur le devis et la conversion se poursuit. Au-dessus, la conversion s'arrête dans un état « calculé » et une personne décide : accepter le chiffre recalculé, ajuster, ou revenir vers l'acheteur. L'écart de livraison est montré mais n'arrête pas la conversion, parce que le marchand choisit le tarif de toute façon. L'écart de stock est montré et le marchand décide de réserver, d'encaisser dans l'admin ou d'attendre.

Le seuil n'est pas une tolérance à l'erreur. C'est le point où « le moteur de taxes de Shopify avait des informations plus récentes que la proposition » devient « l'acheteur va le remarquer ». Une facture B2B dont la taxe diffère de deux pour cent de la proposition est une conversation sur les arrondis ; une qui diffère de vingt pour cent est une exonération qui ne s'est pas appliquée, ou une adresse de livraison qui a changé de juridiction, et quelqu'un doit regarder avant qu'elle parte.

Deux détails rendent cela honnête. La comparaison doit se faire contre l'estimation de la version acceptée, scellée à l'acceptation, pas contre ce que l'objet devis contient maintenant. Et quand un devis se scinde en plusieurs brouillons, la taxe et la livraison de la version doivent être réparties sur chaque brouillon - au prorata de sa part du sous-total accepté - pour que chaque comparaison mette en regard des choses comparables.

Pourquoi la conversion doit être idempotente

draftOrderCreate n'a pas de clé d'idempotence. Appelez-le deux fois avec la même entrée et vous avez deux commandes provisoires, deux factures, et un acheteur qui paie l'une et conteste l'autre. Tout ce qui peut l'appeler deux fois le fera, tôt ou tard : une file de tâches qui relance sur délai dépassé, un marchand qui double-clique, un handler de webhook qui déclenche une conversion puis est relivré.

Le schéma a trois parties. D'abord, une clé par conversion - devis, sous-ensemble accepté et version - stockée avec une contrainte d'unicité avant l'appel, pour qu'une seconde tentative trouve la première. Ensuite, une réservation : la ligne de conversion enregistre qu'une création est en cours avant que la requête parte, et enregistre l'identifiant du brouillon à l'instant où la réponse arrive. Enfin, une règle pour l'intervalle entre ces deux écritures : si le processus est mort après que Shopify a créé le brouillon mais avant que l'identifiant soit stocké, la conversion ne doit pas être relancée automatiquement, parce que la relance est exactement le doublon. Elle est remontée à un opérateur, qui peut retrouver le brouillon par son attribut et le lier.

Cette dernière règle est celle que les développements sur mesure sautent, parce qu'elle oblige à admettre un état qui a besoin d'un humain. C'est aussi celle qui empêche le pire résultat du tableau.

La commande revient par un webhook, pas par une valeur de retour

draftOrderCreate renvoie un brouillon. Il ne renvoie pas de commande, et il ne le peut pas, parce que la commande n'existe que lorsque l'acheteur paie - ou lorsque le marchand finalise le brouillon dans l'admin. L'événement qui porte la commande est orders/create, et il arrive aux conditions de Shopify : un délai de connexion d'une seconde, cinq secondes pour la requête entière, huit relances sur quatre heures, aucune garantie, et la possibilité de la même livraison deux fois.

Une conversion qui se marque « commande terminée » quand l'appel de création réussit montrera un jour une commande pour un paiement abandonné. Une conversion qui ne fait confiance qu'au webhook ratera un jour la commande. Le schéma est les deux : l'identifiant de commande n'est écrit que depuis le webhook, rattaché à son brouillon par un attribut que la couche de devis a écrit sur le brouillon à sa création ; le handler traite une seconde livraison comme un no-op ; et un travail de réconciliation demande directement à Shopify - draftOrder(id) { order { id } } - pour toute conversion dont la facture est partie et dont la commande n'est pas arrivée sous une semaine, en rejouant l'événement manqué si le brouillon s'avère en avoir une. Les annulations et les remboursements reviennent de la même manière, par orders/updated, et sont traités avec la même idempotence.

Comment QuotWay traite chaque ligne

La conversion de QuotWay est le schéma ci-dessus avec des chiffres dessus. Chaque groupe de conversion est calculé avec draftOrderCalculate avant draftOrderCreate, et le résultat est comparé aux chiffres de la version acceptée répartis sur ce groupe au prorata du sous-total. L'écart de taxe est mesuré en pourcentage contre un seuil par boutique dont la valeur par défaut est deux pour cent ; au-dessus, une conversion automatique s'arrête dans l'état calculé et le marchand prend la main. L'écart de stock est lu dans les erreurs utilisateur liées au stock de l'appel de calcul et affiché dans l'aperçu plutôt que de faire échouer la conversion ; toute autre erreur utilisateur la fait échouer. La livraison chiffrée est comparée à la livraison calculée par Shopify, et quand la proposition a laissé le tarif en attente, les availableShippingRates de Shopify sont proposés pour que le marchand en choisisse un par groupe.

Les prix atteignent le brouillon comme priceOverride sur les lignes de variante et originalUnitPriceWithCurrency sur les lignes personnalisées, dans la devise du devis, fixée à la création d'après le marché de l'acheteur et jamais convertie ; presentmentCurrencyCode y est explicitement fixé. Une remise de niveau devis est écrite comme un seul appliedDiscount, réparti sur chaque brouillon quand un devis se scinde. Les conditions de paiement sont posées comme le modèle convenu plus l'échéancier que ce type de modèle exige - une date d'émission pour les échéances nettes, une date d'échéance pour une date fixe - et un pourcentage d'acompte négocié voyage sur le brouillon des boutiques Plus. Pour les devis tenant compte de l'entreprise, l'exonération fiscale du site est posée sur le brouillon depuis les réglages fiscaux du site, et les lignes que le site ne peut pas voir sont de nouveau signalées à la conversion.

Chaque conversion porte une clé construite depuis le devis, le groupe et la version, unique en base, et réserve la création avant d'appeler ; une création morte en cours de route n'est jamais relancée par le système - elle est listée pour l'opérateur. L'identifiant de commande n'est écrit que depuis orders/create, rattaché par un seul attribut sur le brouillon (quotway_conversion_group_id) ; une seconde livraison trouve le lien déjà fait et ne fait rien ; annulations et remboursements arrivent par orders/updated et sont enregistrés une fois. Un balayage ferme les trois états bloqués : un calcul sans identifiant de brouillon et sans mouvement, une facture envoyée sans commande après sept jours - résolue en demandant à Shopify si le brouillon a une commande et en rejouant l'événement - et un groupe calculé sur lequel personne n'a agi depuis un jour. La version pour les marchands est dans convertir un devis en commande provisoire et acceptation partielle et conversion scindée ; la page de la fonctionnalité de conversion le montre depuis l'admin.

Une liste de pré-vol pour n'importe quel projet

Exécutez ces tests contre l'étape de conversion de n'importe quelle couche de devis - une application en évaluation ou un développement sur mesure - avec un devis de test dont vous pouvez changer le catalogue, le stock, la taxe et la livraison entre l'acceptation et la conversion. Le plan de test de mise en ligne en 50 tests fournit le jeu de test.

1. Changer le prix catalogue après acceptation, convertir : le brouillon porte le prix accepté, et le marchand voit que la référence a bougé.
2. Mettre le stock à zéro après acceptation, convertir : le marchand en est informé avant que la facture parte, et peut réserver ou retenir.
3. Supprimer une variante de la version acceptée, convertir : la conversion s'arrête avant tout appel à Shopify et nomme la ligne.
4. Changer l'adresse de livraison vers une autre juridiction fiscale, convertir : l'écart de taxe est mesuré et, au-dessus du seuil, une personne est sollicitée.
5. Laisser la livraison en attente sur la proposition, convertir : le marchand choisit parmi les tarifs de Shopify ; la facture n'est pas envoyée avec le substitut de la proposition.
6. Chiffrer dans une devise de présentation, convertir : le brouillon est dans cette devise et le remplacement de chaque ligne aussi.
7. Activer une remise automatique qui couvre un produit chiffré, convertir : le total du brouillon égale le total accepté, pas moins.
8. Poser des échéances nettes sur le site après acceptation, convertir : le brouillon porte les conditions de l'affaire.
9. Accepter un sous-ensemble strict, convertir, accepter davantage, convertir encore : deux brouillons, lignes encore ouvertes intactes, totaux qui s'additionnent au sous-ensemble accepté.
10. Tuer le processus entre la création et l'écriture en base, puis relancer : pas de second brouillon ; le cas est listé pour un opérateur.
11. Livrer orders/create deux fois : un identifiant de commande, un changement d'état.
12. Bloquer orders/create entièrement, payer la facture : la réconciliation trouve la commande.

Un projet qui passe douze tests sur douze a conçu l'écart. Un qui passe les six premiers a conçu le chemin heureux.

Questions fréquentes

Pourquoi la taxe sur la commande Shopify diffère-t-elle de la taxe sur le devis ?

Parce que Shopify recalcule la taxe à la création de la commande provisoire et de nouveau au paiement, à partir des réglages fiscaux de la boutique et de l'adresse de livraison à cet instant, tandis que le devis portait une estimation faite au moment de la proposition. Une adresse modifiée, une exonération qui ne s'est pas appliquée via l'entité acheteuse, ou un changement de réglage fiscal entre-temps déplacent le chiffre. Le remède n'est pas de rendre l'estimation exacte - c'est impossible - mais de comparer les deux à la conversion et de retenir la conversion quand elles diffèrent de plus d'un seuil.

Pourquoi le devis s'est-il converti au mauvais prix ?

Le plus souvent pour l'une de trois raisons. La ligne a été envoyée sans priceOverride, si bien que Shopify l'a chiffrée depuis le catalogue en direct ; le remplacement a été envoyé dans la mauvaise devise ; ou une remise s'est cumulée avec le prix négocié parce que les remises automatiques ou les codes au paiement sont restés activés sur le brouillon. Vérifiez dans le résultat du calcul originalUnitPriceSet, l'indicateur priceOverride et platformDiscounts par ligne contre la version acceptée.

Que se passe-t-il si le stock s'épuise entre l'acceptation et la conversion ?

Shopify crée le brouillon quand même - un brouillon ne retient aucun stock sauf si reserveInventoryUntil est défini - et le paiement de l'acheteur échoue avec une erreur de rupture de stock, sauf si la variante autorise la survente. draftOrderCalculate fait remonter le manque comme erreur utilisateur, si bien qu'une conversion qui la lit peut prévenir le marchand d'abord ; le marchand peut ajouter du stock et le réserver, encaisser dans l'admin, ou retenir la facture.

Puis-je relancer un draftOrderCreate qui a échoué ?

Seulement si vous savez qu'il a échoué avant que Shopify crée le brouillon. La mutation n'a pas de clé d'idempotence, si bien qu'une relance après une issue inconnue peut créer un second brouillon. Stockez une clé d'idempotence et une réservation avant l'appel, enregistrez l'identifiant du brouillon dès qu'il revient, et orientez une issue inconnue vers une personne plutôt que vers une boucle de relance.

La couche de devis doit-elle créer la commande provisoire dès la proposition pour verrouiller le prix ?

Non. Un brouillon ne verrouille pas ses prix sauf instruction, ne retient aucun stock sauf réservation, est supprimé après un an d'inactivité, et dissocie son paiement s'il est modifié. Le créer à la proposition place un objet modifiable et vieillissant au milieu de la négociation. Créez-le une fois, à l'acceptation, depuis la version scellée.

Comment savoir que la commande arrivée appartient à ce devis ?

Par un attribut que la couche de devis a écrit sur le brouillon à sa création, relu depuis les attributs de note de la charge utile d'orders/create, jamais en faisant correspondre des totaux ou des clients. Le webhook peut arriver deux fois et en retard, donc le handler doit être idempotent et un travail de réconciliation doit pouvoir demander à Shopify si un brouillon a une commande.

Une conversion scindée facture-t-elle la livraison deux fois ?

Elle le peut, parce que chaque commande provisoire est indépendante et porte sa propre ligne de livraison. La couche de devis doit répartir la livraison chiffrée entre les brouillons - au prorata de la part de chacun dans le sous-total accepté, ou selon un montant explicite par brouillon fixé par le marchand - et le dire sur chaque facture.

Sources

Pages Shopify, toutes lues le 22 septembre 2026 en version d'API 2026-07 sauf mention contraire :

• draftOrderCalculate, CalculatedDraftOrder et DraftOrderWarning
• DraftOrderInput, DraftOrderLineItemInput et PurchasingEntityInput
• draftOrderUpdate et draftOrderComplete (lus le 21 septembre 2026)
• Créer des commandes provisoires et envoyer des factures de commandes provisoires
• Créer des commandes B2B avec des commandes provisoires et configurer les conditions de paiement en B2B (lus le 21 septembre 2026)
• Règles de quantité et tarification par volume (lu le 21 septembre 2026)
• Webhooks et vérifier les livraisons de webhooks (lus le 20 septembre 2026)

Le comportement de conversion, d'écart, d'idempotence et de réconciliation de QuotWay est décrit à partir de son code source ; la version pour les marchands est dans les docs liées ci-dessus. Les différences entre offres sont sur la page des tarifs ; les faits sur les commandes provisoires et les conditions de paiement sont tenus à jour dans la référence Shopify B2B.