Release Notes {#rn-general} =========================== These release notes cover all releases to the production server for the week ending May 29, 2026. Announcements {#rn-announce} ============================ These announcements are for May 29, 2026. TLS Updates {#tls-1-3} ====================== 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, 2026 *ics2wstesta.ic3.com* *ics2wstest.ic3.com* *apitest.cybersource.com* **Production environment**: June 2, 2026 *ics2wsa.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: [tls-certificate-lifetimes-will-officially-reduce-to-47-days](https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days "") **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: [?code=KA-09802](https://support.visaacceptance.com/knowledgebase/Knowledgearticle/?code=KA-09802 "") Contact your Customer Support representatives with any questions. Webhooks Updates {#webhooks-validations-decommission} ===================================================== Webhooks version 1 will be decommissioned by end of the year 2026. See [Webhooks version 2 in the Developer Center](https://developer.cybersource.com/api-reference-assets/index.md#webhooks ""). Enhanced Webhook URL Review and Approval Process {#webhooks-urls} ================================================================= 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** {#webhooks-urls_section_dnx_jdt_1jc} --------------------------------------------------------- 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) {#webhooks-urls_ul_enx_jdt_1jc} As part of this enhancement, clients might now see the following user-facing statuses: * **PENDING_REVIEW** * **BLOCKED** {#webhooks-urls_ul_fnx_jdt_1jc} 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** {#webhooks-urls_section_hnx_jdt_1jc} ------------------------------------------------------------------ 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**. {#webhooks-urls_ol_inx_jdt_1jc} **Impact on Existing Subscriptions** {#webhooks-urls_section_jnx_jdt_1jc} ------------------------------------------------------------------------- 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**. {#webhooks-urls_ul_knx_jdt_1jc} 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. {#webhooks-urls_ul_lnx_jdt_1jc} **For New Subscriptions** {#webhooks-urls_section_mnx_jdt_1jc} -------------------------------------------------------------- New webhook-related URLs may go through validation and, if necessary, security review before the subscription can proceed. **For Existing Subscriptions** {#webhooks-urls_section_nnx_jdt_1jc} ------------------------------------------------------------------- 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** {#webhooks-urls_section_onx_jdt_1jc} ------------------------------------------------------------------------------- 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** {#webhooks-urls_section_pnx_jdt_1jc} ---------------------------------------------------------------------- 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. {#webhooks-urls_ul_qnx_jdt_1jc} Message-Level Encryption Upcoming Mandate {#announcement-mle} ============================================================= 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](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-message-intro/restgs-mle-intro.md "") 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](https://github.com/CyberSource ""). 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 a P12 Certificate](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-message-intro/restgs-jwt-const-intro.md "") in the *Getting Started with REST Developer Guide* * See [Construct JWT Messages Using a Shared Secret Key Pair](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-shared-secret-intro/restgs-jwt-con-shared-secret-intro.md "") in the *Getting 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 a Shared Secret Key Pair](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-shared-secret-intro.md "") in the *Getting Started with REST Developer Guide* Smart Auth Retirement {#smart-auth-eol-33440} ============================================= 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 {#rn-features} ============================================ **3-D Secure** \| RM-44940 -------------------------- Description : This release adds support for 3-D Secure data-only transactions for Rede for Visa and Mastercard e-commerce transactions in Brazil. It enables merchants to submit enriched 3-D Secure data in the Cybersource REST API without triggering cardholder authentication or challenge flows. This is an API-only enhancement; there are no changes in the Business Center. Mandate : Does not apply. Audience : This release affects Cybersource merchants using Rede in Brazil, for Visa and Mastercard e-commerce transactions. Benefit : This feature enables merchants to submit authorization requests with additional security-related data and checks in the background, without adding friction to the checkout experience. Because no cardholder challenge is triggered, merchants can provide more issuer-relevant transaction context while keeping the purchase flow unchanged for the customer. : By giving issuers more information during authorization, this enhancement can improve approval rates, reduce false declines, and decrease unnecessary authentication challenges. Liability remains with the merchant. Technical Details : To implement this feature, merchants submit a standard authorization request with the following 3DS Data Only fields: : **Required fields** : consumerAuthenticationInformation.cavv consumerAuthenticationInformation.paSpecificationVersion consumerAuthenticationInformation.directoryServerTransactionId processingInformation.commerceIndicator : **Optional field** : consumerAuthenticationInformation.xid : **Additional implementation requirements:** : * Submit the transaction as an e-commerce payment. * Submit the transaction in BRL. * Process the transaction as Visa or Mastercard through REDE. * No challenge is performed, no step-up authentication is expected, and the response follows the standard authorization response structure. {#rn-features_ul_e3d_ytm_kjc} : **Request Example** : ``` { "processingInformation": { "commerceIndicator": "internet" }, "paymentInformation": { "card": { "number": "4111111111111111", "expirationMonth": "12", "expirationYear": "2030", "sourceAccountType": "C" } }, "consumerAuthenticationInformation": { "cavv": "AAABBIIFmAAAAAAAAAAAAAAAAAA=", "xid": "MDAwMDAwMDAwMDAwMDAwMzIyNzY=", "paSpecificationVersion": "2.2.0", "directoryServerTransactionId": "f3eecb72-31b3-4a62-b9af-8e6a8b7a0abc" }, "orderInformation": { "amountDetails": { "totalAmount": "100.00", "currency": "BRL" }, "billTo": { "firstName": "First", "lastName": "Last", "address1": "Av Paulista 123456", "locality": "Sao Paulo", "administrativeArea": "SP", "postalCode": "01310-100", "country": "BR", "email": "person.person@example.com" }, "shipTo": { "firstName": "First", "lastName": "Last", "address1": "Av Paulista 123456", "locality": "Sao Paulo", "administrativeArea": "SP", "postalCode": "01310-100", "country": "BR" } } } ``` : **Response Example** : ``` { "id": "6654706105956431203955", "status": "AUTHORIZED", "submitTimeUtc": "2026-04-21T14:22:10Z", "processorInformation": { "approvalCode": "831000", "responseCode": "00", "transactionId": "123456789012345" }, "networkTransactionId": "987654321234567", "reconciliationId": "6654706105956431203955" } ``` Important Dates : Released to production April 24, 2026. **Updates for FDC Nashville Global** \| RM-44320 ------------------------------------------------ Description : These features are released for FDC Nashville Global: : **Account Name Inquiry**: Ensures compliance with network mandates and enhances fraud prevention by validating account holder names during account verification and 0 amount authorization transactions. : **Extended Authorizations**: Enables Extended Authorization capabilities, allowing merchants to hold approved authorizations for up to 30 calendar days for eligible Card Not Present transactions and customer-initiated transactions. : **AFT Refund**: AFT bitmap 43 Authorization/Credit Authorization changes and AFT Credit Authorization changes, disabling Credit Auth for FDC Nashville Global Visa AFT transactions, and updating bitmap 43 merchant name for all AFT transactions. Mandate : Does not apply. Audience : FDC Nashville Global merchants. Benefit : This release enhances fraud prevention and allows merchants to hold approved authorizations for up to 30 calendar days. Technical Details : None. Important Dates : Released to production May 28, 2026. Fixed Issues {#rn-fixed-issues} =============================== **Follow-On Credit Transactions** \| RM-45829 --------------------------------------------- Description : This release fixes an error in which some follow-on credit transactions for some payment gateways were failing with an ESYSTEM error, returning the message *The follow-on credit cannot be processed because the capture transaction has not been processed yet*. Audience : All gateways that have enabled Auto Capture. Technical Details : None. Important Dates : Released to production May 22, 2026. Known Issues {#rn-known-issues} =============================== **Transaction Search** \| EPS-37429 ----------------------------------- Description : After new transacting organizations are created, merchant-level organizations cannot see the transacting organization's transactions in the Business Center immediately. In some cases, it can take weeks for tansactions to appear. Audience : Portfolio merchants. Technical Details : None. Workaround : Search for the transactions using a transacting MID user or a portfolio MID user. **Payer Authentication** \| EPS-37750 ------------------------------------- Description : When portfolio accounts onboard merchants to 3-D Secure processing for Cartes Bancaires cards on the Business Center's Payer Authentication Configuration screen for transacting accounts, the Acquirer ID is validated for 1-35 alphanumeric characters only. Accounts with space or hyphen characters in their names are not being accepted. Audience : Portfolio merchants. Technical Details : None. Workaround : Contact support.