Comms log

Magnifying glass
Reset
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Date
Name
Topics
28.6.24
28.6.24

We have some upcoming platform updates that may require some technical updates to your integration. 

Note - these changes will affect customers who are using Judo 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 you in your inbound request). 
  • This field has been deprecated on older versions of the Judo API and will not be returned from Judo 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 will now be leveraging the unique device identifiers obtained 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 Judo API requests and responses.  

  • We’ve 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 Judo 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.
  • Now, we will only return the cardType in the response when it’s 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 is 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’re 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, Judokit Android, Judokit React Native, Web SDK, Webpayments, DotNET SDK, PHP SDK and Judopay Transaction API.

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).
  • Judo API: We recommend that you upgrade to using the latest Judo API version 6.21 if you’re integrated to us directly via the Judo 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.
Platform updates: these may require some technical updates to your integration.

We have some upcoming platform updates that may require some technical updates to your integration. 

Note - these changes will affect customers who are using Judo 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 you in your inbound request). 
  • This field has been deprecated on older versions of the Judo API and will not be returned from Judo 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 will now be leveraging the unique device identifiers obtained 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 Judo API requests and responses.  

  • We’ve 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 Judo 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.
  • Now, we will only return the cardType in the response when it’s 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 is 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’re 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, Judokit Android, Judokit React Native, Web SDK, Webpayments, DotNET SDK, PHP SDK and Judopay Transaction API.

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).
  • Judo API: We recommend that you upgrade to using the latest Judo API version 6.21 if you’re integrated to us directly via the Judo 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.
No tags found
28.5.24
28.5.24

An urgent update is needed for iOS, Android and React Native Mobile SDKs.

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.
Update needed to your Mobile SDK.

An urgent update is needed for iOS, Android and React Native Mobile SDKs.

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.
SDK
6.3.24
6.3.24

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.
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.
One-use Tokens
Authentication
4.10.23
4.10.23

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.

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.

SDK
AMEX
21.9.23
21.9.23

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.

JudoKit Android: https://github.com/Judopay/JudoKit-Android/releases/tag/v4.1.2

JudoKit ReactNative: https://github.com/Judopay/JudoKit-ReactNative/releases/tag/v4.1.2

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.

JudoKit Android: https://github.com/Judopay/JudoKit-Android/releases/tag/v4.1.2

JudoKit ReactNative: https://github.com/Judopay/JudoKit-ReactNative/releases/tag/v4.1.2

Android
React Native
23.6.23
23.6.23

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 example:

For details on ReceiptIDs, referencing ReceiptIDs and for example Transaction API references click the button below. Visit documentation.

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 example:

For details on ReceiptIDs, referencing ReceiptIDs and for example Transaction API references click the button below. Visit documentation.

Mastercard
MIT Transactions
13.10.22
13.10.22

I wrote to you recently advising you that from 14th October 2022, 3D Secure v.1.0 will no longer be supported by Visa, American Express, Mastercard and others. If you have not already done so, I strongly advise you to enable 3D Secure v2.0 as soon as possible to avoid your payments failing.

To assess your 3DS2 readiness please check the guidance below in relation to how you manage your payments with Judopay: See guidance.

Action required regarding 3D Secure 2.0 upgrade.

I wrote to you recently advising you that from 14th October 2022, 3D Secure v.1.0 will no longer be supported by Visa, American Express, Mastercard and others. If you have not already done so, I strongly advise you to enable 3D Secure v2.0 as soon as possible to avoid your payments failing.

To assess your 3DS2 readiness please check the guidance below in relation to how you manage your payments with Judopay: See guidance.

3D Secure