Comms Log

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 2025 january 2025 30th january 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 help\@judopay com 2024 july 2024 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 help\@judopay com 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 ios docid 09p1cru0cbxjkzea 0zpi android docid\ it3yrnihegsketqtsxgi3 react native docid\ ur8qjj7tjdxyhf4e5aojp web sdk docid 40dwe6lbub7vdkza1qydc web payments docid\ glorwwwfkfqp34fykcxe8 judopay transaction api https //docs judopay com/api/index html 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 old response snippet example new response example new response snippet 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 ios docid 09p1cru0cbxjkzea 0zpi android docid\ it3yrnihegsketqtsxgi3 react native docid\ ur8qjj7tjdxyhf4e5aojp web sdk docid 40dwe6lbub7vdkza1qydc web payments docid\ glorwwwfkfqp34fykcxe8 judopay transaction api https //docs judopay com/api/index html 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 old response snippet example new response example new response snippet example june 2024 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 ios docid 09p1cru0cbxjkzea 0zpi android docid\ it3yrnihegsketqtsxgi3 react native docid\ ur8qjj7tjdxyhf4e5aojp web sdk docid 40dwe6lbub7vdkza1qydc web payments docid\ glorwwwfkfqp34fykcxe8 judopay transaction api https //docs judopay com/api/index html 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 old response snippet example new response example new response snippet example may 2024 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 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 developersupport\@judopay com 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 authentication methods docid\ ylkw5coh5nqnfq3j wjk2 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 developersupport\@judopayments com 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 authentication methods docid\ ylkw5coh5nqnfq3j wjk2 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 developersupport\@judopayments com thank you for your cooperation and understanding as we work together to maintain the highest standards of security and compliance march 2024 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 authentication methods docid\ ylkw5coh5nqnfq3j wjk2 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 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 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 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 judokit android judokit reactnative june 2023 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 merchant initiated transactions docid\ ek1dldo8cgr9di226zlyf 2022 october 2022 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