On This Page
Release Notes
These release notes cover all releases to the production server for the week ending
May 22, 2026
.Announcements
These announcements are for
May 22, 2026
.TLS Updates
We are making changes to our implementation of Transport Layer Security (TLS).
TLS 1.3
To maintain the highest security standards for both browser-based and server-to-server
connections, we will enable TLS 1.3 on the endpoints listed below. This enhancement is
optional and will supplement the existing TLS 1.2 support, which will remain in place.
We will make changes to these endpoints on these dates:
Testing environment
: May 26, 2026ics2wstesta.ic3.com
ics2wstest.ic3.com
apitest.cybersource.com
Production environment
: June 2, 2026ics2wsa.ic3.com
ics2ws.ic3.com
api.cybersource.com
api.in.cybersource.com
ics2ws.in.ic3.com
Contact Customer Support if you have any questions about these changes.
TLS Certificate Lifetime Reduction
In alignment with new CA/Browser Forum regulations, the maximum TLS certificate lifetime
will be reduced gradually as follows:
• Currently, the maximum lifetime for a TLS certificate is 200 days.
• Beginning March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.
• Beginning March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.
See this blog for more information about the TLS certificate lifetime changes:
How will this change impact connectivity?
Server-level (leaf) SSL/TLS certificates will remain valid until their scheduled expiration.
Server-level (leaf) TLS certificates have shorter lifespans and must be reissued more
frequently. We therefore recommend that clients trust the root certificate instead.
What is our recommendation?
We continue to recommend trusting the Root TLS certificates for all secure
endpoints. This approach removes the need for periodic renewal of server level certificates
and helps prevent connection failures caused by expired leaf certificates.
How can I tell which TLS certificate I am using?
Contact your server administrator or your network support team.
Where can I find the TLS Root certificate?
Continue trusting the root certificate to maintain connectivity with supported endpoints. You
can download the root certificate from this article:
Contact your Customer Support representatives with any questions.
Webhooks Updates
Webhooks version 1 will be decommissioned by end of the year 2026. See Webhooks version 2 in the Developer
Center.
Enhanced Webhook URL Review and Approval Process
We are introducing an enhancement to webhook subscription processing to improve security,
compliance, and visibility for webhook-related URLs. Webhook URLs will be validated and
reviewed before they can be used. This includes both newly submitted subscriptions and
existing subscriptions currently on file. This change is expected to take place at the end of
May 2026.
What is Changing
What is Changing
When a webhook subscription is created or updated, the URLs associated with that
subscription will be evaluated through a validation and approval process.
This applies to:
- Webhook URL(required)
- OAuth URL(if applicable)
- Health Check URL(if applicable)
As part of this enhancement, clients might now see the following user-facing statuses:
- PENDING_REVIEW
- BLOCKED
The existing
INACTIVE
status remains unchanged and continues to indicate that the
subscription is approved and ready within the current lifecycle.Status Descriptions
Status | Description |
|---|---|
PENDING_REVIEW | One or more submitted URLs are being validated or awaiting required security
approval. |
BLOCKED | One or more URLs were rejected or identified as unsafe or non-compliant. The
subscription cannot proceed until the URL(s) are updated. |
INACTIVE | All required approvals are complete, and the subscription is ready under the
existing activation flow. |
How the New Process Works
How the New Process Works
- A webhook subscription is created or updated.
- Submitted URLs are checked against existing approval records.
- New or unknown URLs are evaluated through automated validation.
- If additional review is required, the subscription status changes toPENDING_REVIEW.
- If any URL is rejected or blocked, the subscription status changes toBLOCKED.
- If all required URLs are approved, the subscription status changes toINACTIVE.
Impact on Existing Subscriptions
Impact on Existing Subscriptions
After this change goes live, we will run existing webhook subscriptions through the new
validation process:
- Existing subscription URLs will be assessed using the new validation framework.
- URLs that require additional security review might change the status of the subscription toPENDING_REVIEW.
- If any existing URL is identified as blocked, the associated subscription status will be updated toBLOCKED.
In cases where a subscription status is change to
BLOCKED
, clients will be expected to
perform these tasks:- Review the affected endpoint(s).
- Update the URL(s) to an acceptable endpoint.
- Resubmit the subscription for processing.
For New Subscriptions
For New Subscriptions
New webhook-related URLs may go through validation and, if necessary, security review before
the subscription can proceed.
For Existing Subscriptions
For Existing Subscriptions
Current subscriptions will also be reviewed after they go live. If an existing endpoint does
not meet the new validation requirements, the subscription status might be updated to
BLOCKED
until the URL is corrected.If Your Subscription Is Marked BLOCKED
If Your Subscription Is Marked BLOCKED
This means one or more URLs associated with the subscription cannot be used in their
current form. To continue, the client must update the affected URL(s) and resubmit.
Why We Are Making this Change
Why We Are Making this Change
This enhancement is designed to:
- Reduce security riskby preventing outbound calls to unapproved endpoints.
- Improve compliancethrough stronger review and approval controls.
- Increase transparencywith clearer client-visible statuses.
- Support scalethrough a standardized and repeatable validation process.
Message-Level Encryption Upcoming Mandate
An updated version of message-level encryption (MLE) will become mandatory in order for
merchants to use the APIs. Portfolio owners must enable this updated version of MLE for their
merchants by
September 2026
.This required MLE update encrypts all data in your API response messages. The previous
version of MLE encrypted only request messages. If your merchants are already using custom
JSON Web Token messaging, they must also update how their system constructs JWTs. Merchants
who are using HTTP signature messaging must migrate their system to JWT messaging.
You risk transaction failures if you do not implement this MLE update.
Overview of MLE
MLE is a robust security protocol designed to encrypt individual messages or payloads
at the application layer. By protecting sensitive data at the message level, MLE ensures
that your information remains secure as it moves through systems and networks, providing a
layer of security beyond traditional transport encryption.
Enabling MLE requires you to create a REST API key for request messages and a
REST
– API Response MLE
key for response messages. If your organization is using
a meta key, the portfolio account or merchant account user who created the meta key
must also create the REST – API Response MLE key.- Update Methods
- Create or update your custom MLE integration using JWTs with P12 certificates. For more information, see the Enable Message-Level Encryption section in theGetting Started with REST Developer Guide. For a method using shared secret key pairs, see the HTTP Messaging Migration to JWT Messaging section below.
- Update your REST API SDK. For more information, see theREST API related productssection in the Cybersource GitHub.
JSON Web Token Construction Update
There are new requirements for how to construct JSON Web Tokens (JWTs) in order to
send API request messages. If you use a custom integration to construct JWTs, you must
update your system to remain compliant. This update is necessary to support the new MLE requirements.
- Update Methods
- See Construct JWT Messages Using aP12 Certificatein theGetting Started with REST Developer Guide
- See Construct JWT Messages Using aShared Secret Key Pairin theGetting Started with REST Developer Guide
HTTP Messaging Migration to JWT Messaging
By
September 2026
, all merchants using HTTP signature messaging must migrate
to JWT messaging in order to support MLE. Merchants already using HTTP signature
messaging with shared secret key pairs can now continue using their existing keys
with JWT messaging. - Update Method
- See Construct JWT Messages Using aShared Secret Key Pairin theGetting Started with REST Developer Guide
Smart Auth Retirement
Smart Auth, also known as SuperAuth, is being discontinued. This product was often included in
the Essentials package of products for small merchants.
Support for Smart Auth is being discontinued in phases. The final end of life occurs October 5,
2026.
Merchants currently using Smart Auth will receive a 90-day product sunset
notification.
Merchants interested in a similar product can use Fraud Management Essentials (FME). FME is an actively supported service that offers improved fraud protection capabilities and system reliability.
Features Introduced This Week
Merchant Descriptior Name | RM-44633
Merchant Descriptior Name
| RM-44633- Description
- Cybersource is updating validation for themerchantInformation.merchantDescriptor.nameAPI field. Merchants can now submit merchant descriptor names that include either the asterisk (*) or hyphen (-) character. Transactions are no longer rejected solely because these characters are included in this descriptive field.
- Mandate
- Does not apply.
- Audience
- The updated validation is available to all merchants who use themerchantInformation.merchantDescriptor.namefield.
- Benefit
- Improved merchant descriptor support.
- Technical Details
- Example:{ "merchantInformation": { "merchantDescriptor": { "name": "MERCHANT*STORE-NAME" } } }
- Important Dates
- Released to Production May 20, 2026.
New Features for Pisma | RM-44633
New Features for Pisma
| RM-44633- Description
- Merchants who use Prisma can now use 3-D Secure 2.x, Network Tokens, and MIT/COF framework data. These capabilities are available to Prisma merchants who are enabled. This update allows Prisma merchants to support tokenized and authenticated card-not-present payment flows and submit the required transaction framework data for eligible use cases.
- Mandate
- Does not apply.
- Audience
- Merchants processing in Argentina through the Prisma connection.
- Benefit
- Prisma merchants can support tokenized, authenticated, and credential-on-file card-not-present payment flows.
- Technical Details
- Supported 3-D Secure-related values include:
- pa_specification_version
- directory_server_transaction_id
- cavv
- ucaf_collection_indicator
- ucaf_authentication_data
Supported MIT/COF-related values include:- subsequent_auth_first
- subsequent_auth_reason
- subsequent_auth
- subsequent_auth_transaction_id
Supported Network Token-related value:- network_token_cryptogram
- Important Dates
- Released to Production May 20, 2026.
Fixed Issues
No customer-facing fixes were released this week.
Known Issues
Transaction Search in the Business Center | EPS-37818
Transaction Search in the Business Center
| EPS-37818- Description
- For a similar search in the Business Center that has over 20 results (1 page), clicking the next page only shows 1 new result. Instead of returning results 21-40, results 2-21 are returned. When the user clicks page 3, results 3-22 are returned.
- Audience
- Global.
- Technical Details
- None.
- Workaround
- None.
Recurring Billing | EPS-37751
Recurring Billing
| EPS-37751- Description
- This issue affects subscriptions that fulfill these criteria:
- A recurring payment fails or is skipped for the month of February.
- The date of payment falls on the 29th - 31st of the month.
- The payment is subsequently retried successfully.
For these subscriptions, the billing cycle is incorrectly recalculated such that the date of payment falls on the 28th of the month instead of the original date (29, 30 or 31). - Audience
- Merchants who use Recurring Billing.
- Technical Details
- None.
- Workaround
- None.
Portfolio Management | EPS-37583
Portfolio Management
| EPS-37583- Description
- When a transacting organization is set to Inactive, it is still shown as a selectable option from its parent merchant organization.
- Audience
- Users of portfolio accounts.
- Technical Details
- None.
- Workaround
- None.
Virtual Terminal | EPS-37322
Virtual Terminal
| EPS-37322- Description
- The postal code cannot be set as Required for any country except the US and Canada.
- Audience
- Global.
- Technical Details
- None.
- Workaround
- Set the postal code manually.
SDK | EPS-37838
SDK
| EPS-37838- Description
- When a merchant uses the Cybersource .NET SDK (NuGet CyberSource.Rest.Client v0.0.1.62) to perform a GET request, the SDK incorrectly adds a digest header and includes the digest in the HTTP Signature's signed-headers list. Per the HTTP Message Signatures specification, Digest should only be signed for requests that have a body, for example, POST or PUT. Merchants might receive validation failures for signed requests.
- Audience
- Merchants using the SDK.
- Technical Details
- None.
- Workaround
- None.