Can't proceed to checkout if the dark background framed poster is in the basket/cart

[amharris]

What Happened

If one of the new framed posters with the dark background is in one's basket, it won't proceed to the checkout on Shopify/Shop. Whether it's the sole item, or other items are included doesn't matter; if one of these is in the basket, it won't proceed.
I've tested each 'SKU'/product ID, each representing a combination of the background colour and frame colour choices and it appears to be affecting any of the dark background ones, whichever size or frame colour, whereas the version with the white background seems fine.

For example; if you have a 'Terminal Pillow - 18×18' or 'edw Sticker Sheet', it'll proceed to the Shopify/Shop checkout successfully. However, if you also have the 'Palette Framed Print – Dark - Black / 24×36' framed poster, it won't. I've tested against both U.S. and UK address and that doesn't appear to play a role. I've also tried with disabling all extensions/plugins for each browser (and was part of the reason I eventually tested with Chrome on Android to ensure nothing custom in my desktop browser was the cause of the issue).

I don't see anything appear in my console and after the request with the redirect and POST to Shopify/Shop, there are no clues on the store end but it cleanly finishes and the page reloads with the submitted form details being loaded back into state.

Expected Behavior

With this product in the basket/cart, it should successfully POST the data and redirect to the Shopify/Shop checkout page.

Steps to Reproduce

1. Go to the store
2. Add the 'Palette Framed Print – Dark - Black / 24×36', 'Palette Framed Print – Dark - Black / 12x18', 'Palette Framed Print – Dark - White / 24×36', or 'Palette Framed Print – Dark - White / 12×18' to your basket/cart
3. Optionally, add another item that's not one of the affected products, (such as the examples noted under 'What Happened')
4. Go to your basket/cart and fill out your contact and address details for shipping
5. Click 'Get Shipping Rates'
6. Selecting an option (in my case, only one of 'Flat Rate') and click 'Checkout'
7. The page should end up reloading with the details for the form being reloaded into state

If you want to confirm the alternative (the process working as it should), repeat this again but with the variant that has the white background.

Logs

Platform Information

• Browsers:
  • Brave
  • Chrome
  • Firefox
• Operating Systems:
  • Linux
  • macOS
  • Windows
  • Android
• The latest versions of the above (both browsers and OSes) at the time of writing

[cassidyjames]

Thanks for the very clear issue report, @amharris! I think I know the underlying issue: Printful is seeming to have issues with items with multiple layers; even though the dark print has a single print file, it also has the background set to black inside of Printful itself. It seems Printful treats this as multiple layers and this errors out. It doesn't happen on the light posters because there is no background layer (the default background is inherently white).

[amharris]

Thanks for the very clear issue report, @amharris! I think I know the underlying issue: Printful is seeming to have issues with items with multiple layers; even though the dark print has a single print file, it also has the background set to black inside of Printful itself. It seems Printful treats this as multiple layers and this errors out. It doesn't happen on the light posters because there is no background layer (the default background is inherently white).

No problem! I pride myself on that sort of detail.
Thanks for getting back to me so swiftly, @cassidyjames.

I've never used Printful. Could you give me a quick rundown of where it fits in between the site and the Shopify gateway. ? Instinctively, is Printful not being used after the order has been processed? Or is it that this data is being used directly out the back of Shopify? I assume you're storing your order regards there and not just using it as a payment gateway, so that you can hand off all the data, payment and storage of sensitive information to them.
That would lead me to assume that the data Printful is generating and being passed to Shopify in the POST (to be handed off to Printful after a successful order, (which I suppose would explain the different material sourcing being listed, depending on region, likely handled by Printful based on the customer location ...but I'm jumping to conclusions here)) is tripping up; or, alternatively, it's being built before being sent, in preparation, and is tripping up then.

If you're happy to spare a bit of time, I'd really appreciate some insight. Useful for me to know for the future for my own endeavours, or just technical considerations in general. 😜

[btkostner]

Hello @amharris. Cassidy is on vacation right now but I can help answer some of the more technical questions.

First off, the store does not use Shopify. It uses Printful and Stripe directly to avoid having the extra Shopify fees on orders.

The process for the order goes like this:

• The user loads the homepage, we load all of our products from the Printful API (cached)
• The user adds a product to their cart, and we save that to a cookie
• The user enters their shipping address, we load the shipping prices from Printful
• The user selects the shipping method
• We create a draft order in Printful. This stores all of the information and locks in the shipping price. This is where this error occurs, and makes it impossible to actually collect the payment information.
• We create a Stripe checkout instance with the product information, and redirect the user to their payment page
• The user enters their information
• Stripe sends us a webhook about the checkout session now being complete, and we confirm the order so it can be printed and shipped

As for where the sensitive information is stored:

• Printful holds the bare minimum to make an order. That's the products, and the ship to address. It never handles any payment information
• All payment information is handled by Stripe. Credit card numbers never touch our servers

[amharris]

Thanks for enlightening me on the architecture, @btkostner—much appreciated.

Ah, I meant in terms of it redirecting to Shop(ify) for payments and tracking. I thought I saw the staple form, or I possibly got mixed up whilst the moon was shining. Being half-awake when filing a bug probably wasn't the best idea!

As for the issue at hand that @cassidyjames was alluding to, could you please expand on that? Time permitting, of course. It's far more valuable that it be thrown at addressing the issue; for customers, as well as capturing otherwise lost revenue.

Depending on where this lies in the priority list—sprints 'n' all—would you be able to facilitate a manual, off-site order for one of the affected item SKUs, if this is going to take the back seat for a while (understandably so, given OS 6)?