Passing six-digit BINs can result in no match being generated when there are multiple possible matches. We recommend that you update your systems to pass eight-digit BINs as soon as possible.

SSL/TLS Certification Migration

To uphold the maximum levels of security and compliance in both your browser-based and server-to-server interactions with the Visa Acceptance Solutions platform (including Cybersource), we are transitioning all Cybersource endpoint SSL/TLS certificates from Entrust to DigiCert. These SSL/TLS certificates, originally issued by Entrust, will now be issued by DigiCert to fortify these communication channels.
The new certificates can be found in the zip file at this link.
This update requires that all merchants who use Cybersource endpoint URLs to integrate the newly issued Root and Intermediate (CA) SSL/TSL certificates from DigiCert into their systems. This must be done in both the Test and Production environments prior to the scheduled revocation dates listed below.
Test environment:
 August 16, 2024
Production environment (shock test)*:
 September 17, 2024, from 16:00 GMT to 18:00 GMT
Production environment:
 October 29, 2024
* The shock test will migrate our Cybersource endpoints from Entrust to DigiCert SSL root and intermediate (CA) certificates for a short period during the day and then roll the change back. The purpose of the shock test is to provide the merchant the option to validate their connection and the chance to make adjustments to become compatible with our security update.
Merchants using Cybersource endpoints should coordinate with their network team or hosting/solution provider to implement all necessary measures to ensure their connections to Cybersource properties follow industry standards. This includes updating their systems with the new Root and Intermediate (CA) SSL/TLS certificates, which correspond to the specific Cybersource endpoint they use.
We strongly urge you to test your implementation in the Testing environment as soon as possible.
Testing in the Production environment will not be possible before September 17, 2024, release date. Therefore, it is imperative to ensure your system is prepared by conducting all necessary tests in the Testing environment.
Do not revoke or remove any of your existing Entrust certificates linked with Cybersource endpoints before the scheduled dates mentioned above. Until the cut-off dates, the only supported certificates will be the Entrust SSL certificates. You may add the new certificates to your system, in addition to the existing certificates, and verify their functionality in the testing environment.
If your application requires trusting of certificates at the server level, you must install (trust) the new certificates prior to expiration of existing certificates to avoid any production impact. The link to the Server-Level (leaf) SSL certificate will be updated when they become available.
We recommended that merchants trust only the Root and Intermediate CA SSL/TLS certificates on all secure endpoints. This method avoids the annual necessity to renew the server-level certificate.
Cybersource URLs that require immediate attention:
Test URLs
accountupdatertest.cybersource.com
apitest.cybersource.com
batchtest.cybersource.com
api.accountupdatertest.cybersource.com
ics2wstest.ic3.com
ics2wstesta.ic3.com
Production URLs
accountupdater.cybersource.com
api.cybersource.com
batch.cybersource.com
api.accountupdater.cybersource.com
ics2ws.ic3.com
ics2wsa.ic3.com
ics2ws.in.ic3.com
api.in.cybersource.com
batch.in.cybersource.com

JSON Web Token 120-Second Mandate

Merchants who secure their REST API transactions with JSON Web Tokens have 120 seconds after the issued-at time (IAT) to submit the transaction. Transactions sent after 120 seconds will fail.

REST HTTP Signature Best Practices Mandate

Merchants who secure their REST API transactions with an HTTP Signature must include all of the required elements. If the required elements are not present, the transactions will fail.

Payer Authentication
 | New Visa Secure Mandate

As of August 12, 2024, an update to the Visa Secure program requires additional data fields and affects users of the Payer Authentication REST and Simple Order APIs. The update is designed to enhance data quality monitoring and fraud dispute rights. There are no changes to API validation rules at this time. Failure to send these fields does not result in transaction failure; however, Visa Secure considers them missing data.
The newly required data fields apply only to standard Visa Secure EMV® 3-D Secure payment transactions. Non-payment transactions and 3-D Secure requestor-initiated transactions will not require these additional data fields as part of the mandate. Note that while some of the mandated Visa Secure data fields also apply to the Digital Authentication Framework (DAF), the DAF data requirements are managed separately.
Key Changes:
  • The
    Visa Secure Program Guide
    , which supplements the core Visa rules, requires users of Payer Authentication to include additional data fields in the authentication request message, also known as the enrollment request. These fields, which are already supported and recommended, were previously labeled as
    required conditional
     and are now mandatory.
  • The
    Visa Secure Program Guide
     is amended to assess only authorization data to determine fraud dispute rights, effective April 15, 2024.

Required Browser Fields

These fields are required for browser-based transactions. If you use Secure Acceptance Hosted Checkout, you do not need to send the browser fields. Hosted Checkout collects them automatically.
REST API Fields
  • deviceInformation.httpBrowserScreenHeight
  • deviceInformation.httpBrowserScreenWidth
Simple Order API Fields
  • billTo_httpBrowserScreenHeight
  • billTo_httpBrowserScreenWidth

Required In-App Field

This field applies only to transactions that are sent using the Software Development Kit (SDK). When you send this field using the SDK, Cardinal Commerce collects that information automatically.
REST API Fields
  • deviceInformation.ipAddress
Simple Order API Fields
  • billTo_ipAddress

Required Cardholder Fields

These fields are required except in countries for which they do not exist. An email address is required only when a phone number is not provided.
REST API Fields
  • orderInformation.billTo.email
  • orderInformation.billTo.firstName
  • orderInformation.billTo.lastName
Simple Order API Fields
  • billTo_email
  • billTo_firstName
  • billTo_lastName

Recommended Cardholder Fields

These fields are recommended except in countries for which they do not exist.
REST API Fields
  • orderInformation.billTo.address1
  • orderInformation.billTo.administrativeArea
  • orderInformation.billTo.country
  • orderInformation.billTo.locality
  • orderInformation.billTo.postalCode
Simple Order API Fields
  • billTo_country
  • billTo_city
  • billTo_postalCode
  • billTo_street1
  • billTo_state

Required Phone Fields

At least one of the following fields is required. A phone number is required only when an email address is not provided.
REST API Fields
  • orderInformation.billTo.phoneNumber
  • buyerInformation.mobilePhone
  • buyerInformation.workPhone
Simple Order API Fields
  • billTo_phoneNumber
  • payerAuthEnrollService_mobilePhone
  • payerAuthEnrollService_workPhone

Merchant Data Quality Best Practices

The following practices are recommended for best results.
  • Ensure that the checkout page is designed to collect the required and priority EMV 3-D Secure data elements and to take required actions to populate any missing data fields.
  • Ensure that data that is sent through EMV 3-D Secure is authentic and accurate at the time of the transaction.
  • Ensure that the 3-D Secure method URL is invoked and completed before you send an authentication request.

Payer Authentication Data Collection Implications

The required browser fields are collected by device data collection. Payer Authentication already requires the cardholder name, email address, and billing address. The common device identification parameters are handled by the Cardinal SDK.