On This Page

Release Notes

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

Features Introduced This Week

Restrict Wildcard Queries in Transaction Search
 | RM-47629

Description
This release restricts wildcard query patterns for Transaction Search direct API users. Requests that use an unsupported wildcard pattern now receive an error response with guidance on proper query syntax.
Mandate
Does not apply.
Audience
Merchants who use the Transaction Search direct API endpoints. Business Center users are not affected.
Benefit
This change improves the performance and stability of transaction search.
Technical Details
Direct API requests that use an unsupported wildcard query pattern now receive an error response with guidance on proper query syntax.
Important Dates
Released on August 19, 2026.

Fixed Issues

No customer-facing fixes were released this week.

Known Issues

IUGU Settlements | EPS-40848

Description
Some transactions processed through the IUGU gateway take up to 20 minutes to update to
SETTLED
 status after a payment is processed, which might cause the transaction to time out on the merchant's system.
Audience
Some merchants who process transactions through the IUGU gateway.
Technical Details
A delay in persisting payment reference data causes the initial payment confirmation status update from IUGU to fail.
Workaround
None.

Invoicing | EPS-41822

Description
A defect is causing some invoices to remain in
PENDING
 status instead of transitioning to
PAID
 status after the cardholder completes payment.
Audience
Some merchants who use Invoicing.
Technical Details
A higher transaction volume caused some transactions to be missed, leaving the corresponding invoices in
PENDING
 status.
Workaround
Cybersource is updating the affected invoices to show the correct status.

Unified Checkout and Decision Manager | EPS-41981

Description
When a Unified Checkout customer enters a numeric-only first or last name during checkout, the authorization succeeds, but the post-authorization Decision Manager check fails, causing instant settlement to fail.
Audience
Merchants who use Unified Checkout together with Decision Manager, specifically when a numeric-only value is entered in the first or last name field.
Technical Details
Authorization succeeds because the numeric surname is accepted during authorization processing; the rejection occurs only in the post-authorization scoring, creating a mismatch between the authorization result and the DM result that causes instant settlement to fail despite a successful authorization.
Workaround
Ensure that customers do not enter a numeric-only value in the first or last name field, or disable the
After Authorization
 Decision Manager scoring option.

Prosa Credits | EPS-42197

Description
A defect is causing some settled Prosa transactions to be missing the
Credit
 button in the Business Center, which prevents merchants from creating a credit for the transaction in the Business Center.
Audience
Some merchants using the Prosa gateway, primarily in Latin America and the Caribbean (LAC).
Technical Details
During certain Prosa payment flows, the transaction's
BATCHED
 status does not persist to the database. Because the transaction is not identified as batched, the
Credit
 button does not appear.
Workaround
Use the Virtual Terminal batch file upload feature to process the credit instead.

Authorization | EPS-42267

Description
Some authorization requests sent to the
/pts/v2/payment
 endpoint intermittently received 5xx errors during three brief intervals.
Audience
Some merchants who use Authorization.
Technical Details
A brief internal service error caused the failures.
Workaround
None.

Announcements

These announcements are for
August 21, 2026
.

Network Routing Architecture Update

Cybersource endpoints will be migrated from the current routing model to a new architecture using updated IP subnet ranges.
This enhancement is designed to improve the performance, resiliency, and reliability of transaction delivery over the Internet. It will also enable seamless transaction routing across multiple Visa data centers, supporting more consistent and reliable transaction processing.
Cybersource Endpoints and IP Addresses Included
Current Application and endpoints:
CAS/Test
:
apitest.cybersource.com
 (current IP address:
66.185.182.49
)
Production
:
api.cybersource.com
 (current IP address:
66.185.182.149
)
Potential Impact
Clients who connect to the REST API endpoints listed above using Domain Name System (DNS) are not expecting to experience any impact. DNS records will be updated automatically to use the new routing architecture.
Clients whose networks are configured to allowlist IP addresses or who have hardcoded IP addresses will likely be impacted. These clients must update their proxy or firewall settings to include the new Visa IP address ranges.
There are no changes to TLS/SSL certificates or supported ciphers as part of this migration. However, Cybersource continues to recommend trusting the root TLS certificates for all secure endpoints.
Migration Timeline
CAS/Test
: October 15, 2026
Production
: January 31, 2027
Now Available
This technology is now available in both the test and production environments through these domains:
CAS/Test
:
apitest.visaacceptance.com
Production
:
api.visaacceptance.com
Deploying in the CAS/Test Environment provides a safe environment to test and validate access. Once testing is complete, you may migrate production processing anytime thereafter.
How to Adopt This Change
To use the new routing architecture, your firewall, or your commerce platform provider's firewall, must be configured to permit outbound traffic to the Visa cloud.
This large, dynamic IP address space represents a significant change from current access configurations. Therefore, it is critically important to test firewall configurations and confirm that connections are successful before migrating production traffic.
Clients who require IP address allowlists may use one of the following options.
Option 1
: Add these specific subnet ranges to your allowlist:
  • 198.217.128.0/17
  • 198.241.128.0/17
  • 66.185.176.0/20
Option 2
: Add these generic subnet ranges to your allowlist:
  • 198.241.206.0/24
  • 198.241.207.0/24

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.

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 newly submitted 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.
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
    .
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

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