On This Page

Release Notes

These release notes cover all releases to the production server for the week ending
June 5, 2026
.

Announcements

These announcements are for
June 5, 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:
Production environment
: June 9, 2026
ics2wsa.ic3.com
ics2ws.ic3.com
api.cybersource.com
The test versions of of these environments have already been updated.
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 in June 2026.

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

  1. A webhook subscription is created or updated.
  2. Submitted URLs are checked against existing approval records.
  3. New or unknown URLs are evaluated through automated validation.
  4. If additional review is required, the subscription status changes to
    PENDING_REVIEW
    .
  5. If any URL is rejected or blocked, the subscription status changes to
    BLOCKED
    .
  6. If all required URLs are approved, the subscription status changes to
    INACTIVE
    .

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 to
    PENDING_REVIEW
    .
  • If any existing URL is identified as blocked, the associated subscription status will be updated to
    BLOCKED
    .
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

New webhook-related URLs may go through validation and, if necessary, security review before the subscription can proceed.

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

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

This enhancement is designed to:
  • Reduce security risk
     by preventing outbound calls to unapproved endpoints.
  • Improve compliance
     through stronger review and approval controls.
  • Increase transparency
     with clearer client-visible statuses.
  • Support scale
     through 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 the
    Getting 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 the
    REST API related products
     section 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

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 a
Shared Secret Key Pair
 in the
Getting 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

Account Funding Transactions (AFTs)
 | RM-45825

Description
Mastercard AFTs are now available on First Data Merchant Solutions (Europe) on OmniPay Direct and Lloyds TSB Cardnet International.
Mandate
Does not apply.
Audience
Merchants who use First Data Merchant Solutions (Europe) on OmniPay Direct or Lloyds TSB Cardnet International.
Benefit
Account Funding Transactions (AFTs) are used by merchants to withdraw funds from a senders account in order to fund a recipient account. For example, transferring funds between accounts or adding funds to a wallet or card.
Technical Details
Merchants must contact their Omnipay acquirer to ensure correct Merchant Category Code setup and registration for AFTs.
AFT transactions are indicated to Visa through presence of valid
aftIndicator
 and
businessApplicationID
 fields and sender and recipient payment details in the authorization and clearing messages.
Important Dates
Released to production June 4, 2026.

Merchant Advice Codes
 | RM-45441

Description
Cybersource is adding support for Merchant Advice Codes (MAC) in the Cielo3 authorization response flow. When Cielo3 returns a Merchant Advice Code on an authorization response, Cybersource will pass that value through to the merchant in the existing merchant advice response fields.
Merchants will see this in the authorization response (API only, not in the Business Center) for Cielo3 authorizations. The MAC value provides guidance on how to handle declined transactions, including whether to retry, when to retry, whether updated account information is available, or whether the customer should use another payment method.
The MAC value is informational only. It does not change the authorization decision, response code, reason code, or transaction status. Merchants do not need to change their authorization request and no additional boarding or enablement is required.
Prerequisites
  • The merchant is enabled for Cielo3 processing
  • The transaction is a supported Cielo3 authorization transaction
  • A Merchant Advice Code is available in the authorization response
  • The merchant uses a supported API response channel: REST, SCMP, or Simple Order API
Mandate
Does not apply.
Audience
Merchants processing through the Cielo3 processor in Brazil for authorization transactions.
Benefit
  • Improved retry handling
  • Reduced unnecessary authorization attempts
  • Better customer-facing decline messaging
  • Improved recurring and subscription billing logic
  • Reduced support volume related to repeated declines
Technical Details
Field Names
API
Code Field
Raw Code Field
REST
processorInformation.merchantAdvice.code
processorInformation.merchantAdvice.codeRaw
SCMP
auth_merchant_advice_code
auth_merchant_advice_code_raw
SOAPI
ccAuthReply_merchantAdviceCode
ccAuthReply_merchantAdviceCodeRaw
Supported Values
The MAC value is handled as a string and may be alphanumeric. Values up to four characters are supported. MAC values are not limited to a fixed list, and additional values may be returned over time.
Common MAC values include:
Code
Description
Recommended Action
01
New account information available
Update account data where available
02
Cannot be approved at this time
Retry after 72 hours or use another payment method
03
Retry is not allowed
Do not retry; request another payment method
04
Token requirement is not met
Review token requirements
21
Plan cancelled
Stop billing attempts for the cancelled plan
24
Try again after 1 hour
Retry after 1 hour
25
Try again after 24 hours
Retry after 24 hours
26
Try again after 2 days
Retry after 2 days
27
Try again after 4 days
Retry after 4 days
28
Try again after 6 days
Retry after 6 days
29
Try again after 8 days
Retry after 8 days
30
Try again after 10 days
Retry after 10 days
40
Retry is not allowed
Do not retry; use another payment method
41
Retry is not allowed
Do not retry using the same single-use virtual card
43
Multi-use virtual card guidance
Ask customer to generate a new virtual card or contact issuer
Example REST Response Snippet
 
"processorInformation": { 
  "merchantAdvice": {
    "code": "03", 
    "codeRaw": "03" 
  } 
}
Important Dates
Released to production June 3, 2026.

Error Codes
 | RM-45803

Description
Some REST API transactions that combine payment services with risk services incorrectly return the error
502 General System Error
 instead of
201 Decline
.
Mandate
Does not apply.
Audience
Merchants who use the REST API.
Benefit
Correct error message.
Technical Details
None.
Important Dates
Released to production June 4, 2026.

Fixed Issues

Transaction Reponse Status
 | RM-45638

Description
This release fixes an issue that cause bundled authorization and capture which were successfully authorized transactions to return the status PENDING instead of AUTHORIZED.
Audience
Merchants who use Payments 2.0.
Technical Details
Any change that was made to a merchant's system as a workaround for the incorrect status must now be restored to its original functionality.
Important Dates
Released to production June 2, 2026.

Known Issues

Decision Manager
 | EPS-37196

Description
In Case Management, when a user exports a quick search to XML, an invalid XML attribute is generated in the downloaded file. This prevents the user from opening the exported file, leading to a validation error.
Audience
Users of Case Management in Decision Manager.
Technical Details
None.
Workaround
Replace the forward slash (/) within a SearchType/QuickSearch attribute name with a hyphen (-) or an underscore (_).

Invoicing and Portfolios
 | EPS-37204

Description
When a portfolio account looks up the address of a child account, the address is sometimes different from the one listed in the child account.
Audience
Portfolio users of Invoicing.
Technical Details
None.
Workaround
None.

Transaction Details for Portfolio Accounts
 | EPS-37405

Description
When portfolio users in the Business Center navigate from Manage Merchants to Transaction Details and then clicks the back button, they are redirected to the login page instead of Manage Merchants.
Audience
Portfolio users.
Technical Details
None.
Workaround
Perform the transaction search again without using the back button.

Transaction Search for Portfolio Accounts
 | EPS-37429

Description
After new transacting organizations are created, users of merchant-level accounts might not be able to see transactions for those organizations immediately. In some cases, it can take up to a few weeks before the transactions become searchable.
Audience
Portfolio users.
Technical Details
None.
Workaround
Search for the transactions using a transacting or portfolio organization's user account instead of a merchant organization.

Decision Manager
 | EPS-37478

Description
Merchants who use Account Takeover Protection in the Business Center see a red banner error when attempting to Mark as Suspect an event.
Audience
Merchants who use Account Takeover Protection.
Technical Details
None.
Workaround
Manually or Programmatically add information to the negative list.

Merchant Boarding
 | EPS-37750

Description
During merchant boarding, when Payer Authentication is configured for Cartes Bancaires cards, the field for Acquirer ID does not accept hyphen (-) or space ( ) characters. However, Cartes Bancaires does accept those values.
Audience
Users of merchant boarding.
Technical Details
None.
Workaround
Contact the Support team.