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 fewer per search.
Use the narrowest date range that answers your question. A period of no more than 7 days 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 that 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 fewer 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 a period of no more than 7 days 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 fewer.
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.

Automated Clearing House (ACH) eCheck Follow-On Credit Eligibility Restored

| RM-49229

Description

This release corrects a defect affecting Automated Clearing House (ACH) eCheck transactions. Sometimes, follow-on credits were incorrectly unavailable because the system could not accurately calculate transaction age when processing request IDs longer than 26 characters. Following this release, merchants can perform eligible follow-on credits for ACH eCheck transactions for up to 180 days after the original debit transaction, consistent with the intended processor rules.

Mandate

Does not apply.

Audience

Some merchants processing eCheck transactions through an ACH processor.

Technical Details

No API changes are required, and no merchant configuration changes are necessary to use this correction.

Important Dates

Released on November 4, 2026.

SDK Upgrade Breaks Some .NET SOAP Requests

| EPS-44622

Description

Applications using sign-only message security cannot submit Simple Order API requests after upgrading the .NET SOAP SDK from version 1.4.10 to version 1.4.11. Affected requests fail with an identity-check error before they are sent.

Audience

Some merchants using version 1.4.11 of the .NET SOAP SDK for the Simple Order API with sign-only message security.

Technical Details

Version 1.4.11 incorrectly applies an identity-verification check to sign-only connections. As a result, the SDK can throw

System.ServiceModel.Security.MessageSecurityException

with an

Identity check failed for outgoing message

message before submitting the request.

Workaround

Continue using version 1.4.10 of the .NET SOAP SDK until a corrected version is available.

Some Transaction Details Pages Do Not Load

| EPS-46021

Description

Some transactions appear in Transaction Search, but their Transaction Details pages display

Unable to Load Transaction Data

. The transaction data remains available in the underlying system.

Audience

Some

Cybersource

users viewing transactions with unusually large linked transaction histories.

Technical Details

The Transaction Details page can time out while retrieving and assembling a transaction history containing an exceptionally large number of related attempts. This issue does not indicate that the transaction data is missing.

Workaround

Use Transaction Search to view the available transaction summary. Contact Customer Support if the complete transaction history is required.

Some Successful Authorizations Return System Errors

| EPS-46070

Description

Some successful payment authorizations can return an HTTP

500

response with

SYSTEM_ERROR

. The authorization might still appear as successful in Transaction Management.

Audience

Some merchants submitting payment authorization requests through the REST API.

Technical Details

This issue occurs when the authorization succeeds but the returned decision code is not recognized during API response transformation. The successful backend result is then replaced with a system-error response.

Workaround

Before retrying an affected authorization, use Transaction Management or the Transaction Search API to verify whether the original request succeeded.

Some Payer Authentication Updates Appear Successful

| EPS-46075

Description

Some UnionPay Payer Authentication configuration updates can appear successful after an earlier update was rejected. A subsequent attempt can report that no changes were submitted even though the configuration was not accepted by the authentication service.

Audience

Some merchants configuring UnionPay Payer Authentication through Business Center or the Payer Authentication configuration API.

Technical Details

When an update to the default-currency configuration is rejected, the submitted acquirer information can still be stored in the local Payer Authentication profile. Retrying the same update can then return a successful

No changes in request

response without resubmitting the configuration for validation.

Workaround

No known workaround.

Some eCheck Billing States Are Incorrect

| EPS-46119

Description

Some eCheck transactions processed through Unified Checkout can contain an incorrect billing state when billing-address collection is disabled. For affected US addresses, Unified Checkout can replace the submitted state with

AL

.

Audience

Some US merchants accepting eCheck payments through Unified Checkout.

Technical Details

This issue occurs when Billing Address is disabled and the capture mandate does not require billing-address collection. Under these conditions, the submitted value in

orderInformation.billTo.administrativeArea

might not be preserved.

Workaround

In

Cybersource

, enable

Billing Address

under

Payment Configuration > Unified Checkout > Customer Information and Payment Flow

, and select

Zip only

or

Full address

.

Some Authorizations Include Conflicting Exemptions

| EPS-46258

Description

Some authorization requests can be declined when a Payer Authentication outage occurs and another Strong Customer Authentication (SCA) exemption is already present. Affected requests return reason code

102

and indicate that only one SCA exemption can be submitted per authorization.

Audience

Some merchants using Payer Authentication and SCA exemptions in Europe.

Technical Details

During some directory-server outages, the Payer Authentication response can add an outage exemption without recognizing an existing exemption. The authorization request is then declined because it contains more than one SCA exemption.

Workaround

No known workaround.

Some Report Events Display in One Row

| EPS-46426

Description

Some Processor Events Detail Reports display multiple processor events as comma-separated values in a single report row. The underlying event records and amounts remain correct.

Audience

Some merchants using Processor Events Detail Reports.

Technical Details

This issue occurs when a transaction has more than one processor event in the selected report period. The report combines the events into one row instead of displaying each event separately.

Workaround

No known workaround.

Some PayPal References Are Not Preserved

| EPS-46577

Description

Some merchants submitting custom reconciliation references for PayPal order, capture, or session requests receive system-generated references instead. As a result, merchants might be unable to use their submitted values to reconcile affected PayPal transactions.

Audience

Some merchants using PayPal through alternative payments and submitting custom reconciliation references.

Technical Details

Values submitted in

processingInformation.reconciliationId

or

orderInformation.invoiceDetails.invoiceNumber

are not included in affected PayPal order, capture, and session requests. PayPal refund requests preserve the submitted reference correctly.

Workaround

No known workaround.

Some Payer Authentication Validations Fail

| EPS-46646

Description

Some merchants using hybrid Payer Authentication receive an authentication failure when validating successful 3-D Secure authentication results. Affected requests return reason code

479

and the message

Unable to validate response access token.

Audience

Some merchants using hybrid Payer Authentication in Europe.

Technical Details

The affected validation flow does not recognize the JSON Web Token (JWT) issuer used for some migrated Payer Authentication sessions. As a result, a successful authentication result can fail validation when

responseAccessToken

is submitted.

Workaround

No known workaround.

Some Payer Authentication Activations Fail

| EPS-46739

Description

Some newly onboarded merchants cannot enable 3-D Secure Payer Authentication through

Cybersource

or API Onboarding. Activation fails and can incorrectly indicate that the merchant has already been created.

Audience

Some newly onboarded merchants enabling 3-D Secure Payer Authentication through

Cybersource

or API Onboarding.

Technical Details

A newly created Payer Authentication profile might not be available when the system immediately attempts to use it as the merchant's default profile. The activation request then fails even though the new profile was created successfully.

Workaround

Contact Customer Support to complete Payer Authentication profile generation and synchronization for the affected merchant.

Some E-Commerce Transactions Rejected during Clearing

| EPS-46911

Description

Some Mastercard e-commerce transactions using 3-D Secure authentication are incorrectly classified as manually entered transactions and rejected during clearing.

Audience

Some merchants processing Mastercard e-commerce transactions through an affected processing connection in the US.

Technical Details

Affected sale and credit authorization messages do not include the required e-commerce classification and authentication information in ISO Field 63. As a result, transactions can receive Mastercard International Payment Management rejection code

8679

during clearing even when authorization completes successfully.

Workaround

No known workaround.