Release Notes

These release notes cover all releases to the production server for the week ending

August 28, 2026

.

Announcements

These announcements are for

August 28, 2026

.

SOAP Tooklit Authentication Update

Cybersource will no longer support username- and password-based authentication for merchants who use the SOAP toolkit key
. You are required to remove username- and password-based authentication from your SOAP toolkit integration and transition to certificate-based authentication by these dates:

Test Environment: April 15, 2026

Production validation test (shock test): September 30, 2026. This applies only to selected merchants.

Production Environment: October 7, 2026

Your API requests to Cybersource will be rejected if you do not implement P12 authentication by the required dates.

See P12 Authentication Upgrade for SOAP Toolkit Key Users Migration Guide
.

Batch Upload Service IP Address Updates

The legacy IP address for the Cybersource Batch Upload service will be replaced by two new IP addresses. We recommend that you use domain names instead of IP addresses.

The new addresses will take effect at these URLs and times:

Testing Environment

batchtest.cybersource.com

July 28, 2026, at 4:00 am GMT

Production Environment:

batch.cybersource.com

September 15, 2026, at 4:00 am GMT

Enhanced Webhook URL Review and Approval Process

We have introduced an enhancement to webhook subscription processing to improve security, compliance, and visibility for webhook-related URLs. Webhook URLs are now validated and reviewed before they can be used. This includes both subscriptions and existing subscriptions currently on file.

What is Changing

When a webhook subscription is created or updated, the URLs associated with that subscription are evaluated through a validation and approval process.

Applies to:

Webhook URL
(required)

OAuth URL
(if applicable)

Health Check URL
(if applicable)

As part of this enhancement, clients might now see 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

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 to PENDING_REVIEW
.

If any URL is rejected or blocked, the subscription status changes to BLOCKED
.

If all required URLs are approved, the subscription status changes to INACTIVE
.

In cases where a subscription status is change to BLOCKED
, clients are 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.

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 March 2027
.

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: See Construct JWT Messages Using a
P12 Certificate
in the Getting Started with REST Developer Guide
See Construct JWT Messages Using a
Shared Secret Key Pair
in the Getting Started with REST Developer Guide

HTTP Messaging Migration to JWT Messaging

By March 2027
, 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

Secure Acceptance Sunset

Secure Acceptance is being sunset as part of a move toward modern, web-based payment acceptance solutions. The target date for merchants to complete migration from Secure Acceptance is September 30, 2026. If you have already begun migrating off Secure Acceptance and expect to complete the move by this date, disregard this message.

Unified Checkout is available as the recommended migration path. It provides a low-code payment acceptance experience with support for expanded payment options and integrated services.

For more details about this change and guidance on how to migrate, see this knowledge base article: Secure Acceptance Sunset (KA-11531).

Review your migration plans and take the necessary steps to move off Secure Acceptance before the deadline. If you need assistance, contact your Visa representative.

Features Introduced This Week

Login Page Enhancement: Improved Visibility of Forgot Password Link
| RM-44255

Description: This release repositions the Forgot Password link on the login page to improve visibility and align password recovery more closely with the login flow. This is a user interface change only. It does not affect authentication behavior or password reset functionality.
Mandate: Does not apply.
Audience: All clients.
Benefit: Clients can locate the password recovery option more easily from the login page.
Technical Details: The Forgot Password link now appears in a different position on the login page. The Forgot Password link moved from the page footer to a position next to the Password field. No customer action is required.

Before:

After:
Important Dates: Released on August 24, 2026.

Fixed Issues

Merchant ID Dropdown Fix on Transactions through Merchant Management Service | RM-48183

Description: The Merchant ID dropdown UI element on the Transactions page was producing an error that prevented users from fetching the merchant list. This fix resolves that error and users can now use the UI as intended.
Audience: Merchants, Issuers, and Acquirers.
Technical Details: The Transaction Search merchant list dropdown UI can now be populated for accounts when
account_id
is greater than 30 characters.
Important Dates: Released on August 25, 2026

Known Issues

There are no known issues this week.