On This Page

Release Notes

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

Announcements

These announcements are for October 16, 2026.

SOAP Toolkit Authentication Update

Cybersource
 will no longer support username- and password-based authentication for merchants who use the
SOAP Toolkit key
. You must 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 a.m. UTC
Production Environment:
batch.cybersource.com
September 15, 2026, at 4:00 a.m. UTC

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 new subscriptions and existing subscriptions currently on file.

Introduced Changes

When a webhook subscription is created or updated, the URLs associated with that subscription are evaluated through a validation and approval process.
Applies to:
  • Webhook URL (required)
  • OAuth URL (if applicable)
  • Health Check URL (if applicable)
As part of this enhancement, user-facing statuses have been added:
  • 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 URLs 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 changed to BLOCKED, merchants are expected to perform these tasks:
  1. Review the affected endpoints.
  2. Update the URLs to an acceptable endpoint.
  3. Resubmit the subscription for processing.

For New Subscriptions

New webhook-related URLs might go through validation and, if necessary, security review before the subscription can proceed.

Why We Are Making This Change

This enhancement provides these benefits:
  • 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.

Message-Level Encryption Upcoming Mandate

An updated version of message-level encryption (MLE) will become required in order for merchants to use the APIs. Portfolio owners must enable this updated version of MLE in order 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

JSON Web Token Construction Update

There are new requirements for how to construct JSON Web Tokens (JWTs) 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 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

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 improves 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
Merchants who connect to the REST API endpoints (
apitest.cybersource.com
 and
api.cybersource.com
) use a Domain Name System (DNS) should not be affected. DNS records will be updated automatically to use the new routing architecture.
Merchants with networks configured to allowlist IP addresses or who have hardcoded IP addresses will likely be impacted. These merchants should update 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. When testing is complete, you may migrate production processing.
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.
Merchants who require IP address allowlists can use one of these options:
Option 1
: Merchants can add these specific subnet ranges to IP address allowlists:
  • 198.217.128.0/17
  • 198.241.128.0/17
  • 66.185.176.0/20
Option 2
: Merchants can add these generic subnet ranges to IP address allowlists:
  • 198.241.206.0/24
  • 198.241.207.0/24

Secure Acceptance Sunset

Secure Acceptance is being sunset as part of a move toward web-based payment acceptance solutions. The target date for merchants to complete migration from Secure Acceptance is September 30, 2026. If you have already begun migrating from Secure Acceptance and expect to complete the move by this date, disregard this message.
Unified Checkout is available as the recommended migration path. It provides a low-code payment acceptance experience with support for expanded payment options and integrated services.
For more details about this change and guidance on how to migrate, see this knowledge base article: Secure Acceptance Sunset (KA-11531).
Review your migration plans and take the necessary steps to move from Secure Acceptance before the deadline. If you need assistance, contact your Visa representative.

Transaction Search Performance Update

Cybersource
 is aware of an intermittent issue that impacts transaction search performance. The search functions in the APIs and
Business Center
 are served from a shared search platform that is used by all Transaction Management module customers. An issue can occur when there is unusually high search activity, which places a heavy load on the shared search service.
Cybersource
 applied traffic controls to reduce the impact and is rolling out additional safeguards to prevent recurrence.
This issue does not impact payment processing transactions.
To improve transaction search performance and provide more consistent response times, the transaction search platform is being updated for requests that use multiple search identifiers. As part of this enhancement, searches that include multiple identifiers will support up to 15 identifiers per request. Merchants whose integrations currently submit larger batches should update their systems to divide searches into smaller requests.

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 it can be reviewed for the batch and export path or an appropriate exception.

Recommended Next Step

Review your search and integration patterns and adhere to the guidance provided in the Best Practices for Implementing Searches section.

Best Practices for Implementing Searches

These best practices apply to searches you implement using the Transaction Search API, Case Search API, and the
Business Center
. Following these practices will help keep your searches and detail lookups fast and reliable.
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.

Features Introduced This Week

Installment Data Added to Settlement Files for Peru Transactions
 | RM-48077

Description
Settlement files for Peru transactions now include additional installment data to support enhanced transaction reconciliation and reporting. This enhancement enables installment-related information to be included for both Mastercard and non-Mastercard transactions and allows issuer additional-data fields to be reported together within the same settlement file when applicable.
Mandate
Does not apply.
Audience
Some merchants and acquirers processing installment transactions in Peru.
Technical Details
The enhancement adds the
CP08 TCR2
 record to
TC33
 files so that both
issuer_additional_data
 and
issuer_additional_data_response
 can be included simultaneously. It also generates
CP01 TCR9
 records for Peru transactions that contain installment data.
Important Dates
Released on October 14, 2026.

Fixed Issues

Invoice Webhook Notifications Are Now Correctly Delivered After Successful Payment Processing
 | RM-49120

Description
Merchants now receive Invoice Webhook notifications after invoice payments are successfully processed.
Audience
Merchants using Invoice Webhooks.
Technical Details
An issue affecting invoice-payment event generation no longer prevents webhook notifications from being delivered.
Important Dates
Released on October 14, 2026.

Enterprise
Business Center
 Users Are No Longer Unexpectedly Logged Out After Authentication
 | RM-49846

Description
Some
Business Center
 users were unexpectedly returned to the login page immediately after successfully signing in, including after completing one-time passcode (OTP) authentication.
Audience
Some
Business Center
 users.
Technical Details
A client-side session-management issue incorrectly identified some active sessions as invalid and triggered an unexpected logout. Existing valid sessions now remain active when users open new browser tabs.
Important Dates
Released on October 16, 2026.

Known Issues

Validation and Capture Requests Return an Unexpected Response for CVN Soft Declines
 | EPS-43280

Description
Some merchants using the Payments API receive an unexpected response when a combined validation and capture request encounters a card verification number (CVN) soft-decline condition. Instead of receiving the expected review status, the request returns a response indicating a CVN failure even though the transaction is authorized.
Audience
Some merchants using the Payments API.
Technical Details
Combined validation and capture requests submitted to
POST /pts/v2/payments
 can return
CV_FAILED
 for certain CVN soft-decline scenarios. Affected transactions can be authorized successfully while returning an unexpected response status.
Workaround
No known workaround.

Stand-Alone Credit Batch Uploads Return Incomplete Processing Information
 | EPS-43394

Description
Some merchants using Stand-Alone Credit through Batch Upload receive incomplete processing information when batch uploads fail. Request IDs might not be searchable in the
Business Center
, Token IDs might not be displayed for affected transactions, and OLP (Offline Processing) batch response files might be blank.
Audience
Some merchants using Stand-Alone Credit through Batch Upload.
Technical Details
Failed batch uploads can return the error message
invalidField_0=recurringSubscriptionInfo_subscriptionID
.
Workaround
No known workaround.

Certain SDK Versions Might Return Incomplete Payment Instrument Data or Fail Capture Context Requests
 | EPS-43512

Description
Occasionally, merchants experience issues after upgrading to certain SDK versions. These issues include payment instrument requests that might return incomplete data, and capture context requests that might fail with a JSON parsing error instead of returning a capture context.
Audience
Some merchants using the .NET or .NET Standard SDK.
Technical Details
In
CyberSource.Rest.Client.NetStandard v0.0.1.56
 and later, payment instrument requests might return null values for count, total, and state data. In
CyberSource.Rest.Client v1.0.1
 and later, capture context requests might fail before returning a response.
Workaround
For payment instrument requests, count values can be derived by counting the returned payment instruments. For capture context requests, remaining on
CyberSource.Rest.Client v1.0.0
 avoids the issue.

Customer Invoicing Webhook Events Are Not Always Dispatched for Invoice Lifecycle Events
 | EPS-43859

Description
Some merchants using customer invoicing webhooks do not receive webhook notifications for invoice lifecycle events such as invoice creation, sending, payment, or cancellation. Webhook subscriptions remain active and configured correctly, but webhook events are not dispatched for affected invoices.
Audience
Some merchants using Customer Invoicing webhooks.
Technical Details
Invoice lifecycle events are not always generated for webhook processing, which prevents customer invoicing webhook notifications from being dispatched.
Workaround
No known workaround.

Invoice Webhook Notifications Are Not Always Delivered After Successful Payment Processing
 | EPS-44411

Description
Some merchants using Invoice Webhooks do not receive webhook notifications after invoice payments are processed successfully. Webhook subscriptions remain active and health checks succeed, but payment-completion notifications are not delivered.
Audience
Some merchants using Invoice Webhooks.
Technical Details
Some Invoice-payment events are not generated for webhook delivery processing even though payment processing completes successfully.
Workaround
This issue has been resolved per the "Fixed Issues" entry RM-49120.

Invoice Receipts Display an Incorrect Payment Solution
 | EPS-44461

Description
Some merchants find that invoice receipts display Apple Pay as the payment solution even when Apple Pay was not used to complete the transaction.
Audience
Some merchants using Invoices.
Technical Details
Certain card-brand values can be incorrectly interpreted as payment-solution values when invoice receipts are generated. As a result, some transactions can be displayed as Apple Pay even when a different payment method was used.
Workaround
No known workaround.