> For the complete documentation index, see [llms.txt](https://partner-docs.covergenius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://partner-docs.covergenius.com/xcover-elements/client-integration/checkout-enablement.md).

# Checkout Enablement

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

{% hint style="info" %}
Not following these best practices may result in customers having an impacted experience if something goes wrong in XCE or a downstream dependancy.
{% endhint %}

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:

{% hint style="info" %}
Every `onSet` promise settles: it will always either resolve or reject, never remain pending indefinitely.
{% endhint %}

| 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://partner-docs.covergenius.com/xcover-elements/client-integration/checkout-enablement.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.