> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/central-issuance/implement-central-issuance/card-order/sla-management.md).

# SLA management

### SLA definition

The SLA

* starts when Thales receives your D1 API request
* ends when the physical card is shipped
* does not include carrier transit time

### Business days and cut-off

SLA working days follow the personalization center’s local calendar. By default, working days are Monday to Friday.

The daily cut-off time is local to the personalization center. Requests received after cut-off start on the next calendar day.

{% hint style="info" %}
In "D+N", **D** is the production request date after time zone conversion and cut-off handling.
{% endhint %}

### Standard SLAs

Standard SLAs depend on your contract and configuration.

Common examples:

* CREATION or REPLACEMENT: `D+1` (ready for carrier pickup at 17:00 local time).
* RENEWAL: `D+10`.
* URGENT: 4 hours if the urgent request is received before 12:00 local time.

D1 calculates the production due date for each physical card order based on the personalization center’s time zone, daily cut‑off, and the applicable SLA in working days.

### Sequence

<figure><img src="/spaces/ol7FqojHqm5it3effNc4/files/YPEDD4HWCNPc8X6CwRgH" alt=""><figcaption><p>SLA calculation sequence (cut-off and working days).</p></figcaption></figure>

### Inputs for due date calculation

D1 API inputs:

* `services.issuance`: Issuance type.
* `services.priority`: Priority level agreed for card production.
* `shipment.type`: BULK or INDIVIDUAL. May impact the SLA
* Request timestamp (from the API call).

D1 configuration:

* Cut-off time: local time after which the base date moves to the next day.
* SLA: number of working days to produce the physical card.

Derived by D1:

* Personalization center and its time zone.

{% hint style="info" %}
If your program maps `services.priority` to different SLAs, that mapping is configured in D1.
{% endhint %}

### Calculation

The due date is calculated as follows:

1. Capture the production request timestamp in UTC.
2. Convert the timestamp to the personalization center’s local time zone to get the local request time.
3. Determine the production request date:
   * If the local request time is strictly after the daily cut‑off, set the production request date to the next calendar day.
   * Otherwise, use the local calendar day of the request.
4. Add the SLA (in working days) to the production request date to obtain the due date.
5. If configured, skip non‑working days (weekends and local holidays) in step 4.

{% hint style="info" %}
Working days and holiday calendars are based on the personalization center’s local configuration. If your program uses multiple personalization centers, the applicable calendar may vary per order.
{% endhint %}

{% hint style="warning" %}
Decide and document whether “exactly at cut‑off” is considered before or after cut‑off. The examples below assume “strictly after” the cut‑off moves to the next day.
{% endhint %}

### Examples

After cut‑off (same week)

* Inputs
  * Request timestamp (UTC): 2025‑03‑18 17:30
  * Personalization center time zone: UTC+1
  * Daily cut‑off: 18:00 (local)
  * SLA: 2 working days
* Computation
  * Local request time: 18:30 (after cut‑off) → production request date = 2025‑03‑19
  * Add 2 working days → due date = 2025‑03‑21

Before cut‑off (crossing a weekend)

* Inputs
  * Request timestamp (UTC): 2025‑03‑14 13:00
  * Personalization center time zone: UTC+1
  * Daily cut‑off: 18:00 (local)
  * SLA: 2 working days
* Computation
  * Local request time: 14:00 (before cut‑off) → production request date = 2025‑03‑14 (Friday)
  * Add 2 working days (Mon, Tue) → due date = 2025‑03‑18


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.payments.thalescloud.io/central-issuance/implement-central-issuance/card-order/sla-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.