Corpay Cross-Border Solutions | API Resources

Corpay will enforce validation rules on the POST Create/Edit Beneficiary endpoint, allowing only valid region and ZIP/postal code values. If invalid data is provided in these fields, the endpoint will return a 400 Bad Request with an appropriate error message.
We are reaching out to you directly as we have observed that some of the region/zip code values provided in your recent beneficiary payment instructions are invalid.
Therefore, to comply with the updated regulatory requirements, we kindly request that you update your API integration to ensure only valid region and postal code values are provided for U.S. and Canadian beneficiaries by the end of Q1.
We will of course be available to assist with the necessary integration changes in which we have outlined the next steps below (this includes scheduling a call to go through the required changes in detail).

Additional updates have been deployed to Corpay’s Onboarding API documentation to help integrated partners more clearly and accurately review our compliance and regulatory requirements by onboarding region.

This includes a new view that allows partners to see both existing and newly added fields that can be submitted via the API—broken down by region and including expected data types. The updated documentation can be found in the POST Client Onboarding along with the new ‘Onboarding Parameters’ table.

The new fields being referred to above are now available in the Beta environment in which we are working with a pilot partner group for testing. Production deployment of the new set of onboarding fields is expected by the end of December (which will be confirmed in our upcoming release notes).

We’re introducing enhancements to webhooks to give partners better visibility on incoming funds. Partners can now subscribe to receive a JSON notification whenever funds are credited to their MCA or any linked (child) MCA account. This allows you to trigger workflows and take timely actions based on incoming payments. Notifications will only be sent if you’ve subscribed to this event type.

We’re therefore pleased to share that we have now deployed the following two new webhook subscription types:

Incoming Fund Notifications: Partners can now subscribe to receive a JSON notification whenever funds are credited to their MCA or any linked (child) MCA account. This allows you to trigger workflows and take timely actions based on incoming payments. Notifications will only be sent if you’ve subscribed to this event type.

Payments on Hold: We’ve also added a new webhook notification to keep partners informed when payments are placed on hold. If subscribed to this event type, partners will receive a JSON push notification whenever a payment is on hold. This enhancement allows you to track held payments in real time and take appropriate action within your workflows.

We’re introducing a new API endpoint, GET Incoming Funds Details, that allows clients to securely retrieve details of incoming funds credited to their Multi-Currency (MCA) account by order number. The endpoint validates deal ownership to ensure access is restricted to your own transactions.

This new endpoint helps to provide partners and clients with a greater level of detail and visibility into the remitter details and incoming funds being received into their MCAs. Included will be key details such as date, deal number, account information, currency, amount, remitter details, and payment references. If the order number provided is invalid or not linked to your MCA incoming funds, the API will return an error message: “Deal# doesn’t exist.

Following our last communication, we have now deployed valid Purpose of Payment (POP) enforcement when instructing payments to meet updated regulatory/banking requirements. Specifically, when submitting a payment via the following endpoints you will need to provide a Corpay-accepted POP value in the purposeOfPayment request field:

POST Instruct Deal
POST Multiple Payments
POST Book Drawdown

You can retrieve the list of accepted POP values using the GET Purpose of Payment endpoint. Each returned object includes an id which must be used in your payment requests. If the purposeOfPayment field is left blank or populated with an invalid value, a 400 Bad Request error will be returned.

Important Note

While the POP list is consistent for most currencies, certain currencies—such as local INR and wire CNH payments—have unique POP value lists. Using INR as an example, there is a different POP list for INR wires vs. INR EFT. Therefore, it is essential to use the correct POP ID for the corresponding currency and payment method.

If you have any questions on this topic, please don’t hesitate to contact your Corpay account representative.

To comply with updated FINTRAC and related regulatory requirements, users are now required to enter valid region and postal code information for bank and beneficiary addresses in payments made to the United States and Canada. This update is enforced when creating or editing beneficiary information on Corpay Cross-Border via Beneficiary Templates, File Upload, or API.

Specifically for API integrated partners, when using the POST Create/Edit Bene endpoint, if a valid region name or code is not specified the request will return a 400 Bad Request error.

Valid region values can be retrieved using the GET Regions endpoint, where both the ID and Code response values are accepted when creating beneficiary templates. Regarding valid postal codes, the accepted format for US and CA will be returned in our GET Beneficiary Rules endpoint.

IMPORTANT NOTE: This validation enforcement was deployed into Production environment on 7th April 2025. Corpay will continue to collaborate with our existing partners who are temporarily exempt from this new validation rule whilst they made the necessary development changes.

The defaultInternalComment field, previously used in the Create/Edit Bene API endpoint to enter “For Further Credit (FFC)” details, is now renamed to furtherCreditDetails to provide a more intuitive and descriptive label. This update will also be reflected in the Beneficiary Validation and the Get Beneficiary Rules endpoint.

Note: As of 25th April 2025, the old field name is no longer supported. If the old field name is used, the API will return a 200 Success response but the FFC information will not be saved for that bene. To ensure FFC details are saved correctly, partners must use the new field name furtherCreditDetails in the API request.

SWIFT will decommission the current version of its payment tracking service, SWIFT GPI v4, by the end of November 2024. Users of this service will need to transition to SWIFT GPI v5.

What does this change mean for our partners using Corpay’s Payment GPS API?

We are pleased to confirm that no changes are required for partners using Corpay Cross-Border’s Payment Tracking endpoints to retrieve SWIFT GPI v5 tracking statuses. Corpay has already completed the necessary updates to implement and deploy SWIFT GPI v5 capabilities within our Payments GPS product offering.

Over the past few weeks, we have thoroughly tested the SWIFT GPI v5 changes to ensure our Payments GPS API continues to provide accurate tracking statuses on the payment network. However, if you encounter any issues, discrepancies, or have questions about this update, please don’t hesitate to reach out to us.

Finally, we would like to extend our sincere thanks to our pilot partners who helped test the SWIFT GPI v5 changes ahead of the wider Production deployment. Your support and invaluable feedback played a crucial role in the success of the testing phase, and we truly appreciate your contributions.

After reviewing the results of our recent partner product feedback and ideas submission, many of you requested a dedicated beneficiary validation API endpoint. This would allow you to test beneficiary details without creating a template on Corpay’s side if the details pass all validation checks. Previously, partners could only use Corpay’s ‘POST Create/Edit Bene’ endpoint to validate beneficiary data.

We are therefore pleased to confirm that we have now developed and deployed a new POST Beneficiary Validation endpoint. This will enable partners to validate a new beneficiary template submission without creating the template if the validation is successful.

To comply with Fintrac and other regulatory requirements, PO Box addresses and similar variations are now restricted in the address fields when creating or editing beneficiary information on Corpay Cross-Border through the API and UI.

When using our POST Create/Edit Beneficiary endpoint, entering a PO Box address in the beneficiary address fields will now return a REGEX_MISMATCH error. This restriction currently applies to Australia, Canada, and Mexico which is now also reflected in the returned address RegEx of our GET Beneficiary Rules endpoint. The update ensures that a complete physical address is provided, as required by regulatory standards

A few partners noticed a discrepancy in the header documented for our POST Partner-level Token Login endpoint. Specifically, there was a header entry titled CMG-AccessToken with a value of “toBeDiscontinued.” If you have downloaded our API collection into your Postman instance or codebase, this header may also appear in your Production environment.

Corpay’s development team has confirmed that this header should not be included in the POST Partner-level Token Login endpoint. We have since removed it from our documentation. If you are currently passing the CMG-AccessToken with the ‘toBeDiscontinued’ value in this endpoint’s header, please ensure it is removed. This has been identified as a potential root cause of some recent timeout errors partners have encountered when authenticating with our API.

CMG-AccessToken ‘toBeDiscontinued’ header has now been removed from our API documentation.

Previously, when using Corpay’s Mass Payment APIs, the payment GPS tracker Id’s were not returned in the POST Multiple Payment response. Therefore, clients would need to make a subsequent call to our GET Lookup Orders API to retrieve the payment tracker Id’s in which they weren’t always available straight away.

We have now deployed an update in which the payment GPS tracker Id’s are now returned immediately in the POST Multiple Payment API response. This removes the need to make any subsequent follow-up API requests and allows clients to store the tracker Id’s during the Mass Payment workflow immediately.

You can find an example of the update below:

As part of our continuous development of Corpay’s Onboarding API suite, we have now added an Authentication Retrieval API endpoint. Previously, when a partner onboarded a new client account via the API, the secret keys for authentication were sent via an encrypted email. However, our new GET AuthSecret Keys endpoint will now allow partners to retrieve the secret keys for a newly onboarded client account directly via the API (helping to automate the end-to-end flow).

This new endpoint helps to further streamline the client onboarding process for all our integrated partners. Retrieving the secret keys via the API significantly reduces the turnaround time of a client’s account being operational and ready for use with our wider services.

*Future Update: In Corpay’s first iteration of its upcoming Webhook deployment (scheduled for Q3), a push notification subscription will be available for the Onboarding API. This will allow for a push notification to be sent to our partners whenever one of their onboarded client accounts has been approved by Corpay’s Compliance team.

You can find an example of the GET AuthSecret Keys below:

We are enhancing IP Whitelisting to improve security, flexibility, and performance across our API services. This update introduces:

Whitelisting at both client and partner levels
Support for IPv4, IPv6, and valid CIDR ranges (e.g., 192.0.2.0/24)
Removal of SQL LIKE syntax (e.g., % wildcards will no longer be supported)
Improved access control with cached authentication for faster performance

These changes provide stronger protection against unauthorized access and greater flexibility in network management.

This enhancement is scheduled for deployment in Q1 2026, with further details to follow in upcoming communications.

As shared in previous updates, Corpay has implemented internal flow changes to align with the Confirmation of Payee (CoP) and Verification of Payee (VoP) frameworks.

Confirmation of Payee: CoP is a UK name-checking service used for domestic GBP payments via FPS, Bacs, and CHAPS. It validates that the payer-entered name matches the account holder’s name, helping prevent fraud and misdirected payments.
Verification of Payee: VoP is the EU framework that validates payment account numbers and counterparty names prior to initiating SEPA Credit Transfer (CT) or SEPA Instant payments.

Both verification schemes are now fully supported within Corpay’s payment infrastructure for all applicable incoming and outgoing payment flows.

We are now actively building these capabilities into our REST API workflows. This will require:

Migration to new API versions of existing beneficiary creation endpoints.
New verification endpoints.

Further details, including timelines and Beta availability—will be provided in future communications. Initial availability is forecast for Q1 2026.

We are preparing to release an updated version of our GET Beneficiary Rules endpoint (internally known as the “Template Guide”) in the first half of 2026.

Current Endpoints:

api/template-guide
api/{clientCode}/{clientDivisionId}/template-guide

New Endpoints:

api/template-guide-rules
api/{clientCode}/{clientDivisionId}/template-guide-rules

The key enhancements within the newer version of the GET Beneficiary Rules endpoint are as follows:

Region Value Return: The API response will now return a list of accepted region values based on the specified ‘destinationCountry’ and ‘bankCountry’ parameters. This ensures users populate compliant region values when submitting beneficiary creation requests via POST Create/Edit Bene.
New Routing Code Parameter: A new optional routingCode parameter will support accurate beneficiary rule retrieval for CAD (Canada) This improvement resolves challenges related to variations in account number digit lengths across Canadian banks and institutions.

Again, we will provide further details and timeline expectations once the new endpoint version is available in Beta (sandbox) for partners to test/develop to.

To further enhance our Multi-Currency Account (MCA) offering, we will be introducing new bank-style statements and reporting in the first half of 2026. This release will include a new MCA Statement endpoint, which will eventually replace the existing GET Multi-Currency Accounts History endpoint.

Both the current GET Multi-Currency Accounts History endpoint and the new MCA Statement endpoint will run in parallel for a transition period to support partners in updating their integrations. We will provide detailed specifications, sample responses, and deprecation timelines as part of our Q1 2026 communication.

Over recent months, we have been keeping partners informed of Corpay’s progress toward full adoption of ISO20022 and MX messaging.

We are pleased to confirm that as of 22 November 2025, Corpay has fully transitioned to ISO20022 for all cross-border payment messages, meeting the SWIFT coexistence deadline.

We extend our thanks to all partners who participated in testing and provided valuable feedback throughout this transition. Achieving full ISO adoption now allows us to focus on expanding our ISO20022 MX ingestion and reporting capabilities into 2026, enabling a wider range of solution enhancements in this area.

1. What is ISO 20022 and why is it being adopted?

ISO 20022 is a global messaging standard for payments that enables richer, more structured data. It’s being adopted to improve processing efficiency, support regulatory compliance, and enhance interoperability across markets.

2. How does ISO 20022 differ from existing MT formats?

ISO 20022 is a modern XML-based messaging standard designed to replace the older MT (Message Type) formats used in SWIFT payments. Unlike MT messages, which are text-based and somewhat rigid, ISO 20022 (MX messages) allows for richer, more structured data, enabling clearer and more detailed information to accompany each payment. This leads to improved processing, enhanced compliance, and better interoperability across global payment systems.

3. Is ISO 20022 mandatory for me as a client?

While ISO 20022 is primarily mandated for financial institutions and market infrastructures, it may affect how you exchange payment files, especially if you're using structured formats or working with global banks.
Corpay is actively aligning with the standard to ensure compliance and support client readiness. We’ll work with you to ensure compatibility, so you can benefit from enhanced quality of data, improved reconciliation, and greater payment transparency without major changes to your internal systems.

4. What are the benefits for my organization?

ISO 20022 enables better reconciliation, more accurate compliance screening, enhanced remittance information, and fewer payment delays, contributing to real-time payments and operational efficiency.

5. How do MX messages enhance compliance monitoring?

MX messages use a structured format that improves transaction screening, monitoring, and regulatory reporting, helping detect fraud and support AML compliance.

However, these benefits can only be fully realized when ISO 20022 is adopted end-to-end. Many institutions are currently using 1-to-1 MT-to-MX mappings, which often result in data loss or truncation. This limits the effectiveness of compliance tools. Until full adoption, expected by November 2025 these improvements may take time to materialize.

6. Do I need to change my file formats or systems to support MX Messages?

Possibly. If you send or receive structured payment files (like XML or SWIFT messages), updates may be needed. We offer guidance and tools to help you assess the impact and prepare for changes.

7. When is migration happening?

The global migration to ISO 20022 for Cross-Border payments is currently in progress. SWIFT began its coexistence period supporting both MT (legacy) and MX (ISO 20022) message formats in March 2023. This coexistence period will end with SWIFT’s November 2025 standard release (planned for November 22, 2025).

Corpay Cross-Border has already started transitioning to MX-format messages. During this period, you may see either format depending on the payment flow. We are committed to ensuring a smooth transition and continued support throughout this industry-wide change.

8. Will there be disruptions during the transition?

No, we do not anticipate any disruptions to your payment processing during the transition. Corpay Cross-Border is implementing ISO 20022 changes in a phased and controlled manner to ensure continuity and stability.

Both MT and MX message formats will be supported during SWIFT’s coexistence period through November 22, 2025, allowing for a smooth migration. While we strive for a seamless experience, there may be occasional issues caused by factors within or outside of Corpay's control, such as third-party system updates or network conditions. These instances are expected to be rare and will be managed promptly to minimize impact.

If you have any concerns about your systems or processes, we encourage you to reach out to your Corpay Cross-Border Relationship Manager.

9. How can I access MX message?

Payment message copies will still be accessible in the same locations via the Corpay Cross-Border web platform and API. However, as part of the ISO 20022 transition, the format of these messages is changing from MT (legacy SWIFT) to MX (XML-based ISO 20022).

Whilst in the transition phase, Corpay will support and show both MT and MX message types. Once Corpay completes its transition journey all payments will be exited in the new ISO format (MX). This will not impact historical payment or payment existed before the said timeline will status in their respective format.

10. What should I do to prepare?

To prepare, we recommend familiarizing yourself and any downstream systems or teams with the new structure and terminology. While the content remains consistent, the way data is labeled and organized will be different. Below is a table highlighting the most critical field changes:

11. Will I still be able to send MT messages?

Corpay has already begun transitioning to the ISO 20022 (MX) message format across our platform as part of our commitment to industry standards and regulatory readiness.

Going forward, all payments will default on MX formatting.

While MT messages are technically supported during the SWIFT coexistence period (until November 22, 2025), Corpay will only allow MT messages in exceptional cases, and these will be assessed on a case-by-case basis.

If you believe your institution has a valid exception or require support during this transition, please contact your Corpay Relationship Manager for further assistance.

We’re here to ensure your migration to ISO 20022 is seamless and future ready.

Where can I get support or more information?

For any additional questions or support, please reach out to your Corpay Cross-Border Relationship Manager.

What is the Event?

Corpay’s Forwards creation workflow has been updated in the v1.8 API suite.

Who is Impacted?

Users of Corpay Cross-Border’s Forwards API functionality.

What are the details?

Corpay’s POST Accept Terms API endpoint was deprecated on August 26th, 2023.

To streamline our Forward workflow and reduce the number of endpoints that need to be called to successfully complete a Forward order, the POST Accept Terms API endpoint for the v1.8 suite was made obsolete as of the advised date.

Partner’s are no longer required to send an ‘Accept Terms’ API request and instead, will complete their Forward booking with the existing POST Complete Order API endpoint.

Scheduled Event Time?

Removed on August 26th, 2023.

Contact:

If you have any questions regarding this Production API update, please contact: technicalsales@corpay.com

As detailed in the ‘Beneficiary Validation Best Practices’ section, Corpay will be enforcing SWIFT BIC as a mandatory field when creating beneficiaries — originally set for December 4th. This means that when creating beneficiary templates of any currency/country via the POST Create/Edit API endpoint, you will be required to populate the swiftBicCode parameter. This change will also be reflected in our GET Beneficiary Rules API endpoint in which the swiftBicCode parameter will always show as ‘IsRequired – True’ (meaning it is a required field).

Furthermore, we will soon be updating our Beta (sandbox) environment to enforce SWIFT BIC. This will allow our partners to test how this change may impact their current beneficiary workflow integrations with Corpay’s API ahead of the Production deployment date. We will send an additional communication once the Beta environment has been updated with the new SWIFT BIC requirement in which the regEx for SWIFT will be: ^[A-Z0-9]{8,11}$.

We are postponing the effective date to develop a beta environment and additional support mechanisms to lessen the impact of the transition on our partners and clients. We are committed to moving to mandatory SWIFT BIC fields in the near future.

An IBAN (International Bank Account Number) is used to identify an individual account (the ultimate beneficiary) within banking institutions.

Corpay strongly recommends including IBAN for any currency directed to an IBAN country.

The Corpay team greatly values our partnership! Please reach out to your Corpay Representative for any questions related to our Currency Capabilities, Product and Technology offerings.

*Please note: Where SWIFT/BIC and IBAN are not currently mandatory, this is subject to change with a 90 day notice period.

Beneficiary Rules (Template Guide)

The GET Beneficiary Rules endpoint allows partners to retrieve the required data fields for creating beneficiary templates and initiating payments. Requirements are based on:

Country
Currency
Beneficiary Type (Business or Individual)
Payment Method (Wire or Local)

The API will then return the key requirements/rules needed to successfully create the beneficiary template including:

Mandatory fields required for the POST Create/Edit Bene call.
Regex validation patterns, defining field format, structure, and character length.
Country-specific regulatory requirements, such as contact information and tax codes.

Benefits:

Partners can dynamically display the correct input fields and formats within their own UIs.
Reduces the chance of input errors and improves the success rate of beneficiary creation and payment execution.

IBAN Validation

A commonly used tool our partners incorporate into their beneficiary management flows whenever the account number is an International Bank Account Number (IBAN) is our POST IBAN Validation endpoint. This allows them to validate in real-time whether the IBAN provided by a customer is valid (i.e., it meets the formatting and character length requirements for that country).

In summary, it allows partners to:

Validate that the IBAN meets country-specific format and length requirements
Retrieve associated bank details, including:
- SWIFT BIC
- Routing Code
- Bank Name
- Bank Address

Benefits:

Ensures the IBAN is valid and correctly formatted.
Enables auto-population of bank fields, reducing manual input and minimizing errors.

Bank Search

For non-IBAN countries, partners can utilise our GET Bank Search API to retrieve results based on specified query criteria. Again, this allows partners to retrieve the corresponding banking information associated with the details provided and allows the partner/user to auto-populate the required banking information with valid data.

Search criteria that can be submitted includes:

Bank Name
Routing Code
SWIFT BIC
Bank Address

The API will then return:

Detailed bank information to help populate required fields.
Narrowed results due to its multiple criteria search capability in a single request.

Benefits:

Enables an intuitive, dynamic user experience.
Improves accuracy by helping users select the correct bank from potential matches.
Reduces friction and manual input by auto-filling bank details with validated data.

“Cambridge Mercantile” and “AFEX” and “Associated Foreign Exchange” and “Corpay” are names that may be used for Corpay Cross-Border services (international payment solutions and risk management solutions) provided by certain affiliated entities, all using the “Corpay” brand. International payment solutions are provided in Australia through Cambridge Mercantile (Australia) Pty. Ltd.; in Canada through Cambridge Mercantile Corp.; in the United Kingdom through Cambridge Mercantile Corp. (UK) Ltd.; in Ireland and the European Economic Area through Associated Foreign Exchange Ireland Ltd.; in Jersey through AFEX Offshore Ltd.; in New Zealand through Corpay (NZ) Limited; in Singapore through Associated Foreign Exchange (Singapore) Pte. Ltd. and in the United States through Cambridge Mercantile Corp. (U.S.A.). Risk management solutions are provided in Australia through Cambridge Mercantile (Australia) Pty. Ltd.; in Canada through Cambridge Mercantile Corp.; in the United Kingdom through Cambridge Mercantile Risk Management (UK) Ltd.; in Ireland and the European Economic Area through AFEX Markets Europe Ltd.; in Jersey through AFEX Offshore Ltd.; in New Zealand through Corpay (NZ) Limited; in Singapore through Associated Foreign Exchange (Singapore) Pte. Ltd. and in the United States through Cambridge Mercantile Corp. (U.S.A.). Please refer to http://cross-border.corpay.com/brochure-disclaimers for important terms and information.

Corpay Cross-Border SolutionsAPI Resources

API Release Notes and Upcoming Changes

Corpay Cross-Border has launched a new developer portal which contains a variety of guides and resources, as well as our API documentation. The purpose of the portal is to further support our partners who are integrated (or in the process of integrating) with our API suite.

You can access the new developer portal and API documentation via the direct links below:

Corpay’s Postman collection is still available for you to download all our API endpoints to your own instance of Postman. The Postman documentation link can be found within the developer portal.

*Have feedback or thoughts on what you would like to see on this new portal? Then please don’t hesitate to share your suggestions with technicalsales@corpay.com in which all feedback is welcome!

Region & Zip Enforcement (US & CA)

To comply with updated FINTRAC and related regulatory requirements, Corpay Cross-Border must ensure that valid region and ZIP/postal code information is included for both bank and beneficiary addresses in payments made to the U.S. and Canada.

What Does This Mean for You?

API Release Notes

December 2025

Onboarding API Documentation Improvements

Onboarding API Picklist Update

Alongside the documentation improvements and available fields, we have expanded the list of picklist types retrievable via GET Onboarding Picklists. This enhancement helps ensure partners use Corpay-accepted values when submitting onboarding requests.

Below is the full list of picklists now available, including both existing and newly added entries:

Annual Volume Range

Applicant Type

Business Type

Client Intends to Use Corpay Account To (NEW)

Expected Frequency Of Transactions (NEW)

Id Type (NEW)

Nature of Business (NEW)

Purpose of Transaction

Routing (NEW)

Settlement Method (NEW)

Source of Funds (NEW)

Source of Wealth (NEW)

Total Assets or Net Worth (NEW)

Trade volume Range

Webhook Enhancements

Incoming Funds API Endpoint

Purpose of Payment Enforcement

POST Instruct Deal

POST Multiple Payments

POST Book Drawdown

Purpose of Payment Expansion

Following feedback from our partners, we have expanded our standard GET Purpose of Payment list to include additional values:

Royalties

Reimbursement Payment

Winnings

Currency Edits on Existing Bene Template

Onboarding API Picklist Update

We've updated the GET Onboarding Picklist endpoint to include additional values for the Purpose of Transactions picklist. Partners can now include specific Purpose of Transaction details to support compliance requirements.

Onboarding API Documentation Improvements

MCA Nickname Endpoint

We've updated the GET Onboarding Picklist endpoint to include additional values for the Purpose of Transactions picklist. Partners can now include specific Purpose of Transaction details to support compliance requirements.

Activated – Deactivated Status of MCA Accounts

We have added a new ‘isActive’ parameter to our GET View Multi-Currency Accounts endpoint to make it easier for our partners to identify active and disabled MCA’s they hold with Corpay.

Payment Channel Information (MT & MX)

Based on the payment method used, the GET Payment Channel API will now return either SWIFT MT103 or SWIFT MX Pacs.008.001.08 raw details in the response payload. The corresponding status in the response will be displayed as MT103 or Pacs.008.001.08 .

Beneficiary & Bank Region Enforcement

Further Credit (FFC)

SWIFT GPI v5 Update

Validate API Endpoint

Beneficiary Address Lines – PO Box Update

Onboarding API Documentation Update

Partner-Level Token Documentation Update

Token Endpoint – Error Response Update

We have updated the POST Partner and POST Client level token endpoints to return a 400 HTTPS error for null or invalid form data, instead of the previously returned 500 error. This update improves error handling.You can find an example of the update below:

Mass Payment – Tracker Ids

Authentication Retrieval API

Onboarding API

What value does onboarding API provide to partners?

Automated APIs eliminate the manual process of submitting requests, increases efficiency, and expedites the process resulting in reduced time to revenue for partners.

Consistent and accurate onboarding requests from different partners ensure improved SLA between Corpay and our Partners as well as between Partners and their downstream clients.

The automated process increases the scalability of onboarding new clients for partners.

Partners will have access to up-to-date onboarding Terms and Conditions (T&C), thus ensuring their downstream clients comply and submit requests based on the most recent requirements.

With our onboarding APIs, partners will have access to a faster and more streamlined process to onboard their downstream clients thus improving their customer onboarding experience.

Current status: North America is live, other global jurisdictions currently in Beta.

Push Notifications

Benefits to Push Notifications

With instant notifications and increased data visibility, you can improve your customer experience by being informed about the data that matters to you and your client.

Events covered under push notifications via webhooks:

Payments GPS

— Payment Accepted— Payment Processed— Payment Tracking Info Received— Payment Processed Non-Swift

Onboarding

— Account Approved

Current status: Testing is in progress on Beta environment, with our partners. Full Rollout is expected in Jan 2024.

Upcoming Updates

IP Whitelisting

Corpay Cross-Border Solutions
API Resources

We have updated the POST Partner and POST Client level token endpoints to return a 400 HTTPS error for null or invalid form data, instead of the previously returned 500 error. This update improves error handling.

You can find an example of the update below:

— Payment Accepted
— Payment Processed
— Payment Tracking Info Received
— Payment Processed Non-Swift

These changes provide stronger protection against unauthorized access and greater flexibility in network management.

This enhancement is scheduled for deployment in Q1 2026, with further details to follow in upcoming communications.

ISO 20022 enables better reconciliation, more accurate compliance screening, enhanced remittance information, and fewer payment delays, contributing to real-time payments and operational efficiency.

5. How do MX messages enhance compliance monitoring?

Possibly. If you send or receive structured payment files (like XML or SWIFT messages), updates may be needed. We offer guidance and tools to help you assess the impact and prepare for changes.

7. When is migration happening?

MT Field
MT103

MX Field
pacs.008