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.
2026
September 2026
Mastercard Network Token Mandate 1 October 2026.
If you have any questions, drop us an email at [email protected].
A final reminder that from 1st October 2026, Mastercard expects all businesses processing card-on-file transactions to use Network Tokens. For more on Network Tokens, please visit our Support Centre. What do you need to do? You don’t need to do anything. Unless you have opted out, we’re automatically enabling Network Tokens on your account. This keeps your current card-on-file transactions compliant or ensures you’re covered if you choose to process them in the future. A new fee applies to Network Token transactions. Please review recent pricing updates for more details. Using Judopay's DPG API Bridge integration? You are required to migrate and will have already received separate instructions. Please reach out to a member of the team today if you have not already agreed a migration plan.
August 2026
Network Tokens & Update to our Transaction API. If you have any questions, drop us an email at [email protected].
—-------------------------
To avoid any issues with your payment processing we always recommend using the latest version of our SDKs & API.
—-------------------------
1 October 2026: Network Tokens Mandate.
From 1 October 2026, Mastercard is mandating that all businesses using card-on-file transactions start using Network Tokens. This change is part of their ongoing work to improve authorisation rates and minimise fraud. For more info, on Network Tokens visit our Support Centre.
No integration changes are required to stay compliant (unless you are using our DPG API Bridge). We’re automatically enabling Network Tokens on your account ahead of the 1 October deadline.
While the mandate comes into force from 1 October, you may notice some Network Token fees in September as we begin testing across all accounts. This ensures your integration fully supports Network Tokens ahead of the 1 October compliance deadline, helping you avoid any non-compliance fees.
If you do not currently use card-on-file transactions AND do not want to be auto-enabled, you can email [email protected] by 1 September to opt out. Please note this automatic enablement is to ensure you remain compliant: if you start using card-on-file transactions in the future and Network Tokens are not enabled, you could be fined by the card schemes.
—-------------------------
Update to Transaction API v 6.26
We have released a new version of our Transaction API. We always recommend using the latest version of API to avoid any issues with your payment processing. See details of the changes below or on our Docs here.
API Version 6.26 released
The addition of yourPaymentMetaData attribute on the following request:
- POST /transactions/checkcard
- This is an optional attribute added to the /checkcard request body, to provide additional information associated with that transaction.
- The receipt response will then display the metadata that was supplied in the request.
- Using the yourPaymentMetaData attribute means the additional information supplied, can help with reconciling transactions.
July 2026
Network Tokens Mandate & 3DS2 Fields. If you have any questions, drop us an email at [email protected].
—-------------------------
To avoid any issues with your payment processing we always recommend using the latest version of our SDKs & API.
—-------------------------
1 October 2026: Network Tokens Mandate. From 1 October 2026, Mastercard is mandating that all businesses using card-on-file transactions start using Network Tokens. This change is part of their ongoing work to improve authorisation rates and minimise fraud. For more info, on Network Tokens visit our Support Centre.
No integration changes are required to stay compliant (unless you are using our DPG API Bridge). We’re automatically enabling Network Tokens on your account ahead of the 1 October deadline.
If you do not currently use card-on-file transactions AND do not want to be auto-enabled, you can email [email protected] by 1 September to opt out. Please note this automatic enablement is to ensure you remain compliant: if you start using card-on-file transactions in the future and Network Tokens are not enabled, you could be fined by the card schemes.
—-------------------------
Best Practices for 3DS2 Fields.
Mastercard recommends that merchants send the field data below to reduce friction, minimise challenges at the checkout, and send stronger approval signals to Issuers.
Please note, if you do not make the below changes, your payments will continue to work.
Mastercard recommends:
- Always including: Cardholder name AND Billing address line 1.
- Including at least 1 contact method e.g. email address, home phone, mobile number, work number.
- Including at least one device identifier e.g. IP address (browser or device), Device ID.
June 2026
Mobile SDK Update, Network Tokens & 3DS2 Fields.
—-------------------------
Please review the important updates and deadlines below. If you have any questions, drop us an email at [email protected].
To avoid any issues with your payment processing we always recommend using the latest version of our SDKs & API.
—-------------------------
1 July 2026 Mobile SDK - Update Required for Latest Mastercard Encryption Certificate Please note - if you're integrated to Judopay via a technology provider, we have reached out to your provider directly. If you process payments using our Mobile SDK, you must update to the latest version by 1st July 2026. Mastercard has issued a new encryption certificate - without it, your Mastercard transactions will fail. Please ensure you’ve upgraded to the version of JudoKit Mobile SDK mentioned below (or later) before 1st July 2026.
- Update iOS SDK to 6.4.0, details here.
- Update Android SDK to 6.2.0, details here.
- Update React Native SDK to 6.4.0, details here.
—-------------------------
Recommended 3DS2 updates from Mastercard From 1 July 2026, Mastercard are recommending that merchants start sending the below field data in order to reduce friction, minimise challenges at the checkout from 3DS2 and send stronger approval signals to Issuers. Please note, if you do not make the below changes your payments will still continue to work. Mastercard now recommends:
- Always including: Cardholder name AND Billing address line 1.
- Including at least 1 contact method e.g. email address, home phone, mobile number, work number.
- Including at least one device identifier e.g. IP address (browser or device), Device ID.
—-------------------------
1 October 2026 Mastercard's Network Tokens Mandate From 1 October 2026, Mastercard is mandating that all businesses using card-on-file transactions start using Network Tokens. This change is part of their ongoing work to improve authorisation rates and minimise fraud. We have separately emailed out the necessary information for your account. If you have not received an email from us please contact us at [email protected].
Mastercard Network Token Mandate. 1 October 2026.
—-------------------------
As part of their ongoing plans to improve authorisation rates and minimise fraud, on 1st October 2026, Mastercard is mandating all businesses using card-on-file transactions to begin using Network Tokens.
What are Network Tokens? Network Tokenisation is the next evolution in card-on-file technology. By replacing sensitive card data with anonymised tokens, it reduces compliance burden and lowers fraud risk.
This also has a positive impact on approval rates and user experience - with Network Tokens meaning card details can automatically be updated whenever a customer’s card is replaced or expired.
What you need to do No integration changes are required to stay compliant - we’re enabling Network Tokens on your account ahead of the deadline. Please note the use of Network Tokens incurs a fee - details will be shared with your Finance contact later this month.
However, we do offer additional reporting that allows you to see which transactions have been processed using Network Tokens. To access this feature, you will need to be on our latest integration.
If you need any support or have any questions, drop us an email at [email protected].
Tech Bulletin: June 2026 Update to the Latest Version of our Mobile SDKs.
—------------------------- 1 July 2026 Mobile SDK - Update Required for Latest Mastercard Encryption Certificate Please note - if you're integrated to Judopay via a technology provider, we have reached out to your provider directly. If you process payments using our Mobile SDK, you must update to the latest version by 1st July 2026. Mastercard has issued a new encryption certificate - without it, your Mastercard transactions will fail.
Please ensure you’ve upgraded to the version of JudoKit Mobile SDK mentioned below (or higher) before 1st July 2026.
- Update iOS SDK to 6.4.0, details here.
- Update Android SDK to 6.2.0, details here.
- Update React Native SDK to 6.4.0, details here.
May 2026
ACTION REQUIRED: Important Update on Account Funding Transactions (AFTs).
—-------------------------
What is an Account Funding Transaction (AFT)? An AFT is a transaction where funds are drawn from a cardholder's account to fund a separate account (rather than to purchase goods or services directly). For example, topping up a digital wallet, a money transfer, loading a prepaid card, or buying cryptocurrency.
Who may be affected? To check if your business is impacted, we recommend speaking directly with your acquirer. The changes will apply to certain business types, identified by the below Merchant Category Codes (MCCs). If your business falls into one of these categories and you fail to update to the latest integration, your transactions may be declined.
Merchant Category Code | Description |
|---|---|
4829 | Money Transfer |
6012 | Financial Institutions – Money Orders / Foreign Currency |
6051 | Financial Institutions – Merchandise / Services / Debt Repayment |
6211 | Securities Brokers / Dealers |
6540 | Stored Value Card Purchase |
What do you need to do? Before making any changes, contact your acquirer. They can confirm:
- Whether this applies to your account
- Whether they need to start sending the new AFT fields
- Any deadlines you need to meet
If your acquirer confirms that you’re affected you’ll need to make an update to include the new AFT details - what you need to do will depend on your integration type.
- API: Update to API version 6.25. We’ve introduced new AFT fields on:
- POST /transactions/payments
- POST /transactions/preauths
- POST /paymentsession endpoints. Details here.
- SDKs: While you do not need to update the SDK version, you need to provide additional AFT information in the payment session. Details here.
- Pay by Link: You’ll see a new “AFT Recipient Information” section when you create a link. Details here.
- Virtual Terminal: You’ll see a new “AFT Recipient Information” section when you take a payment. Details here.
—-------------------------
Key Links & Info.
- Full details of the API 6.25 changes
If you have any questions or need any additional support, please contact us at [email protected].
April 2026
SDK Update and Upcoming Mandate for Network Tokens.
—-------------------------
Please review the important tech updates and deadlines below. If you have any queries, drop us an email at [email protected].
—-------------------------
1st July 2026: Mobile SDK - Update Required for Latest Mastercard Encryption Certificate.
Please note - if you're integrated to Judopay via a technology provider, we have reached out to your provider directly.
If you process payments using our Mobile SDK, you must update to the latest version by 1st July 2026.
Mastercard has issued a new encryption certificate - without it, your Mastercard transactions will fail. Please ensure you’ve upgraded to the version of JudoKit Mobile SDK mentioned below (or higher) before 1st July 2026.
- Update iOS SDK to 6.4.0, details here.
- Update Android SDK to 6.2.0, details here.
- Update React Native SDK to 6.4.0, details here.
If you need any support with the update, please contact us at [email protected].
—-------------------------
1st October 2026: Mastercard are Mandating Network Tokenisation.
Mastercard is requiring merchants to enable Network Tokens - here’s what you need to know.
What are Network Tokens? Network Tokens replace a customer’s card number with a secure, unique digital identifier issued by the card network. This token is specific to your business, meaning it can’t be used elsewhere if data is ever compromised - typically resulting in higher authorisation rates and better fraud protection. More info here.
What’s the deadline? Mastercard has set a deadline of 1 October 2026 for this mandate to take effect.
What do you need to do? We’re working closely with Mastercard to understand the full scope of the mandate and what it means for businesses. We’ll be in touch with clear guidance and next steps as soon as we have them - no action is needed right now.
Questions? Drop us an email at [email protected].
2025
September 2025
Important: If you process Amex payments via our Mobile SDK, you must update to the latest version by November 15, 2025.
Transactions may not be processed if not updated.
What is the Update? Amex has issued a mandatory encryption certificate. This certificate adds a layer of security to all of your Amex transactions - without it, your Amex transactions will fail. Please ensure that you’ve upgraded to the version of our JudoKit Mobile SDK mentioned below (or higher) before 15th November 2025.
What you need to do. Based on your integration, please ensure you’ve upgraded to the versions below or higher before 15th November.
- Update iOS SDK to V5.0.3 or higher, details here.
- Update Android SDK to V5.0.3or higher, details here.
- Update React Native SDK to V5.0.2 or higher, details here.
Already using these versions? No action needed.
The latest certificate issued by Amex will be valid until 28 June 2027.
Please note: When upgrading from an older version, check the changes in previous releases to ensure you’re fully aware of all changes.
If you have any questions or need any support with your upgrade, please reach out to the team at [email protected].
July 2025
An important update is needed to your React Native SDK. Why do you need to update? Due to a Transport Layer Security cipher suites update we've noticed a recent increase in decline rates linked to certain banks (such as Allied Irish Banks, Bank of Ireland, Tesco Bank, Capital One, Clydesdale Bank, HSBC, NatWest, Nationwide, Santander, The Co-Operative, The Royal Bank of Scotland and TSB). This specifically impacts 3DS challenge flows. To address this, we’ve developed and released a new version of our React Native SDK.
Alternative Solution. If you experience any issues before updating your React Native SDK, we recommend that consumers use Google Pay™ instead of card payments for successful payments.
What you need to do. Based on your integration:
- Update your React Native SDK to V4.4.0
Important update needed to your Android SDK.
Why do you need to update? Due to a Transport Layer Security cipher suites update, we’ve noticed a recent increase in decline rates linked to certain banks (such as Allied Irish Banks, Bank of Ireland, Tesco Bank, Capital One (Europe), Clydesdale Bank, HSBC, NatWest, Nationwide, Santander, The CO-Operative, The Royal Bank of Scotland and TSB). This specifically impacts 3DS challenge flows. To address this, we've developed and released a new version of our Android SDK. Please note - our iOS SDK is not affected.
Alternative solution. If you experience any issues before updating your Android SDK, we recommend consumers use Google Pay™ instead of card payments for successful payments.
What you need to do. Based on your integration:
- Update your Android SDK to V5.0.1 Please be aware that this version of the Judokit Android targets Android API version 35.
January 2025
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, from 31st January. 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 enabling this for all merchants from 31st January 2025 (unless someone at your business requests early access to 2FA for your account).
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]
2024
July 2024
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:
- Judokit iOS
- Web SDK
- Web Payments
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:
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:
- Judokit iOS
- Web SDK
- Web Payments
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:
June 2024
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:
- Judokit iOS
- Web SDK
- Web Payments
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:
May 2024
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.
- iOS SDK version 3.4.1 here.
- Android SDK version 4.3.3 here.
- React Native version 4.3.2 here.
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].
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.
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.
March 2024
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.
2023
October 2023
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.
- Android: Version 4.1.3
- iOS: Version 3.2.5
- React Native: Version 4.1.3
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.
September 2023
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.
June 2023
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
2022
October 2022
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