How to handle pricing when weight and price change based on variation

[hackerman]

Hello everyone, I have a situation I need to address.

Situation:

I am building a store that sells jackets. The price and shipping weight for each product change based on which size the customer chooses.

Problem:

My checkout workflow fails whenever the customer attempts to purchase a size different from the default size listed on the product’s details page.

Assumptions:

I know the failure is caused by the HTML crawler seeing data attribute values in the DOM that don’t match the customer’s selections. More specifically, these data attribute values are related to weight, which directly affects the price.

The only solution I can think of is to set up a unique REST API that serves JSON data for every possible variant/size/weight/price combination so that Snipcart can validate products in the checkout workflow using the JSON crawler instead.

Building an API just for product validation would be an astronomical amount of work on top of an already tight deadline with this client.

I imagine this problem has been addressed before in a more efficient manner, so I was hoping someone might share some insight.

Also, for the record, this site uses the Contentful CMS to hold my data models and product listings. I could use their API, but I would still run into the same problem of producing a JSON representation of every possible variation.

Here’s a test hosting of the site :

Welcome to Wilson Biker Gear

That said, the store is still in test mode, so you can attempt to make purchases using Snipcart’s test credit card … i.e., 4242 4242 4242 … etc.

Thank you so much!

[TorchlightPress]

This should be possible, however because Snipcart relies on scraping HTML to validate orders, it will require some legwork to make it work.

This recent post has information on how you can achieve this:

The TL;DR is that you can provide a validation URL that has query parameters. I believe you’ll need to be using server-side rendering (SSR) for this to work though, as the crawler needs to receive static HTML that’s been updated with the data in the query parameters. Traditionally cached HTML won’t be able to update like that on its own.

Doing this, you won’t need to generate every possible variation. Whether it’s more or less work for you, I’m not sure.

Donations, dynamic price or "pay what you want" scenarios?

Snipcart does support donations or “pay what you want” scenarios. However, to make our order validation work, you will have to: Set the price of your products dynamically via custom JavaScript code on your page. Set the URL of your product dynamically to a custom backend endpoint including the user-defined price in its route (using a query parameter for example). From this endpoint, dynamically return HTML or JSON markup that generates the correct price. See the order validation documentation …

[Michael]

Hello @hackerman,

You could use our product custom fields to change the price of items depending on which one is selected.

However, this won’t allow you to change the weight of the product depending on the selected field.

If this is a deal-breaker, you’ll need to rely on generating a custom JSON or server-side render your page with custom attributes, as explained in the reply above.

Let me know if that helps!

[TorchlightPress]

I completely forgot about the custom fields that can modify the price!

The Snipcart order validation only checks for a valid price, right? so if the product contains a dynamic weight (e.g. set via JavaScript), the Cart/order could get a dynamic weight and still pass validation, right?

[Michael]

Weight can’t be updated dynamically with JavaScript. It’s part of the order validation process to ensure a customer doesn’t bypass the cost of a shipping method.

For instance, if it was customizable, a customer could set the weight of any order to 0, which could trigger a cheaper shipping method.

[TorchlightPress]

Ah, right, that makes sense. Thanks for the clarification Michael!

Hopefully either the custom fields or the dynamic url help out, hackerman

[tmack8001]

It would be nice if data-item-custom{X}-<field> was a standard way of setting or rather overriding any of the original data-item data. Guess it would be a fairly complex requirement to be formatted similarly to the data-item-custom{X}-options but for each individual field.

Would be easier, IMO, to have a custom item setup with custom price and weight if the format for options was like this (this isn’t supported or built, just put together for an example of how it could work in the future):

data-item-custom{X}-price:"+10|+0|+0"
data-item-custom{X}-weight:"+0|+50|+100"

This format of overriding would allow for many of the attributes (length, width, height, weight, price) be modified based on a custom data-item option selected. It may get very complex if there are several data-item options in a specific data-item… but that is where the advice of user documentation would likely state to create multiple items vs trying to use the options for everything.