Salesforce Commerce Cloud gives you the ability to customize almost every aspect of the storefront experience, including checkout. This gives companies the ability to customize the users experience, however, I believe understanding the 'native' capabilities is required before you can begin your journey into creating a custom checkout on Salesforce.
In this article, we're going to focus on the elements of standard checkout, how each component interacts with the Salesforce API's & objects behind your store.
Salesforce Commerce Cloud Checkout Process Overview
At a very high level there are really three stages when attempting to purchase on a storefront:
Cart - This is when the customer is still adjusting items to their cart, and it's possible for the user to move back to this stage at any time
Checkout - This stage is the steps the customer has to complete in order to successfully place a order with your company. The exact steps will vary by industry and customer but the ones listed below are the native steps
Order - This stage represents everything that happens after the place order action is successful
Checkout Steps
Before we get into the individual steps of checkout we should address the asynchronous nature of checkout. As you might imagine, checkout is dependent on data from many places in order to pull together a meaningful checkout experience. This includes elements like shipping, inventory, taxes, and more.
When a user initiates the checkout process by navigating to the checkout page (this could be through the native place order button on cart or through a custom method) the async process is kicked off which in the latest version of commerce is very tied to extensions. In short this kicks of the process of asynchronously retrieving the latest prices, inventory, shipping, and taxes.
If you're interested to learn more about how this works and what controls you have over this process you can visit my video on demystifying extensions.
In each section i've included diagrams that explain the components interaction with the cart & checkout process. The diagram key below will help you understand the different elements in the following diagrams.
Shipping Address
In the standard shipping component we have two main phases:
Mounting - The component is waiting for checkout to fully be ready, once ready it will parse the data from the checkout adapter and set the default shipping address
Interactions - These are user initiated actions, in the shipping address section we have three interactions that could effect the cart record behind the scenes
If you're interested in seeing the details of these imperative API's that the interactions use, you can find them on the below link.
Delivery Options
The standard delivery method component relies on the async process I mentioned in the intro to this section. Specifically we're reliant on the shipping calculator and the post shipping call.
Shipping Calculator - This shipping calculator is either the native shipping configured on the store, or the shipping calculator that has been hooked up as an extension
Post Shipping - "The postShipping calculator selects the least expensive delivery method and adds a shipping charge for the method. You can't modify this behavior with a custom calculator. Your custom orchestrator, however, can skip this calculator if that's appropriate for your use case."
Reference: https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/cart-calculate-api.html
It's important to note that this creates a cart item of type charge in the cart with the selected charge amount from the post shipping method
Once the checkout has been deemed ready the checkoutStatus will return 200 and the component will have the data it needs to load the options.
Async -Â This is the process mentioned above in the pre-description
Mounting - The component will parse the data returned from the checkoutInformationAdapter and display the options returned
Interactions - The user has the option to select a different shipping method if there are more then one option. Once selected, it will update the cart item of type charge.
If you're interested in seeing the details of these imperative API's that the interactions use, you can find them on the below link.
When the Checkout Information Adapter returns the response the data will look something like the example on the right side.
Within the payload you'll notice a object Delivery Groups and within that the Available Delivery Methods which holds all the returned options for your store.
Payment & Place Order
I believe it's important to start this section by stating that the payment component is always the last component / section in your checkout and therefore it's very tied into the place order action.
As you might have expected, the payment component is the most complicated! Let's spend some time breaking this down.
Purchase Order
The purchase order portion of this component is thankfully very easy, we are calling an imperative api called simplePurchaseOrderPayment which satisfies the requirements of checkout so you can capture a simple number and allow the user to move forward. This is obviously most applicable in a B2B storefront, so may not be applicable to you depending on what type of store you're building.
Credit Card
In short, the credit cart process depends on how your are implementing your credit card form, whether that is client side or server side. In this article we'll be talking about server side as that is how the out of the box component works.
The process of taking a credit card going through these steps:
Tokenization - This takes your card details and creates a token that can be used with your provider to validate the card being used
This token call is something that can be invoked through the API which can be found here https://developer.salesforce.com/docs/atlas.en-us.chatterapi.meta/chatterapi/connect_resources_commerce_webstore_token.htm
Authorize Payment - This takes that token and goes and authorizes the amount against the credit card, once complete we're ready to place the order
This authorize call there is a standard imperative call called authorizePayment which can be used to pass in a token and a few other details
Regardless of if you're placing an order with a purchase order or a credit card, they both result in calling a dispatchPlaceOrderAsync which begins the asynchronous process of moving a cart to an order.
To know more about the detailed interaction between the tokenization & authorization actions you can find a good digram located here - https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-b2c-comm-checkout-payment-serverside-setup.html
To wrap this all up, there are quite a few pieces to completing checkout and having a solid foundation in what's happens natively will help in the determining how to customize checkout & being able to troubleshoot any issues that arise as an admin.