Introduction
If you're going to build a headless WooCommerce application, you generally have two options when it comes to checkout:
A) Build it yourself
--OR--
B) Offload to WordPress
✋🏼 Yep, I know there are some hosted checkout plugins for WordPress, but for the sake of simplicity, this post isn't about reviewing those plugins.
Option A: build the checkout yourself
This is a totally feasabile solution. The WooGraphQL has a checkout
mutation that will create the order and handle the payment gateway for you.
💡 Example: See my post about a detailed implementation: build a checkout page for your headless WooCommerce app with React.
The pros of building your own checkout:
- You have complete control of the UI (👈🏽 this may be the deal breaker)
- It's fast
- It's a seemless experience
The cons of building your own checkout:
- You have to build the entire UI - yes, you get the blank canvas, but that means you need to build it
- You have to deal with form validation
- You have to handle errors - checkout errors, gateway errors
- You have to build another route for the confirmation page
- You have to learn about the payment gateway SDKs (Stripe, PayPal, etc)
- There may be existing functionality that you have to integrate such as adding users to a newsletter upon checkout
- WTF is PCI compliance and do you need to support it? I don't know it, and would rather spend time on solving business problems than dealing with learning and supporting this
- What if you want to start supporting Google and Apple Pay?
- Has your implementation gone through the wringer? Is there something in production that you can trust or is this the first implementation? If so, checkout is a critical piece of the business, and you probably don't want to mess it up 😀
- Authentication - how can you ensure that authenticated users' orders get associated with their account?
Based on this list, it seems that the cons far outweigh the pros; however, if a very specific UI is required and cannot be built in WordPress, building your own may be an optimal option.
Option B: offload to WordPress
The idea behind this is to send your users from the cart page to the WordPress checkout page, which lives in a different domain.
💡 Read my detailed implementation about offloading checkout to WordPress.
The pros of offloading checkout to WordPress:
- It already works - form validation, error handling and payment gateways are already in place
- No need to deal with custom payment gateway integration
- 3rd party plugins that hook into checkout will continue to work
- The confirmation page is already built
- Authentication will work (kind of - see below)
The cons of offloading checkout to WordPress:
- You have to properly handoff the cart session from your decoupled app to WordPress, otherwise the cart will be empty when the checkout page loads
- Unless you're using cookie authentication, your users will have to log in again
- The page may be slow to load, especially on mobile, since it's WordPress
- You need to ensure that branding properly matches the headless app so that users aren't confused
Conclusion
These days, I lean more towards offloading the checkout to WordPress. That way I can stay focused on solving unique business challenges.