3 min read

Checkout

Available from AW24

Native Checkout is a core framework, built with SwiftUI, that can replace Web Checkout for a more native experience. It uses the Checkout API allowing updating cart addresses and payment methods.

overview

# Checkout
checkout

The checkout deeplink is shared by the Checkout and Web Checkout features.

Set Up

Native Checkout requires a payment provider integration and BE configuration.

Poq currently supports Adyen and Braintree; using either of these usually requires almost no developer configuration. It is also straightforward to wrap any other 3rd party provider SDK as a poq payment provider.

Dynamic Content

Native Checkout supports the following Dynamic Content slots:

SlotVersionWhere?
scroll-topSS24After the progress bar, before all other views.

Adding slots in SwiftUI is easy.

Sections

The Checkout view is a stack of views based on the Checkout information. The screen fetches the current checkout for the user then guides the user to enter information with progress unveiling sections as the user completes the previous.

When the user selects or edits a section checkout is updated to update the other sections. This is important if shipping methods or prices change based on other information.

Contact Information

The contact information section is the first stage for guest users (only). It opens a separate screen for the user to set or edit their email address.

Shipping Contact

The shipping contact section is the first or second (guest) section.

For logged-in users it defaults to their default Address Book address. If they don't have one or edit it, it opens the Address Book in selection mode.

For guest users it opens the Address screen directly.

Addresses are stored in the Cart so may not exactly match Address Book addresses. There is extra logic to attempt to match existing addresses for selection mode.

Billing Contact

The billing contact section works the same as the shipping contact section with extra functionality.

If the billing contact matches the shipping contact the billing contact is simplified to a 'Same as Shipping' message. Editing the shipping contact updates a matching billing contact. Editing the billing contact does not change the shipping contact.

Shipping Method

The shipping method section presents a list of available shipping methods for the cart. Options may change based on the current cart state.

The Checkout UI doesn't currently support BOPIS or multi-ship but can be customised to do so as the models can support it.

Order Summary

The order summary presents a preview of the cart items and a breakdown of costs. The section supports different styles across Checkout and Order Details.

Payment

Payment can be handled as a payment methods section and/or a payment button. However, using just the payment button is easier, less error prone, and preferred.

The UI for these are handled by the integrated payment provider.

Payment Providers

Payment Providers are integrations to present the Payment Method section or Pay Button. The poq platform integrates with 3rd party payment provider 'Drop-In' SDKs that provide the UI for the Pay Button.

It is easier and less error prone to present a sheet of payment options to take payment. Storing a selected payment method for later requires that the provider can take amounts that may change after selection.

The poq platform currently supports:

Payment providers can also vend express checkout widgets to add to the Cart screen. From AW24, express checkout widgets have been rewritten to use the Checkout API for consistency.

Errors

Errors and edge cases can occur; we must ensure the amount the user pays is correct and expected. Checkout and poq payment provider integrations have built-in logic to protect the user and their progress.

If the cart expires, when the user makes a change or goes to pay, the app should receive a 410 response. Checkout then updates the BE with the current state to preserve as much progress as possible and an error is shown to the user. This should allow them to continue as if nothing happened.

We send the cartId and expected amount when the user initiates the payment provider. If the information doesn't match the app should receive a 409 response. Checkout then fetches and presents the new cart and an error is shown to the user.

History

  • AW24: Initial release with Adyen and Braintree providers.