RFC: Custom Checkout

[martinbavio]

I'm thinking about having a fully custom checkout page for this project.

Didn't want to start working on a POC before having a talk about heuristics with the core team of the project.

There are three main topics that come to my mind right now:

1. Checkout data hooks: Based on what I've been from BigCommerce, they have a Checkout SDK to pull this off, so it shouldn't be hard to build custom hooks on top of that. But at the same time, they might be thinking about adding hooks like those to their own hooks repo, which is the kind of information I don't have access to.

2. Thinking beyond BigCommerce: I saw there's already some work being done to support multiple providers, so I'd like to know how would that affect an effort like this one.

3. Page UI: was there any mockup or version of the checkout page on the designs that were made for the initial version of the Commerce Kit?

@okbel @lfades Thoughts?

[lfades]

@marbiano We did have some mockups but there were limitations on custom checkouts with BC, mostly related to security, therefore we went for the full checkout using an external page handled by BC.

@becomevocal any thoughts here?

[becomevocal]

@lfades yeah the most custom form of checkout where you manage your own payment requests puts the app in scope of PCI compliance. We support that method, it's just easier for many devs & merchants to have the ecomm platform manage more of that risk.

@marbiano high level the BC platform supports the following checkout methods:

• Fully Hosted Checkout, which is customized by modifying the template and settings inside BC (this is what's integrated now and on the Vercel demo store)
• Custom Hosted Checkout, which can be implemented by using our Checkout SDK and replacing the default fully hosted checkout (can be accomplished now but is custom work for each site you develop, of course)
• Embedded Checkout, which is our hosted checkout initialized inside an iframe on an external page
• Completely Custom Checkout, which could be implemented using our Checkout APIs

Would be great to hear more about what flow you are trying to accomplish so we could pair up on the BC side to implement into our data hooks and make sure it works seamlessly here. If it helps to chat it out on our dev slack or discord let our dev advocate @RayeEThompson know and we'll continue the convo there 💪

[RayeEThompson]

👋 @marbiano - creating a custom checkout using Open Checkout is an option. At this time your team would own the PCI compliance if you use this code - but it is our BC production application, it is supported and has regular releases/bug fixes. It is React so it should work nicely with Next or give you the inspiration for how to build your solution.

I also think that we are open to having our hooks collaborated on by our dev community. It might just take sometime to open that repo for collaboration. I would love to hear your thoughts on that and how we could work on community collaboration to improve checkout.

[RayeEThompson]

@marbiano the data hooks are open-sourced. I will be happy to look at more data hooks for checkout, as well please feel free to reach out to me any time and we can collaborate on them.

[martinbavio]

@becomevocal Thanks for the info!

@RayeEThompson Hi! happy to connect, I was just looking at this document but it's not clear to me what would be the best course of action since there seems to be are many options, including the Checkout SDK which looks kind of nice.

I'll join BC's Slack tomorrow so we can discuss via chat. Thank you!

[RayeEThompson]

@okbel I think this one is good ;)

[robbieaverill]

Hi @becomevocal @RayeEThompson, would you mind please clarifying a couple of points around the requirement for PCI compliance here?

the most custom form of checkout where you manage your own payment requests puts the app in scope of PCI compliance

If you're talking about posting credit card information over network requests in your own application, sure - you'd need to be PCI compliant, but I don't think that's a realistic scenario - I believe that the standard approach would be to use a PCI compliant tokenized payment gateway (like Stripe) to handle the payments for you, which should offload this responsibility.

In the case where the payment gateway is PCI compliant, my understanding is that the dev/merchant actually does not need to be PCI compliant, because they are not handling credit card information directly. In this case there's no reason why the dev/merchant couldn't use BigCommerce's checkout API to build their own hosted checkout experience, and no reason why we shouldn't use a "Completely Custom Checkout" in this repository instead of the "Fully Hosted Checkout".

[becomevocal]

@robbieaverill good point! I maybe made it sound a bit too ominous in my previous comment 😅

The completely custom checkout route should be able to skirt the PCI compliance scope if it's using a payment gateway like Stripe to handle secure tokenization on the FE. I've definitely seen that route taken across many ecomm sites across in the past. It's then more of a matter of how you create the order in your downstream systems with a reference to the payment? Makes me think it's worth looking into order specific data hooks as an enabler 🤔

[patrys]

If anyone is interested in how different APIs handle checkout (I hope the idea is for this to not be too BigCommerce-specific), here's Saleor's checkout API (JS SDK): https://github.com/mirumee/saleor-sdk/blob/master/src/api/Checkout/index.ts

[osseonews]

Interesting discussion. Bigcommerce usually suggests using Braintree as the payment provider. If you use Braintree, you can use their Drop-In and there is absolutely no issue with PCI whatsoever. There is a wrapper for React available at: https://github.com/Cretezy/braintree-web-drop-in-react -

[avisra]

+1 on this. It is a bit upsetting that (without a lot of effort) we have to leave the BC shop UX live and available to the public in order to easily integrate checkout (e.g. demo store is relying on https://acmedemo.mybigcommerce.com).

Ideally, it would be integrated much like cart and other options. Otherwise, the embedded checkout seems like a fair compromise so we can at least keep things on the same URL (vercel demo store sends you to https://acmedemo.mybigcommerce.com to checkout).

In both of these options, it would be desirable to shut down all other UX on the https://acmedemo.mybigcommerce.com site so only checkout is being delivered from there.

[robbieaverill]

In #175 there is some discussion around a "feature API" for various providers to opt in or out of various features. I think that in this case, if BigCommerce/Shopify/other providers don't support building checkouts natively into your application, then it could be feature flagged to use an external checkout [status quo] instead (or disable a native checkout which this issue would build). Fully headless platforms could then opt in to using the native checkout (which this issue would build), which would then become the default.

FWIW, I'm happy to help out with the build here!