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
Payer Authentication
| New Visa Secure MandateAs 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:
- TheVisa 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 asrequired conditionaland are now mandatory.
- TheVisa Secure Program Guidewas 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.