On This Page

Release Notes

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

Announcements

These announcements are for
July 10, 2026
.

I.P. Address Updates

The legacy I.P. address for the Cybersource Batch Upload service will be replaced by two new I.P. addresses. We recommend that you use domain names instead of I.P. Addresses.
The new addresses will take effect at these URLs and times:
Testing Environment
batchtest.cybersource.com
July 28th, 2026 4:00am GMT
Production Environment:
batch.cybersource.com
September 15th, 2026 4:00am GMT

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

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

Features Introduced This Week

Salesforce Order Management

Description
This release introduces enhanced payment lifecycle capabilities by enabling Capture and Refund functionalities for both PayPal and Venmo transactions.
Mandate
Does not apply.
Audience
Users of Salesforce Order Management.
Benefit
This release enables merchants to efficiently complete payment settlements and process refunds directly in the platform, improving transaction management, operational flexibility, and overall customer experience.
Technical Details
None.
Important Dates
Released to production July 9, 2026.

Klarna Advantage
 | RM-45665

Description
Clients using the Transaction Search page in the Business Center can use a new search filter in the Status filter drop-down menu. The new filter is called
Step Up Required
, and can be used to filter Klarna Advantage transactions. Users can select this status to find transactions in which the authorization response contains a
STEP_UP_REQUIRED
 result. The status also displays in search results and on the Transaction Details page.
Mandate
Does not apply.
Audience
Users of Klarna Advantage.
Benefit
Clients can now quickly filter and identify Klarna Advantage transactions that triggered step-up authentication during authorization, reducing manual effort when reviewing or investigating those transactions.
Technical Details
None.
Important Dates
Released to production July 7, 2026.

Staged Digital Wallet
 | RM-45223

Description
Cybersource now supports Staged Digital Wallet transactions for merchants processing through
Rede
 in Brazil. Merchants submit staged-wallet data in the standard Cybersource REST payment-authorization request for these scenarios:
  • Cash-In
     loads funds into a wallet from a registered card.
  • Purchase
     uses a wallet to make a payment or to transfer funds between wallets.
Clients experience this in the API. There is no change in the Business Center and no new response fields. Consumer Bill Payment Service is not part of this release.
Mandate
Does not apply.
Audience
Merchants processing through
Rede
 in Brazil using the Cybersource API.
Benefit
Brazilian merchants and wallet operators can process wallet-based cash-in and purchase/transfer activity through Rede using their existing Cybersource integration, extending supported payment experiences with no change to response handling.
Technical Details
Merchants include staged-wallet fields in the standard authorization request. Required field set:
Core wallet and transaction type
  • paymentInformation.customer.stagedDigitalWalletId
  • processingInformation.walletTransactionIntent
    :
    01
     = Purchase, including wallet-to-wallet transfer;
    02
     = Cash in
  • processingInformation.destinationType
    :
    04
     = machine-to-machine, same owner;
    05
     = person-to-person, different holder;
    06
    /
    07
     = transfers;
    08
     = stored-value wallet
  • processingInformation.businessApplicationId
    :
    AA
     = same person (pair with
    04
    );
    PP
     = different people (pair with
    05
    )
Sub-merchant
 (
aggregatorInformation.subMerchant
):
merchantCategoryCode
,
id
,
address1
,
country
,
postalCode
,
cardAcceptorId
Sender
 (
senderInformation
):
firstName
,
lastName
,
address1
,
locality
,
countryCode
,
taxIdNumber
Recipient
 (
recipientInformation
): conditional, required for person -to-person:
firstName
,
lastName
,
taxIdNumber
,
beneficiaryId
Merchant
 (
merchantInformation
):
merchantDescriptor.name
,
taxId
Important Dates
Released to production July 2, 2026.

Fixed Issues

No customer-facing fixes were released this week.

Known Issues

Invoicing
 | EPS-41011

Description
Some merchants might experience intermittent HTTP 500 errors when sending API POST requests to the
/invoicing/v2/invoices
 endpoint.
Audience
API users of Invoicing.
Technical Details
None.
Workaround
None.

Decision Manager
 | EPS-39533

Description
When creating a custom rule in the Business Center, selecting a comparison value also selects a corresponding custom field and vice versa. Deselecting either field causes both fields to be deselected.
Audience
Users of Decision Manager.
Technical Details
None.
Workaround
None.