Release Notes {#rn-general} =========================== These release notes cover all releases to the production server for the week ending September 4, 2026. Announcements {#rn-announce} ============================ These announcements are for September 4, 2026. SOAP Tooklit Authentication Update {#soap-p12} ============================================== 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 {#soap-p12_ul_hbm_lwq_zjc} Your API requests to Cybersource will be rejected if you do not implement P12 authentication by the required dates. See [*P12 Authentication Upgrade for SOAP Toolkit Key Users Migration Guide*.](https://developer.cybersource.com/docs/cybs/en-us/so-p12/migration/all/so/so-p12/so-p12-intro.md "") Batch Upload Service IP Address Updates {#ip-addresses} ======================================================= 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 {#webhooks-urls} ================================================================= 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 subscriptions and existing subscriptions currently on file. **What is Changing** {#webhooks-urls_section_dnx_jdt_1jc} --------------------------------------------------------- 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) {#webhooks-urls_ul_enx_jdt_1jc} As part of this enhancement, clients might now see user-facing statuses: * **PENDING_REVIEW** * **BLOCKED** {#webhooks-urls_ul_fnx_jdt_1jc} 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** {#webhooks-urls_section_hnx_jdt_1jc} ------------------------------------------------------------------ 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**. {#webhooks-urls_ol_inx_jdt_1jc} In cases where a subscription status is change to **BLOCKED**, clients are expected to perform these tasks: 7. Review the affected endpoint(s). 8. Update the URL(s) to an acceptable endpoint. 9. Resubmit the subscription for processing. {#webhooks-urls_ul_lnx_jdt_1jc} **For New Subscriptions** {#webhooks-urls_section_mnx_jdt_1jc} -------------------------------------------------------------- New webhook-related URLs may go through validation and, if necessary, security review before the subscription can proceed. **Why We Are Making This Change** {#webhooks-urls_section_pnx_jdt_1jc} ---------------------------------------------------------------------- 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. {#webhooks-urls_ul_qnx_jdt_1jc} Message-Level Encryption Upcoming Mandate {#announcement-mle} ============================================================= 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](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-message-intro/restgs-mle-intro.md "") 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](https://github.com/CyberSource ""). 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 : * See [Construct JWT Messages Using a P12 Certificate](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-message-intro/restgs-jwt-const-intro.md "") in the *Getting Started with REST Developer Guide* * See [Construct JWT Messages Using a Shared Secret Key Pair](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-shared-secret-intro/restgs-jwt-con-shared-secret-intro.md "") in the *Getting Started with REST Developer Guide* 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 : * See [Construct JWT Messages Using a Shared Secret Key Pair](https://developer.cybersource.com/docs/cybs/en-us/platform/developer/all/rest/rest-getting-started/restgs-jwt-shared-secret-intro.md "") in the *Getting Started with REST Developer Guide* {#announcement-mle_ul_mkf_nff_1kc} Network Routing Architecture Update {#network-routing-ip-migration} =================================================================== 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` Secure Acceptance Sunset {#secure-acceptance-sunset} ==================================================== Secure Acceptance is being sunset as part of a move toward modern, 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 off 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)](https://support.visaacceptance.com/knowledgebase/Knowledgearticle/?code=KA-11531 ""). Review your migration plans and take the necessary steps to move off Secure Acceptance before the deadline. If you need assistance, contact your Visa representative. Features Introduced This Week {#rn-features} ============================================ No customer-facing features were released this week. Fixed Issues {#rn-fixed-issues} =============================== No customer-facing fixes were released this week. Known Issues {#rn-known-issues} =============================== **Incorrect Invoicing Status Displayed in UI** \| EPS-41938 ----------------------------------------------------------- Description : In some instances, an issue in the post-payment invoice update process prevents the invoice status from being committed to the database following successful payment authorization and processing. As a result, invoices remain in a Sent status instead of updating to Paid/Completed within the Invoicing UI. Audience : Some merchants in CEMEA. Technical Details : This issue occurs during post-payment invoice status persistence. Under specific conditions, a database deadlock can cause the invoice status update transaction to be rolled back, preventing the updated status from being committed. Workaround : No known workaround. **Incorrect Phone Details on Pay By Link Email Receipts** \| EPS-42410 ---------------------------------------------------------------------- Description : Receipt emails generated for Invoicing and Pay By Link transactions may occasionally display an incorrect merchant phone number. As a result, customers may be presented with inaccurate merchant contact information on receipt communications. Audience : Some invoicing and Pay By Link merchants. Technical Details : While payment pages display the merchant's intended customer contact information, receipt emails may display an incorrect merchant phone number due to the use of an unintended merchant contact record during receipt generation. Workaround : Until a permanent fix is available, merchants can update the phone number associated with their Business Contact to match the customer-facing phone number configured in their merchant profile. This will help ensure consistent contact information is displayed in receipt emails. **Business Center Credit/Refund Action Causing Incorrect Transaction Status** \| EPS-42369 ------------------------------------------------------------------------------------------ Description : In certain cases, transactions that successfully complete a void operation after an initial timeout may not be accurately reflected in the transaction status. This issue may cause refund actions to be unavailable in the Transaction Details page, preventing merchants from initiating a refund through the user interface. Audience : Some merchants and cardholders attempting void requests. Technical Details : A transaction status synchronization issue may occur when a void request encounters a communication timeout during processing. As a result, the transaction record may not be updated to reflect its final state in some cases, even when the void is completed successfully. Workaround : If refund options are unavailable for the affected transaction, merchants can issue a standalone credit to return funds to the customer. **Intermittent Token Management Service Failure for Recurring Billing** \| EPS-42500 ------------------------------------------------------------------------------------ Description : Some merchants may experience intermittent failures when setting up recurring billing if a payment method is associated with a legacy Instrument Identifier that was created while nullable Instrument Identifiers were allowed in the TMS (Token Management Service) vault. These failures may occur when the legacy Instrument Identifier does not contain the card details required by the current vault configuration. Audience : Merchants with legacy Instrument Identifiers created while nullable Instrument Identifiers were allowed in TMS. Technical Details : None. Workaround : No known workaround. **Invoicing Payment Receipts Sent to Business Contact Instead of Configured Email Address** \| EPS-42538 -------------------------------------------------------------------------------------------------------- Description : Merchants can configure Invoicing to send payment receipts to an alternative email address. However, payment receipts are currently sent to the business contact associated with the merchant account, even when an alternative recipient email is configured. Audience : Merchants using Invoicing who have configured payment receipts to be sent to an alternative email address. Technical Details : None. Workaround : No known workaround.