Comms Log
View our technical communications log, listing communications we have previously circulated to our merchants. Depending on your:
- Integration type
- SDK
- Payment flows
This may have an impact for all merchants, or be merchant specific.
15th October
Judopay Portal: We’re updating the way you log in.
In the coming weeks we’re updating the way you log in to the Judopay Portal.
Due to upcoming industry security requirements we will be enabling 2 Factor Authentication (2FA) for your Judopay Portal login, prior to the March 2025 deadline. This means that you’ll need to enter a one-time code (that will be sent to the associated email address) every time you log in to the Portal.
For more info on 2FA for the Portal visit our Support Centre here.
When is this launching? We’re doing some final tests before we roll this out to everyone. Unless someone at your business requests early access to 2FA for your account, we’ll notify you as soon as we have an official launch date in the coming weeks.
Action needed to prepare for 2FA launch.
Make sure you can access the mailbox linked to your login. The one-time code will be sent to the email address used to log in to the Portal. Make sure that you can easily access this mailbox or if you need to change the associated email address, or create new accounts, just drop us a message at [email protected]
Want early access to 2FA? Email: [email protected]
If you request early access to 2FA, it will be enabled early for all users on your account.
24th July
Platform updates: these may require some technical updates to your integration.
A final reminder that we have some upcoming platform updates that may require some technical updates to your integration.
If you've already actioned the below please ignore.
These changes will affect customers who are using Judopay API 6.0 upwards (both via SDK or direct integration). These changes will come into effect from 31st July 2024.
Please forward this on to the relevant contact if you're not responsible for the below updates, or ask them to reach out to us at [email protected].
Why we are updating our platform:
This year we are rolling out the final parts of our enhanced new technology platform. This new platform - when fully deployed will give you access to an even better processing performance, including:
- Enhanced performance and reliability; our cloud architecture will enable greater resilience and infinite capacity.
- Even greater security; every project will now be auto-embedded with thoroughly tested and certified standards.
- More products and features: the platform will allow us to build, launch and iterate features in record time.
The #8 updates that we’re making.
The below updates will only apply to you if you’re using the mentioned fields, values, formats etc. Please do get in touch with the Judopay team if you need any support.
Update #1 Judopay will no longer be generating, storing or returning consumerTokens in transaction responses.
- This change is aimed at removing the requirement to handle redundant data that is not used for transaction processing flows.
- The only consumer reference that will be provided in the response will be “yourConsumerReference” - this is the reference provided by the merchant in the inbound request.
- This field has been deprecated on older versions of the Judopay Transaction API and will not be returned from Judopay Transaction API version 6.0 onwards.
- We understand that consumer tokens may have been utilised for various purposes, and we’re available to assist you in adapting to this new approach if you have a dependency on this value.
Update #2 The format of deviceIdentifier will be changing.
- Previously, the device.identifier value was a GUID (Globally Unique Identifier) generated by the Judopay platform.
- As part of our ongoing improvements, we’ve decided to leverage the unique device identifiers that we gather from the consumers’ device during the checkout process (kDeviceId) - instead of generating new ones.
- Please note that the length of the deviceIdentifier returned can be up to 36 characters.
Update #3 Some attributes are being dropped from the Judopay Transaction API requests and responses.
We have identified certain attributes in our API that are currently not being used or are being duplicated by other attributes. These attributes will no longer be used in requests or returned in Judopay Transaction API responses. These include:
- address3 (not used)
- line1, line2, line3 (not used)
- cardQualifier (not used)
- city (use attribute ‘town’ instead)
Additionally, we will no longer be returning the threeDSecure block in the responses to ‘cross-reference’ transactions such as refunds, voids and captures.
Update #4 Some values in the responses will be returned in upper case.
The values returned in the following attributes in the transaction responses will be in upper case:
- cardScheme
- cardCategory
- bank
Update #5 When processing Apple and Google Pay transactions, the cardType may be “unknown” in the response in some cases.
- We've identified that the cardType attribute returned in transaction responses are not always accurate when using wallet payments.
- We will now only return the cardType in the response when it is available to us directly from the Apple / Google Pay payload that we retrieve. Otherwise, the cardType will be returned as a ‘0’ to indicate that it is ‘unknown’ as listed in our documentation.
Update #6 The Judopay APIs are becoming case sensitive.
- This change aims to standardise the casing conventions and ensure consistency across our API ecosystem.
- While our API documentation has always specified the use of camelCase, it has not been strictly enforced in the past, allowing flexibility in the casing of attribute names. However, moving forward, we will be enforcing case sensitivity in all of our APIs.
- The only accepted cases will be camelCase and PascalCase.
Update #7 The calculation of ‘netAmount’ has been updated to be more consistent in immediate and historic receipts for collections and refunds.
- The aim of this change is to ensure that the netAmount returned in our responses was accurate and appropriate to the type of transaction response.
- The concept of ‘netAmount’ differs based on transaction type. This is documented in our API reference.
- As a reminder, if you are just looking for the amount associated with a specific refund or collection, the field that reflects this in the response is ‘amount’.
Update #8 Deprecation of Register Card functionality
- Acquirers and issuers are actively requesting users to switch to the newer alternative - Checkcard - to verify card holders since this provides a better user experience.
- Checkcard allows you to verify a cardholder with a 'zero value' preauthorization, ensuring the card's validity without charging the customer.
- Please update your integration to use the Checkcard feature instead. Checkcard is available via the following integration methods:
Additional reminders:
- “OneUseToken” authentication: is no longer supported (this was effective from 6 June 2024). A separate email was sent to merchants we identified as still using this, with details on next steps.
- MIT Processing: please check that you are always sending a ‘relatedReceiptId’ when processing Merchant Initiated Transactions (MIT). The ‘relatedReceiptId’ that is referenced should be associated to a Customer Initiated Transaction (CIT).
- Judopay Transaction API: We recommend that you upgrade to using the latest Judo API version 6.21 if you’re integrated to us directly via the Judopay APIs for any of your transactional flows.
- SDKs: If you’re integrated to us via one of our SDKs, please ensure that you’re using the latest version.
Comparison between the old and the new transaction response bodies:
Old Response Example:
New Response Example:
11th July
Platform updates: these may require some technical updates to your integration.
These changes will come into effect from 31st July 2024.
We have some important updates and info to share about our platform and some upcoming technical changes that may require some updates to your integration.
Please note, these changes will affect merchants who are using Judopay Transaction API 6.0 upwards (both via the SDKs or direct integrations). These changes will come into effect from 31st July 2024.
Why we are updating our platform:
This year we are rolling out the final parts of our enhanced new technology platform. This new platform - when fully deployed will give you access to an even better processing performance, including:
- Enhanced performance and reliability; our cloud architecture will enable greater resilience and infinite capacity.
- Even greater security; every project will now be auto-embedded with thoroughly tested and certified standards.
- More products and features: the platform will allow us to build, launch and iterate features in record time.
The #8 updates that we’re making.
The below updates will only apply to you if you’re using the mentioned fields, values, formats etc. Please do get in touch with the Judopay team if you need any support.
Update #1 Judopay will no longer be generating, storing or returning consumerTokens in transaction responses.
- This change is aimed at removing the requirement to handle redundant data that is not used for transaction processing flows.
- The only consumer reference that will be provided in the response will be “yourConsumerReference” - this is the reference provided by the merchant in the inbound request.
- This field has been deprecated on older versions of the Judopay Transaction API and will not be returned from Judopay Transaction API version 6.0 onwards.
- We understand that consumer tokens may have been utilised for various purposes, and we’re available to assist you in adapting to this new approach if you have a dependency on this value.
Update #2 The format of deviceIdentifier will be changing.
- Previously, the device.identifier value was a GUID (Globally Unique Identifier) generated by the Judopay platform.
- As part of our ongoing improvements, we’ve decided to leverage the unique device identifiers that we gather from the consumers’ device during the checkout process (kDeviceId) - instead of generating new ones.
- Please note that the length of the deviceIdentifier returned can be up to 36 characters.
Update #3 Some attributes are being dropped from the Judopay Transaction API requests and responses.
We have identified certain attributes in our API that are currently not being used or are being duplicated by other attributes. These attributes will no longer be used in requests or returned in Judopay Transaction API responses. These include:
- address3 (not used)
- line1, line2, line3 (not used)
- cardQualifier (not used)
- city (use attribute ‘town’ instead)
Additionally, we will no longer be returning the threeDSecure block in the responses to ‘cross-reference’ transactions such as refunds, voids and captures.
Update #4 Some values in the responses will be returned in upper case.
The values returned in the following attributes in the transaction responses will be in upper case:
- cardScheme
- cardCategory
- bank
Update #5 When processing Apple and Google Pay transactions, the cardType may be “unknown” in the response in some cases.
- We've identified that the cardType attribute returned in transaction responses are not always accurate when using wallet payments.
- We will now only return the cardType in the response when it is available to us directly from the Apple / Google Pay payload that we retrieve. Otherwise, the cardType will be returned as a ‘0’ to indicate that it is ‘unknown’ as listed in our documentation.
Update #6 The Judopay APIs are becoming case sensitive.
- This change aims to standardise the casing conventions and ensure consistency across our API ecosystem.
- While our API documentation has always specified the use of camelCase, it has not been strictly enforced in the past, allowing flexibility in the casing of attribute names. However, moving forward, we will be enforcing case sensitivity in all of our APIs.
- The only accepted cases will be camelCase and PascalCase.
Update #7 The calculation of ‘netAmount’ has been updated to be more consistent in immediate and historic receipts for collections and refunds.
- The aim of this change is to ensure that the netAmount returned in our responses was accurate and appropriate to the type of transaction response.
- The concept of ‘netAmount’ differs based on transaction type. This is documented in our API reference.
- As a reminder, if you are just looking for the amount associated with a specific refund or collection, the field that reflects this in the response is ‘amount’.
Update #8 Deprecation of Register Card functionality
- Acquirers and issuers are actively requesting users to switch to the newer alternative - Checkcard - to verify card holders since this provides a better user experience.
- Checkcard allows you to verify a cardholder with a 'zero value' preauthorization, ensuring the card's validity without charging the customer.
- Please update your integration to use the Checkcard feature instead. Checkcard is available via the following integration methods:
Additional reminders:
- “OneUseToken” authentication: is no longer supported (this was effective from 6 June 2024). A separate email was sent to merchants we identified as still using this, with details on next steps.
- MIT Processing: please check that you are always sending a ‘relatedReceiptId’ when processing Merchant Initiated Transactions (MIT). The ‘relatedReceiptId’ that is referenced should be associated to a Customer Initiated Transaction (CIT).
- Judopay Transaction API: We recommend that you upgrade to using the latest Judo API version 6.21 if you’re integrated to us directly via the Judopay APIs for any of your transactional flows.
- SDKs: If you’re integrated to us via one of our SDKs, please ensure that you’re using the latest version.
Comparison between the old and the new transaction response bodies:
Old Response Example:
New Response Example:
28th June
Platform updates: these may require some technical updates to your integration.
We have some important updates and info to share about our platform and some upcoming technical changes that may require some updates to your integration.
Please note, these changes will affect merchants who are using Judopay Transaction API 6.0 upwards (both via the SDKs or direct integrations). These changes will come into effect from 31st July 2024.
Why we are updating our platform:
This year we are rolling out the final parts of our enhanced new technology platform. This new platform - when fully deployed will give you access to an even better processing performance, including:
- Enhanced performance and reliability; our cloud architecture will enable greater resilience and infinite capacity.
- Even greater security; every project will now be auto-embedded with thoroughly tested and certified standards.
- More products and features: the platform will allow us to build, launch and iterate features in record time.
The #8 updates that we’re making.
The below updates will only apply to you if you’re using the mentioned fields, values, formats etc. Please do get in touch with the Judopay team if you need any support.
Update #1 Judopay will no longer be generating, storing or returning consumerTokens in transaction responses.
- This change is aimed at removing the requirement to handle redundant data that is not used for transaction processing flows.
- The only consumer reference that will be provided in the response will be “yourConsumerReference” - this is the reference provided by the merchant in the inbound request.
- This field has been deprecated on older versions of the Judopay Transaction API and will not be returned from Judopay Transaction API version 6.0 onwards.
- We understand that consumer tokens may have been utilised for various purposes, and we’re available to assist you in adapting to this new approach if you have a dependency on this value.
Update #2 The format of deviceIdentifier will be changing.
- Previously, the device.identifier value was a GUID (Globally Unique Identifier) generated by the Judopay platform.
- As part of our ongoing improvements, we’ve decided to leverage the unique device identifiers that we gather from the consumers’ device during the checkout process (kDeviceId) - instead of generating new ones.
- Please note that the length of the deviceIdentifier returned can be up to 36 characters.
Update #3 Some attributes are being dropped from the Judopay Transaction API requests and responses.
We have identified certain attributes in our API that are currently not being used or are being duplicated by other attributes. These attributes will no longer be used in requests or returned in Judopay Transaction API responses. These include:
- address3 (not used)
- line1, line2, line3 (not used)
- cardQualifier (not used)
- city (use attribute ‘town’ instead)
Additionally, we will no longer be returning the threeDSecure block in the responses to ‘cross-reference’ transactions such as refunds, voids and captures.
Update #4 Some values in the responses will be returned in upper case.
The values returned in the following attributes in the transaction responses will be in upper case:
- cardScheme
- cardCategory
- bank
Update #5 When processing Apple and Google Pay transactions, the cardType may be “unknown” in the response in some cases.
- We've identified that the cardType attribute returned in transaction responses are not always accurate when using wallet payments.
- We will now only return the cardType in the response when it is available to us directly from the Apple / Google Pay payload that we retrieve. Otherwise, the cardType will be returned as a ‘0’ to indicate that it is ‘unknown’ as listed in our documentation.
Update #6 The Judopay APIs are becoming case sensitive.
- This change aims to standardise the casing conventions and ensure consistency across our API ecosystem.
- While our API documentation has always specified the use of camelCase, it has not been strictly enforced in the past, allowing flexibility in the casing of attribute names. However, moving forward, we will be enforcing case sensitivity in all of our APIs.
- The only accepted cases will be camelCase and PascalCase.
Update #7 The calculation of ‘netAmount’ has been updated to be more consistent in immediate and historic receipts for collections and refunds.
- The aim of this change is to ensure that the netAmount returned in our responses was accurate and appropriate to the type of transaction response.
- The concept of ‘netAmount’ differs based on transaction type. This is documented in our API reference.
- As a reminder, if you are just looking for the amount associated with a specific refund or collection, the field that reflects this in the response is ‘amount’.
Update #8 Deprecation of Register Card functionality
- Acquirers and issuers are actively requesting users to switch to the newer alternative - Checkcard - to verify card holders since this provides a better user experience.
- Checkcard allows you to verify a cardholder with a 'zero value' preauthorization, ensuring the card's validity without charging the customer.
- Please update your integration to use the Checkcard feature instead. Checkcard is available via the following integration methods:
Additional reminders:
- “OneUseToken” authentication: is no longer supported (this was effective from 6 June 2024). A separate email was sent to merchants we identified as still using this, with details on next steps.
- MIT Processing: please check that you are always sending a ‘relatedReceiptId’ when processing Merchant Initiated Transactions (MIT). The ‘relatedReceiptId’ that is referenced should be associated to a Customer Initiated Transaction (CIT).
- Judopay Transaction API: We recommend that you upgrade to using the latest Judo API version 6.21 if you’re integrated to us directly via the Judopay APIs for any of your transactional flows.
- SDKs: If you’re integrated to us via one of our SDKs, please ensure that you’re using the latest version.
Comparison between the old and the new transaction response bodies:
Old Response Example:
New Response Example:
28th May
Urgent update needed to your Mobile SDK before 15 June.
An urgent update is needed for iOS, Android and React Native Mobile SDKs.
While the Visa deadline to complete this update is 22nd August, Mastercard’s have enforced a deadline of 15th June. Making this update urgent.
Details below on:
- Why do you need to make this update?
- Update details.
- How to update your Mobile SDK.
Why do you need to make this update? This update is crucial in maintaining secure transactions and compliance with Mastercard and Visa’s requirements. Mastercard & Visa have mandated that all 3DS2 authentication users via mobile SDKs must update to the latest encryption certificates.
To ensure you don’t see an increase in 3DS2 authentication failures and to maintain the highest level of security and compliance with industry standards, you must update your apps to use the latest versions before the 15th June 2024.
Update details.
iOS SDK Updates include:
- The latest iOS SDK (v3.4.1) now includes support for iOS 17, ensuring compatibility with the latest iOS features and improvements.
- It also incorporates privacy manifest files, which are essential for merchants to successfully publish their apps to the App Store.
- This update will help you avoid potential disruptions and ensure a smooth app publishing process.
Android SDK Updates include:
- The new Android SDK (v4.3.3) includes support for Android targetSdk 38, ensuring your app remains compatible with the latest Android platform updates and enhancements.
- This update will help you avoid potential disruptions and ensure a smooth app publishing process.
React Native SDK Updates include:
- The React Native SDKs (v4.3.2) have been updated to incorporate the latest changes in the underlying iOS and Android SDKs to ensure that apps using this SDK are able to comply with the latest changes introduced in the iOS and Android SDKs.
How to update your Mobile SDK. Please update your Mobile SDK to the latest versions listed below.
We appreciate that this is an urgent request. If you have any questions or need any assistance, our support team is ready to help.
You can reach us at [email protected].
21st May
Important: Only 2 weeks until the deprecation of One-Use Tokens and reminder to transition to Payment Session Authentication.
IMPORTANT Please action the below by 6th June or your transactions will fail.
With only 2 weeks to go, we want to remind you of this important tech update:
As part of our ongoing commitment to security and compliance, as of 6th June 2024, we will no longer be supporting the use of one-use tokens to authenticate requests sent to Judopay's APIs and SDKs. As a result, you must transition to Payment Session Authentication (more details below).
Why are we deprecating one-use tokens? Since the Strong Customer Authentication (SCA) mandate, we’ve been actively encouraging merchants to move away from one-use tokens. One-use tokens are not considered to be fully SCA compliant, and we’re taking proactive measures to ensure the highest level of security for your transactions.
What does this mean for you? From 6th June 2024, any authentication requests using one-use tokens will not be processed. To ensure the continued security of your transactions, you can no longer use this method of authentication.
It’s vital you transition to using payment session authentication for your transactions. If you don't transition by 6th June, your transactions will fail. Payment session authentication not only provides a more robust security framework but also ensures compliance with SCA standards.
To guide you through the implementation of payment session authentication, you can find step-by-step instructions and best practices in our documentation here.
Next Steps:
- Familiarise yourself with the documentation linked above.
- Update your authentication processes to incorporate payment session authentication.
- Ensure that your team is aware of these changes and has the necessary resources to make a smooth transition.
We understand that changes like these can be challenging, and we are here to support you throughout this process. If you have any questions or concerns, please do not hesitate to reach out to our support team at [email protected]
Thank you for your cooperation and understanding as we work together to maintain the highest standards of security and compliance.
8th May
Deprecation of One-Use Tokens and reminder to transition to Payment Session Authentication.
IMPORTANT Please action the below by 6th June or your transactions will fail.
With less than 1 month to go, we want to remind you of this important tech update:
As part of our ongoing commitment to security and compliance, as of 6th June 2024, we will no longer be supporting the use of one-use tokens to authenticate requests sent to Judopay's APIs and SDKs. As a result, you must transition to Payment Session Authentication (more details below).
Why are we deprecating one-use tokens? Since the Strong Customer Authentication (SCA) mandate, we’ve been actively encouraging merchants to move away from one-use tokens. One-use tokens are not considered to be fully SCA compliant, and we’re taking proactive measures to ensure the highest level of security for your transactions.
What does this mean for you? From 6th June 2024, any authentication requests using one-use tokens will not be processed. To ensure the continued security of your transactions, you can no longer use this method of authentication.
It’s vital you transition to using payment session authentication for your transactions. If you don't transition by 6th June, your transactions will fail. Payment session authentication not only provides a more robust security framework but also ensures compliance with SCA standards.
To guide you through the implementation of payment session authentication, you can find step-by-step instructions and best practices in our documentation here.
Next Steps:
- Familiarise yourself with the documentation linked above.
- Update your authentication processes to incorporate payment session authentication.
- Ensure that your team is aware of these changes and has the necessary resources to make a smooth transition.
We understand that changes like these can be challenging, and we are here to support you throughout this process. If you have any questions or concerns, please do not hesitate to reach out to our support team at [email protected]
Thank you for your cooperation and understanding as we work together to maintain the highest standards of security and compliance.
6th March
Deprecation of One-Use Tokens and reminder to transition to Payment Session Authentication.
Important update regarding authentication methods used to interact with Judopay products.
As part of our ongoing commitment to security and compliance, as of 6th June 2024, we will no longer be supporting the use of one-use tokens to authenticate requests sent to Judopay's APIs and SDKs.
As a result, you must transition to Payment Session Authentication (more details below).
We’re reaching out to you as you are among the few merchants who have not yet made this shift.
Why are we deprecating one-use tokens? Since the Strong Customer Authentication (SCA) mandate, we’ve been actively encouraging merchants to move away from one-use tokens. One use-tokens are not considered to be fully SCA compliant, and we’re taking proactive measures to ensure the highest level of security for your transactions.
What does this mean for you? From 6th June 2024, any authentication requests using one-use tokens will not be processed. To ensure the continued security of your transactions, you can no longer use this method of authentication.
Payment Session Authentication: A more secure alternative. It’s vital you transition to using payment session authentication for your transactions. Payment session authentication not only provides a more robust security framework but also ensures compliance with SCA standards.
To guide you through the implementation of payment session authentication, you can find step-by-step instructions and best practices in our documentation here.
Next Steps:
- Familiarise yourself with the documentation linked above.
- Update your authentication processes to incorporate payment session authentication.
- Ensure that your team is aware of these changes and has the necessary resources to make a smooth transition.
4th October
Upgrade required for JudoKit SDKs to continue processing AMEX.
Important Amex upgrade required by 13th October.
To continue processing American Express (Amex) transactions on your mobile apps, an urgent upgrade is required, to the latest versions of our JudoKit SDKs for Android, iOS, and React Native.
From the 13th October 2023, AMEX requires all JudoKit Mobile SDKs to use the latest AMEX encryption certificates.
To ensure uninterrupted processing of AMEX transactions and to remain compliant with their requirements, we’ve released an updated version of the JudoKit Mobile SDKs which incorporate the latest AMEX encryption certificate.
Why do you need to upgrade?
Security: The new SDK versions incorporate the latest AMEX encryption certificate and adhere to the latest standards to protect your transactions and customer data.
Continuity: Upgrading is essential to continue processing AMEX cards via your mobile apps which use the JudoKit Mobile SDKs.
Failure to upgrade will likely result in being unable to process AMEX transactions. We understand the urgency of this upgrade and are here to assist you every step of the way. Our support team is available to answer any questions and provide guidance as needed.
Deadlines.
- Upgrade deadline: To ensure uninterrupted AMEX transaction processing, please complete the upgrade by 13th October 2023.
- AMEX changes: AMEX's security enhancements and protocol updates will be effective starting 13th October 2023.
Action required.
To upgrade to the latest versions of JudoKit SDKs, please follow these links.
Please note - The latest SDK was made available on 3rd October. If you've recently upgraded before 3rd October, please follow the "Action Required" steps to upgrade to the latest version, or your app won't be compliant.
21st September
Upgrade Required for Judokit Android and Judokit React Native.
Update required for Judokit Android and Judokit React Native libraries before your next app update.
If you’re not the tech contact at your company, please forward this email on to the relevant person / team.
Recently, we’ve identified an external dependency issue that requires attention - before your next app update.
To ensure the continued smooth operation of your payment processing, we’re asking all Judopay merchants to upgrade to the latest versions of Judokit Android and Judokit React Native as soon as possible. Why you need to upgrade. One of our partners has transitioned their library from JFrog Artifactory to Maven Central. From the 22nd of September, this third-party library hosted on JFrog will no longer be available. This means that you will no longer be able to build your apps without upgrading to the latest versions of the JudoKit Android (v4.1.2) and Judokit React Native (v4.1.2) SDKs.
This is especially critical for merchants who are actively developing apps or with plans to release an app update. You will be unable to build your apps during development without actioning the below.
This does not affect any applications that have already been deployed by you.
By upgrading to the latest versions of Judokit Android (v4.1.2) and Judokit React Native (v4.1.2), your IDE will download dependencies from the correct repositories, and you can continue your app build without any issues.
Action required. Upgrade your integration to the latest versions of Judokit Android and Judokit React Native, using the links below, as soon as possible to avoid any issues.
23rd June
Mastercard data points for MIT/Recurring Transactions.
From 30th July, Mastercard will begin checking for additional data in Merchant Initiated Transactions (MIT) / Recurring transactions, to further minimise fraud. This means that we need you to start sending us an additional data point - ReceiptIDs - to ensure that your payments aren’t impacted.
If you do not complete the below update by 30th July, the success rate of your transactions may be impacted and you could risk being issued a fine by Mastercard.
What is a ‘Related ReceiptID’ and how is it used? When a customer signs up to a recurring payment, a ReceiptID is generated. This ‘relatedReceiptID’ is what then needs to be referenced in the future merchant initiated transactions for that customer, giving assurance to Mastercard that the customer has agreed for these recurring transactions to be made.
What do you need to do? You need to make sure that you have a ReceiptID for all customers using MIT/Recurring payments and that you’re sending us the ‘relatedReceiptID’ in your relevant transactions.
If you don’t have a record of ReceiptIDs… We encourage you to ask your customers to re-register their cards with you so that you can generate and capture a ReceiptID for that customer.
To start sending us ReceiptIDs… You need to start referencing the original transactions ReceiptID when sending us MIT/Recurring transactions.
For details on ReceiptIDs, referencing ReceiptIDs and for example Transaction API references, visit Documentation
13th October
Action required regarding 3D Secure 2.0 upgrade.
From 14th October 2022, 3D Secure v.1.0 will no longer be supported by Visa, American Express, Mastercard and others.
To assess your 3DS2 readiness please check the guidance below in relation to how you manage your payments with Judopay: See guidance