> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fexco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Handle rate expiry

> Understand when a DCC or MCP rate expires, and when you need to request a new one.

Every rate returned by Fexco has a limited validity window, communicated
through the expiry field in the response. How you use this field depends
on the type of transaction you are processing.

This page explains why rates expire, how to read the expiry field for
each integration method, and what to do for DCC, pre-authorisation, and
MCP transactions.

## Why rate offers expire

Fexco sources wholesale exchange rates from leading financial data
providers. These rates are refreshed up to six times per day
on every financial trading day. Each rate offer is built from the
most recently sourced wholesale rate at the time of the request.

Because exchange rates change throughout the day, an offer that was
valid minutes ago may no longer reflect the current rate. The
expiry window ensures that the cardholder is always presented with
an accurate, up-to-date rate. Once the expiry passes, the offer
is considered stale and must not be used for the transaction.

## How expiry works per API

Each integration method communicates the validity window differently:

| Method | Field | What to check |
| :- | :- | :- |
| Rate Service Classic | `expiry` | A date and time in UTC (for example, `2025-10-08T14:35:00Z`). The rate is invalid after this time. |
| Rate Service Connect | `exchangeRate.expiry` | A date and time in UTC (for example, `2025-10-08T14:35:00Z`). The rate is invalid after this time. |
| XML over TCP/IP | `VALIDHOURS` | The number of hours the rate remains valid from when you received the response. Add this value to the time of receipt to calculate the expiry. |
| ISO 8583 | Bit 60 (Valid Hours) | Same calculation as XML over TCP/IP. |

> [!NOTE]
>
> The expiry window length is configured by Fexco as part of your
> acquirer setup. Contact your Fexco project manager if you need
> to understand or adjust the expiry duration for your integration.

## DCC transactions

For any DCC card rate request, a real-time rate request is made
at the point of interaction, when the card is presented. The expiry
window is configured to allow sufficient time for the cardholder to
accept or decline the offer and for the transaction to complete, so
you do not need to manage rate expiry for standard DCC transactions.

> [!WARNING]
>
> Do not store or reuse a DCC rate offer for a later transaction.
> Always request a new rate at the point of interaction.

### Pre-authorisation completions

Pre-authorisation transactions, such as hotel or car rental bookings,
may be completed days after the original pre-authorisation. In this
case, the rate obtained at pre-authorisation must not be used for the
completion.

Send a new rate request at the time of pre-authorisation completion and
use the rate returned in that response. See the request guide for your
API:
[Rate Service Classic](https://docs.fexco.com/dcc/guides/rate-service/dcc-offer-rate-service-classic.md),
[Rate Service Connect](https://docs.fexco.com/dcc/guides/rate-service/dcc-offer-rate-service-connect.md), or
[ISO 8583](https://docs.fexco.com/dcc/guides/rate-service/dcc-offer-iso.md).

## MCP transactions

For Multi-Currency Pricing (MCP), FX rates are typically cached and
stored locally so that prices can be displayed in the cardholder's
currency ahead of the transaction. In this case, you must validate the
expiry field before authorising a transaction, and only use rates that
are within their expiration period.

**Step 1**

### Store the expiry with the cached rate

For Rate Service Classic and Rate Service Connect, store the `expiry` timestamp alongside
each cached rate and parse it as a UTC datetime.

```json theme={null}
{
  "exchangeRate": {
    "rate": "0.891200",
    "source": "ECB",
    "sourceTimestamp": "2025-10-08T14:00:00Z",
    "expiry": "2025-10-08T14:35:00Z"
  }
}
```

In this example, the rate expires at 14:35:00 UTC on 8 October 2025.

For XML over TCP/IP and ISO 8583, store the time you received the
response together with the `VALIDHOURS` (or bit 60)
value, and calculate the expiry by adding the two.

**Step 2**

### Validate before authorising

Before authorising a transaction, compare the stored expiry against
the current UTC time. If the current time is before the expiry, the
rate is valid and can be used. If the current time is equal to or
later than the expiry, discard the cached rate and request a new
one before pricing or authorising the transaction.

> [!TIP]
>
> Only authorise transactions using rates within their expiration
> period. Refresh your cached rates regularly so that a valid rate
> is always available.

> [!WARNING]
>
> Authorising with an expired rate may result in incorrect conversion
> amounts and settlement discrepancies.

## Rate becomes unavailable during processing

If you are using Rate Service Connect and the API returns a `409 Conflict`
response, the rate is no longer available. This can happen when
the underlying exchange rates are being refreshed or the external
rate service is temporarily unavailable.

Wait a short time and retry the request. If the `409` response
persists, see
[Troubleshoot rate service errors](https://docs.fexco.com/dcc/guides/rate-service/troubleshoot.md)
or contact your Fexco project manager.

## Next steps

* [Handle domestic and unsupported cards](https://docs.fexco.com/dcc/guides/rate-service/domestic-unsupported.md):
  manage transactions where the card is not eligible for DCC.
* [Choose a rate API](https://docs.fexco.com/dcc/guides/rate-service/choose-rate-api.md):
  compare Rate Service Classic, Rate Service Connect, and ISO.
* [Troubleshoot rate service errors](https://docs.fexco.com/dcc/guides/rate-service/troubleshoot.md):
  resolve common rate request failures.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.