Hi, I did a search and didn’t see any previous threads on this - we utilize cart transform for one of our apps, and we would like to be able to allow for also updating the line item’s product cost as part of the cart transform.
The use case is we have a POS app where merchants can update the price of a line item, and in some cases they are looking to also hard-code a specific cost for that line item for financial reporting purposes.
We intend to keep it as a feature exclusive to Plus shops for now.
However, if we get enough feedback, we may consider making lineUpdate available for other plans in the future. No promises though.
Thanks for sharing the link. It refers to the product price update, which we’re already using successfully. For this scenario, however, we need to update the product’s cost rather than its price. Could you let us know if there’s a way to handle that?
We intend to keep it as a feature exclusive to Plus shops for now.
However, if we get enough feedback, we may consider making lineUpdate available for other plans in the future. No promises though.
Please consider making lineUpdate available for other plans as well. We currently have an app in the App Store that manages dynamic pricing by creating variants on the fly.
When a product has numerous configurations that influence the price, it’s impossible to pre-generate all possible variants. This means we must create variants dynamically while the user is on the product page. Currently, there is a 10–30 second delay before Shopify reflects these new variants in the cart. To bridge this gap, we’ve had to implement custom JavaScript workarounds in themes to display the correct price—a hurdle we’ve been dealing with for over 5 years because Shopify doesn’t allow cart line price updates.
This feature is particularly vital for print-on-demand and custom printing shops, many of whom cannot afford the Shopify Plus tier. Making this available for all plans would be a game-changer for these merchants. We would truly appreciate you reconsidering this!
To make sure I’m understanding correctly, could you share a quick example of the current behavior versus the expected behavior? Since lineUpdate.price is used to update the line’s cost, it sounds like it may already be working as you intended.
Hi @Paige-Shopify we are referring to cost which is different than price (i.e., what affects Cost of Goods Sold financial reporting). Ideally we would like a way to specify a custom product cost during the cart transform.
And yes, chiming in that we would also greatly appreciate lineUpdate being available for other plans as well. Ours is a Shopify POS app and lineUpdate makes everything looks much cleaner in the POS cart vs. lineExpand.
We have merchants who sell custom / one-off items, for example a shoe store, and they use our app to enter that specific’s product price each time they check out, and the margins may vary depending on the shoe. Because of this, they have requested the ability to also input a specific product cost for a given line item which would flow through to cost of goods reporting.
Sorry for the delay. I looked into this and found that the Cart Transform API wasn’t designed to support this kind of use case. The best solution I can think of for this is to actually create new variants/products on the fly, rather than manipulating existing variants/products.
Hi @Paige-Shopify just raising this again as we’ve begun rolling out Cart Transform more broadly, as our app’s previous default behavior of creating products/variants on the fly has become increasingly unreliable due to ongoing changes in POS cart behavior.
However, we are hitting blockers where certain merchants are hesitant to transition given that they lose accurate gross profit reporting within Shopify Analytics.
I understand that the Functions team may not want to support a custom cost amount - what about instead scaling a line item’s cost proportionally based on the updated price?
Our use case is we have a couple apps that enable selling by weight / decimal quantities. The current default behavior for our app is if a product has price of $5.00 and cost of $2.00, then if they process a line item through our app and create a temporary product, the temporary product’s cost will always be 40% of the total (60% gross margin).
Example line item: 4.60 lb @ $5.00 per lb
Line item price in cart: $23.00 Line item cost: $9.20 (40% cost / 60% gross margin)
However, this is the same example with cart transform:
Example line item: 4.60 lb @ $5.00 per lb
Line item price in cart: $23.00 Line item cost: $2.00
From a business / accounting standpoint, I would think that if a merchant is transforming the line item price, then the cost should scale up/down proportionally and this should be the default behavior. Is it possible to raise this with the Functions team?
@derrick apologies for the delay getting back to this.
That sounds like a reasonable approach for the by-weight case. The complication is that Cart Transform is ultimately intended to shape the buyer experience and what they are charged at checkout, while cost data sits outside that scope. I’m happy to raise this internally, but I can’t guarantee it’s something we’d be able to introduce.
You mentioned the move to Cart Transform was driven by POS cart behavior changes making the on-the-fly variant approach unreliable. Could you share more about what changed and what’s making that path no longer an option? If there’s a fix on the POS side that restores the original approach, that may be a faster route than waiting on a Cart Transform change.
We have battled an increasing number issues over the past year related to the POS cart properly validating or accepting newly-created product/variants. In a couple POS versions, this method stopped working entirely across the board.
Also, not sure if this is due to the Product Admin API => GraphQL migration or something else that changed behind the scenes over the past year, but during busier times merchants report unacceptably long waits for programmatic product/variant creation (8+ seconds in some cases).
Cart Transform eliminates many of the above issues, as we are simply adding the original product to the POS cart. Hopefully this helps.
The delay mostly sits in the product/variant creation step, which is a shared dependency for online store, POS, and anywhere else that needs the new data. I actually investigated this exact issue on the online store side recently in this thread, Intermittent 422 error when adding newly created variant to cart via /cart/add.js - #49 by jay_nl. As a result, we’ve made what optimizations we can at product/variant creation, but products and variants now have to handle a lot more than they used to, which limits how much we can optimize there.
I’ll forward this context along. It’ll help build a stronger case for the Cart Transform request.