Menu
Menu Sheet Overlay
Search
Search Sheet

Payments

In this section understand the design considerations around the payment features of the Mobify Platform.

Understanding Apple Pay and Payment Request API

Apple and Google have unique solutions to speeding up checkout flows on the web.

Terminology

Design Considerations

When adding Apple Pay, Android Pay, or the Payments Request API (PR API) methods to the site there are a few key considerations. It's a good idea to audit the existing checkout flow to understand which features are being used in the checkout, and where they live.

Since the Payments Request API will mostly skip options in the cart, it is imperative that what will be missed is communicated before they choose the desired payment flow, so the shopper can make an informed decision about the checkout flow that is best for them.

Communicating Payment Options

PLP and PDP Buy Now Buttons

On the PDP, Apple Pay and the Payments API will allow the shopper to quickly purchase a single product quickly and effortlessly without having to interact with the cart or checkout flow. Primary buttons should communicate this speedy checkout type to the shopper. Language should be tested around these variations:

The Cart

Complexity increases when the shopper interacts with the cart. The cart is already a very complex interaction area where the shopper is required to review their purchase, enter promotion codes or other information, and then make a final decision to buy. With the addition of Apple Pay and the Payments Request API, the shopper now has additional paths to consider: using Apple Pay or the Payments Request API will act as an Express Checkout; the Traditional Checkout flow will still be required for those customers that have complex gift wrapping, multi-destination shipping, or other checkout requirements. The shopper also still may have the option of using third-party checkouts such as PayPal, Shoprunner, Visa Checkout, or Masterpass. Communicating the benefits of each of these is key to reducing friction.

To reduce complexity on the cart we could take a similar approach as we do on the PLP and PDP and limit the options to two, Buy Now and Checkout, and move the third-party checkout options into the traditional checkout.

Shopper Flow

Shopper Flow Diagram
This diagram shows the user flow of navigating the complexity of a multi-method checkout.

Interface Examples

PDP

iOS PDP Buy Now

iOS PDP with Apple Pay button
Standard full width button layout with emphasis on Add to Cart.

Android PDP


Android PDP
Standard full width button layout with emphasis on Add to Cart. Addition of benefit copy below Express Checkout may be necessary to communicate various checkout options for Express shoppers.

Cart

iOS Cart

iOS Cart
Option 1: Three distinct areas are presented to the shopper to consider. Express Checkout where they can use Apple Pay, Checkout where they can complete the traditional checkout and other where options like Visa Checkout can appear.
iOS Cart
Option 2: This option reduces the options to a condensed list to save vertical space. The two primary checkout options are called out through the use of color and additional benefits copy.

Android Cart

Android Cart
Option 1: Three distinct areas are presented to the shopper to consider. Express Checkout where they can use Apple Pay, Checkout where they can complete the traditional checkout and other where options like Visa Checkout can appear.
Android Cart
Option 2: This option reduces the options to a condensed list to save vertical space. The two primary checkout options are called out through the use of colour and additional benefits copy. Android Pay and Credit Card payment options are clearly communicated to the shopper.

Strip Out the Customerā€™s Checkout

The above solutions require the shopper to consider 3 different checkout option, increasing their cognitive load at a key junction. Once they have made a decision the path forward is logical but this additional level of complexity defeats the objective of simplifying checkout.

Android Cart

Android Cart
Customerā€™s checkout is removed and only two flows remain. When the shopper selects Checkout the Web Payments API sheet will appear.

For Android customers who have a ā€˜standardā€™ checkout with no complex checkout features such as gift wrapping, shipping instructions, gift cards, or shipping items to multiple addresses we should consider removing their checkout entirely.

Traditional Checkout with Express Checkout Options

iOS Traditional Checkout with Express Checkout Options
iOS: Shopper is provided final option to use Apple Pay during the payment portion of the checkout
Android Traditional Checkout with Express Checkout Options
iOS Traditional Checkout with Express Checkout Options
iOS: Shopper is provided final option to use Apple Pay during the payment portion of the checkout

Payment Sheet Examples

iOS Payment Sheet Examples
iOS:
Android Payment Sheet Examples
Android:

Payments Request API Setup Flow - New User

When you launch the Payments Request API for the first time, it pulls in the Order Summary total from the item/ cart.

Payments Request API Setup Flow Tap Edit
Tapping EDIT will allow you to fill in the necessary information. The sheet takes over the screen to give the user a more focused experience.
Payments Request API Setup Flow Tap Add Address
Tapping on + ADD ADDRESS will launch a new overlay with the needed fields.
Payments Request API Setup Flow Add Credit Card
Payments Request API Setup Flow Mutiple Address
Multiple addresses can be added to the Payments sheet, however only one can be used at a time (no multi-address shipping accommodated). Once a shipping address is supplied then the system can query the shipping options. The default shipping option is shown first by default, and expanding the section will allow you to modify the options.
Payments Request API Setup Flow Add Credit Card
Adding a credit card works the same way as adding addresses.
Payments Request API Setup Flow Payment API
The Payments API will pull in the accepted payments method from the seller payment API.
Payments Request API Setup Flow Billing Address
Billing address can be customized to be the same or different than the shipping address as is usually the case.
Payments Request API Setup Flow Contact Information
Contact information only takes the userā€™s email address. Phone number should be included with the shipping address.
Payments Request API Setup Flow Fields
Once all the fields have been populated and the customer is satisfied with the information they can tap pay to proceed.
Note: Once the information has been added to the payments store in their browser the information will always prepopulate from their.
Payments Request API Setup Flow CVC Code
The last step is to add the CVC code from the credit card to authenticate the transaction.

In the future they will still need to manually add the CVC number to complete the transactions to maintain credit card security.

Conclusion

The Payments Request API favours a simplified flow, and it requires some significant engineering and customer input to implement it as a total checkout replacement. Either the customer needs to approve removing fields/features, or we need to explore adjusting the flow to include those features earlier in the process to accommodate the Payments Request API.

The Payment Request API is a great way to simplify the checkout, with the caution that it may bring significant work to adapt existing checkout flows. To determine if it's worth the extra workload, consider your end users and their platform. As this feature would expedite payment for Android Chrome users, consider whether the number of Android Chrome users justifies the additional work.