> ## 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. # Choose a rate API > Compare Rate Service Classic, Rate Service Connect, and ISO 8583 to pick the right rate API for your integration Fexco offers three rate APIs. This page explains what each one is, how they differ, and which questions to ask before choosing one for your integration. ## Rate API comparison In this section, you will find a table summarizing each rate API. You will find more details on each one in the sections below. | | [Rate Service Classic](#rate-service-classic) | [Rate Service Connect](#rate-service-connect) | [ISO 8583](#iso-8583) | | - | - | - | - | | Messaging format | REST, JSON | REST, JSON | ISO 8583 | | Authentication | None at the application layer | Client certificate and JWT | None at the application layer | | MCP support | Yes | Not yet | Yes | | Testing approach | Certification environment after onboarding | Curated OpenAPI examples | Certification environment after onboarding | ## Rate Service Classic Rate Service Classic is Fexco's most widely used rate API and the one most customers integrate with first. It works over REST using JSON, with separate endpoints for merchant and ATM transactions. Fexco checks whether the card is eligible for DCC and returns either a DCC offer, with the converted amount, exchange rate, and any margin applied, or a "no offer" response for domestic or unsupported cards. See [Request a DCC offer (Rate Service Classic)](https://docs.fexco.com/dcc/guides/rate-service/dcc-offer-rate-service-classic.md) for full request and response details. Some of its key characteristics are: * **No application-layer authentication:** Access relies on standard TLS encryption, not a signed token per request, and does not require a merchant's IP address to be whitelisted. * **DCC and MCP support:** Supports both point-of-sale DCC and multi-currency processing (MCP) for e-commerce use cases. * **Testing:** No self-service sandbox is available. Once you complete early onboarding, Fexco provides a certification environment where you can test real requests and responses. * **Merchant identification:** The merchant is identified by MID in the request URL. See [Field name mapping](https://docs.fexco.com/dcc/developer-resources/codes/field-mapping.md) for how this identifier differs across Fexco's APIs. > [!TIP] > > Rate Service Classic is a strong default if your stack already sends JSON or you need MCP. ## Rate Service Connect Rate Service Connect exposes a single endpoint and represents the transaction stage and channel (POS, ATM, or e-commerce) as fields on the request, rather than as separate endpoints. It also introduces an authentication layer the older APIs do not have. Before you can call it, you generate a key pair, submit a certificate signing request to Fexco, and receive a signed client certificate, which you then use alongside a JWT to authenticate every request. See [Request a DCC offer (Rate Service Connect)](https://docs.fexco.com/dcc/guides/rate-service/dcc-offer-rate-service-connect.md) for full request and response details. Its key characteristics are: * **Certificate and JWT authentication:** Every request carries a JWT signed with a client certificate issued by Fexco, proving the request came from a specific acquirer. This is a genuine onboarding step. See [Certificate and JWT authentication](https://docs.fexco.com/dcc/api-reference/authentication/jwt-pki.md) for the certificate request process and token construction steps. * **One endpoint for every transaction type and channel:** Transaction stage and channel are request fields rather than separate endpoints, unlike Rate Service Classic's separate merchant and ATM paths. * **Header-based merchant identification:** The merchant is identified through request headers rather than a URL parameter. See [Field name mapping](https://docs.fexco.com/dcc/developer-resources/codes/field-mapping.md) for how this differs across Fexco's APIs. * **Ready-to-use offer and receipt text:** The response includes pre-built offer and receipt text with the rate and amounts already resolved, so you don't need to assemble your own wording. * **DCC only, for now:** MCP and other FX services available in Rate Service Classic have not been ported to Rate Service Connect yet. * **Testing:** No self-service sandbox or certification environment is available. You test against curated OpenAPI request and response examples provided on this portal. > [!TIP] > > Rate Service Connect is Fexco's strategic direction and the more secure option, though whether it becomes the default recommendation for new integrations is still being finalized internally. Choose it today if a strong, certificate-based authentication model and structured, ready-to-use responses matter more to your integration than having every rate-service feature available on day one. ## ISO 8583 ISO 8583 is a legacy message format used by bank-grade infrastructure to obtain a DCC or MCP rate offer. Like Rate Service Classic, it supports two modes: caching rates locally once a day, or requesting a rate from DHS on a per-transaction basis at the moment of payment. Its key characteristics are: * **ISO 8583 messaging:** Uses the standard financial messaging format that bank-grade payment systems already speak. * **No application-layer authentication:** Access relies on network-level restriction instead of a certificate or token. Fexco's DHS platform sits behind a firewall and only accepts connections from a pre-agreed IP address. * **DCC and MCP support:** Supports both DCC and MCP, matching Rate Service Classic. * **Testing:** No self-service sandbox is available. Once you complete early onboarding, Fexco provides a certification environment along with sample request and response messages to validate your implementation. > [!TIP] > > ISO 8583 is the right fit if your existing systems, particularly older or bank-grade infrastructure, already communicate using ISO 8583. ## Frequently asked questions These questions help you make a decision for your own integration. > [accordion] What messaging format do you already use elsewhere in your stack? > > Customers overwhelmingly stick with whatever format they already use for the rest of their integration rather than switching just for Fexco. If your stack sends JSON, a REST API fits naturally. If your stack already speaks ISO 8583, staying on that format keeps your integration consistent end to end. This is the single biggest driver in practice. > [accordion] Do you need MCP, not just point-of-sale DCC? > > DCC applies at the moment of a card transaction. MCP tracks rates across several currencies ahead of time, for cases like an e-commerce basket where a shopper can switch currencies before paying. Rate Service Connect does not support MCP yet. If MCP is a requirement, the choice is between Rate Service Classic and ISO 8583, not Rate Service Connect. > [accordion] Do you need certificate-based authentication? > > Rate Service Connect requires a client certificate and a JWT before you can call it. Rate Service Classic and ISO 8583 have no application-layer authentication. Security-conscious integrations lean toward Rate Service Connect. Integrations that want the fastest path to a first working request lean toward the other APIs. > [accordion] How can you test your integration? > > No self-service sandbox is available for any of the rate APIs. For Rate Service Classic and ISO 8583, Fexco provides a certification environment once you complete early onboarding. For Rate Service Connect, you test against curated OpenAPI request and response examples provided on this portal. > [accordion] Do you need Fexco to generate ready-to-use offer and receipt text? > > Rate Service Connect returns ready-to-use offer and receipt text with the rate and amounts already resolved. Rate Service Classic and ISO 8583 return only the raw rate and amounts, so you build the wording yourself. This matters more for integrations that don't already have their own DCC prompt and receipt-line logic in place. > [accordion] Does your integration need explicit transaction-type or channel handling? > > Rate Service Connect models transaction stage (for example a pre-authorization or a reversal) and channel (POS, ATM, or e-commerce) as fields on a single request. Rate Service Classic instead routes by URL, with separate endpoints for merchants and ATMs, and has no explicit concept of transaction stage in the rate request itself. If your business needs to distinguish these stages at the rate-request level, for example hospitality or car rental pre-authorizations, factor that into your choice. ## Next steps * [Certificate and JWT authentication](https://docs.fexco.com/dcc/api-reference/authentication/jwt-pki.md): review the certificate and JWT setup required for Rate Service Connect if authentication is your deciding factor. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.