On This Page
Release Notes
These release notes cover all releases to the production server for the week ending
July 31, 2026
.Announcements
These announcements are for
July 31, 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.
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 newly submitted subscriptions and
existing subscriptions currently on file.
What is Changing
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.
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.
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
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
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
Features Introduced This Week
No customer-facing features were released this week.
Fixed Issues
No customer-facing fixes were released this week.
Known Issues
There are no known issues this week.