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. This transition will be done in two phases.
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.
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.
Do not revoke or remove any of your existing Entrust certificates linked with Cybersource endpoints before the scheduled dates. 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.
There will be two phases and each phase will update different endpoints.
First Phase
The first phase is now complete and the certifications are updated on the following endpoints:
Test URLs
Production URLs
apitest.cybersource.com
accountupdater.cybersource.com
accountupdatertest.cybersource.com
api.cybersource.com
batchtest.cybersource.com
batch.cybersource.com
api.accountupdatertest.cybersource.com
api.accountupdater.cybersource.com
ics2wstest.ic3.com
ics2ws.ic3.com
ics2wstesta.ic3.com
ics2wsa.ic3.com
apitest.cybersource.com
ics2ws.in.ic3.com
api.in.cybersource.com
batch.in.cybersource.com
We strongly urge you to test your implementation as soon as possible.
Second Phase
The second phase will update the following endpoints:
Test URLs
Production URLs
testflex.cybersource.com
flex.cybersource.com
testsecureacceptance.cybersource.com
secureacceptance.cybersource.com
flex.in.cybersource.com
secureacceptance.in.cybersource.com
The URLs above will have the new certs on these dates:
  • CAS/Test Environment: November 5, 2024, 4:00 GMT
  • Production Environment: December 10, 2024, 4:00 GMT
The old certs will expire on December 31, 2024.

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
    was 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 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.