Checkout Enablement

This page outlines the importance on how to maintain checkout enablement using XCE

Not following these best practices may result in customers having an impacted experience if something goes wrong in XCE or a downstream dependancy.

Some partners may wish to prevent the user from continuing through the checkout journey until they have selected an option for XCover protection.

Because XCE is a third party dependency, we do not want to adversely affect the customer checkout journey. To that end, we strongly recommend that partners integrate our widget using the following practices:

• Use onSet promise in the set signal layer to wait for a response and control the user experience after.

• If onSet promise resolves then we can disable the Checkout Button to wait for users to select an insurance option from the widget.

• If onSet promise catches an error then we shouldn't disable the Checkout Button to avoid affecting the user checkout flow. Note: Any time the request fails you can expect onSet to throw an error so you can catch it and react to it.

• If the onSet is never called that means there was an issue loading the script. As long as the Checkout Button is enabled by default this should not cause an issue.

Rejection reasons

When the onSet promise rejects, err.message is one of the following stable codes, and err.cause carries the underlying error for diagnosis:

Every onSet promise settles: it will always either resolve or reject, never remain pending indefinitely.

Code	Meaning	err.cause
XCE_OFFER_REQUEST_FAILED	The offer request failed and nothing was rendered	The underlying error, e.g. the API validation message
XCE_RENDER_FAILED	The offer request succeeded but the element failed to render	The render error
XCE_ONSET_SUPERSEDED	A newer set signal was pushed while this one was still loading; this promise is retired	none

All rejections call for the same action: do not disable the checkout button. The codes and err.cause are diagnostic detail for your logging. For XCE_ONSET_SUPERSEDED, simply ignore that promise; your newer push's onSet carries the current outcome.