Introduced Changes

Webhook URL (required)
OAuth URL (if applicable)
Health Check URL (if applicable)

PENDING_REVIEW
BLOCKED

Status Descriptions

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.

Review the affected endpoints.
Update the URLs to an acceptable endpoint.
Resubmit the subscription for processing.

For New Subscriptions

Why We Are Making This Change

Reduce security risk
by preventing outbound calls to unapproved endpoints.
Improve compliance
through stronger review and approval controls.
Increase transparency
with clearer merchant-visible statuses.
Support scale
through a standardized and repeatable validation process.

Overview of MLE

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.
Update your REST API SDK. For more information, see the
REST API related products
section in the Cybersource GitHub.

JSON Web Token Construction Update

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

Update Method

See Construct JWT Messages Using a
Shared Secret Key Pair
in the
Getting Started with REST Developer Guide

Merchant Impact

You might occasionally experience slower response times or timeouts.
For API integrators, an HTTP
429
response often indicates that there are too many request responses on Transaction Search, Case Search, or the Find Similar Transactions feature, particularly for large, broad, or long-date-range searches.

Recommended Actions

Keep multi-value lookups to 15 identifiers or less per search.
Use the narrowest date range that answers your question. A period of 7 days or less is recommended for interactive transaction searches.
Break large bulk lookups into smaller batches instead of using one large combined search.
Avoid broad wildcard searches, especially searches that use a short prefix and an asterisk (*).
If a search is slow or times out, wait a moment before retrying instead of retrying immediately.
For API integrators:
Limit each request to 15 or fewer identifiers.
Use the narrowest date range your job needs.
Implement back off on timeouts or errors instead of tight-loop retries.
If you receive a
429
response, honor any Retry-After value and reduce your request rate and batch size rather than immediately retrying.
If your workflow repeatedly requires a large multi-identifier or long-date-range search, contact your support or account team so it can be reviewed for the batch and export path or an appropriate exception.

Recommended Next Step

Best Practices for Implementing Searches

General Guidance

Keep multi-value lookups to 15 identifiers or less per search. Identifiers include reference numbers, request IDs, or account numbers. For larger lookups, use another method instead of one very large interactive request.
Use the narrowest date range that answers your question. Use 7 days or less for interactive transaction searches.
Break large bulk lookups into smaller batches. For example, implement several searches of less than or equal to 15 identifiers and less than or equal to 7 days instead of implementing one combined search that spans many identifiers and a long date range.
Retry failed or slow searches manually, using a short pause instead of immediately re-running the identical search in an automated loop.

Practices to Avoid

Do not implement broad wildcard searches. These searches scan a large portion of the search index and use the most resources.
These wildcard validation rules now apply:
Leading wildcard searches are no longer accepted.
Wildcard searches must contain a minimum of three characters preceding the wildcard character (*). These examples demonstrate the unsupported and the accepted wildcard formats.
Unsupported Wildcard Formats:
*ABC
A*
AB*
12*
Accepted Wildcard Formats:
ABC*
ABCD*
123*

Avoid combining a large number of identifiers with a long date range in the same search. Cost increases roughly with identifiers multiplied by a date range, so a search that is fine alone can be expensive when both are large together.
Avoid automated rapid-retry on a timeout. An identical search that timed out will typically time out again if re-run immediately, which adds load on the service without improving results.

API Searches: Request Shape

Cap each request to 15 or fewer identifiers when using multi-value lookups. If your integration currently sends larger batches, split them into multiple smaller requests.
Use an end-of-day reconciliation or bulk report instead of paging through many large interactive search calls.
Use the narrowest date range your job actually needs. Recurring jobs that request a wide window are a common source of avoidable load.
Avoid wildcard or short-prefix values in identifier fields. Search for an exact full value when it is available.

API Searches: Retry and Error Handling

Implement a back-off retry instead of tight-loop retry. If a request times out or errors, wait before retrying, and increase the wait time on repeated failures (exponential back off).
If you receive a
429
(rate limited) response, treat it as a signal to slow down, not a bug to route around. Honor any Retry-After value if present, and reduce your request rate/batch size rather than retrying immediately or in parallel.
Cap your retry attempts for a given request. For example, make 3 to 5 attempts with increasing back-off retries and alert/log instead of retrying indefinitely.
Watch for repeated identical requests from your own systems. A scheduled job that re-issues the exact same search on every run because a previous run did not complete can create a sustained load without your team realizing it. Add job-level locking or de-duplication search so a stopped run does not stack up.

Business Center Searches

Transaction Search:
search on a specific field (order number, request ID, reference number) instead of a broad free-text and keyword term when possible. Keep the date range to 7 days or less.
Quick Search:
use a reasonably narrow date range rather than the widest default. If you manage multiple sub-accounts under a parent account, search from the specific sub-account instead of from the top-level parent view when you know the account where the transaction belongs.
Bulk Export and Reporting:
if you need a large number of transactions or cases, use the Business Center report feature to pull the full set at once instead of repeatedly re-running and paging through search results. If a search is slow or times out, wait a moment and retry once instead of repeatedly clicking search or refresh in quick succession.

Follow-On Credit Transactions Now Progress Correctly after RTC Flag Updates

| RM-47953  

Description

This release fixes an issue that could cause follow-on credit transactions to remain in a

Pending

status after the Real-Time Clearing (RTC) flag changed from

N

to

Y

.

Audience

Merchants processing follow-on credit transactions through an affected processing connection.

Technical Details

Previously, some follow-on credit transactions remained in a

Pending

status after the RTC flag was updated. Transaction status now progresses correctly when the RTC flag changes to

Y

.

Important Dates

Released on September 23, 2026

Account Updater Configuration Can Now Be Saved at the Merchant Level

| RM-48214

Description

This release resolves an issue that prevented merchants from adding and configuring the Account Updater product at the merchant level in the Business Center. Previously, when users selected the default Account Updater template, the template loaded without configuration values, and merchant-level Account Updater settings were not saved after users selected

Apply

. Account Updater configurations can now be applied and saved correctly.

Audience

Portfolios that use the Account Updater product in the Business Center.

Technical Details

Previously, the default Account Updater template loaded without configuration values, and merchant-level Account Updater settings were not saved when users selected

Apply

. Account Updater templates now load the expected configuration values, and merchant-level settings are saved correctly.

Important Dates

Released on September 23, 2026

TRN Is Now Retained across Credit Transactions

| RM-48424

Description

This release resolves an issue that could cause Transaction Reference Number (TRN) inconsistencies for follow-on and standalone credit transactions when a merchant did not provide a TRN in the credit request. Cybersource now retains the original authorization TRN throughout the transaction lifecycle, providing consistent transaction linking and simplifying reconciliation.

Audience

Some merchants processing credit transactions through any impacted processing connection.

Technical Details

Previously, when a merchant did not provide a TRN in a credit request, the processor received a different TRN than the one associated with the original authorization. The TRN sent to the processor now matches the original authorization TRN, and merchants can view the original authorization TRN in the

P74V

-prefixed online message for the credit authorization request.

Important Dates

Released on September 24, 2026