Skip to main content
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:
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.
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, Rate Service Connect, or ISO 8583.

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.
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.
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.
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.
Only authorise transactions using rates within their expiration period. Refresh your cached rates regularly so that a valid rate is always available.
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 or contact your Fexco project manager.

Next steps