Release Notes {#rn-general} =========================== These release notes cover all releases to the production server for the week ending September 18, 2026. Announcements {#rn-announce} ============================ These announcements are for September 18, 2026. SOAP Toolkit 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 the [*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 a.m. UTC **Production Environment:** `batch.cybersource.com` September 15, 2026, at 4:00 a.m. UTC 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. **Introduced Changes** {#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, user-facing statuses have been added: * 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 URLs 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 changed to BLOCKED, merchants are expected to perform these tasks: 7. Review the affected endpoints. 8. Update the URLs 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 might 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 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. {#webhooks-urls_ul_qnx_jdt_1jc} Secure Acceptance Sunset {#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)](https://support.visaacceptance.com/knowledgebase/Knowledgearticle/?code=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. 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 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 that connect to the REST API endpoints (`apitest.cybersource.com` and `api.cybersource.com`) using 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 that 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 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. Merchants that require IP address allowlists may use one of the options below. **Option 1**: Merchants may 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 may add these generic subnet ranges to IP address allowlists: * `198.241.206.0/24` * `198.241.207.0/24` Transaction Search Performance Update {#trans_search_perform_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 an 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, 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 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 --------------------- Review your search and integration patterns and adhere to the guidance provided in the [*Best Practices for Implementing Searches*](#trans_search_perform_update_best-practices "") section. Best Practices for Implementing Searches {#trans_search_perform_update_best-practices} -------------------------------------------------------------------------------------- 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 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. Features Introduced This Week {#rn-features} ============================================ **Support for `issuerInformation.discretionaryData` on FTT Processor** \| RM-47810 ---------------------------------------------------------------------------------- Description : Cybersource added merchant support for the `issuerInformation.discretionaryData` field when processing transactions through the FTT processor on the CTPV4 Gateway. {#rn-features_dl_vmj_cr1_gke} Mandate : Does not apply. {#rn-features_dl_l5k_cr1_gke} Audience : Merchants processing transactions through the FTT processor on the CTPV4 Gateway. Technical Details : * **Feature:** Support for `issuerInformation.discretionaryData` * **Products:** FTT processor, CTPV4 Gateway * **Tech Details:** Added support for the `issuerInformation.discretionaryData` field when processing transactions through FTT processor connections. This feature is now supported in this locale: * Latin America and Caribbean (LAC) Important Dates : Released on September 15, 2026. {#rn-features_dl_wmj_cr1_gke} Fixed Issues {#rn-fixed-issues} =============================== **Business Center Session Handling Improvements for SSO Merchant Switching and OTP Login \| RM-47464** ------------------------------------------------------------------------------------------------------ Description : Two Business Center session-handling issues have been resolved: * Users using Single Sign-On (SSO) merchant switching can now successfully return to Portfolio Management after selecting Exit View. Previously, users could be returned to the previously selected merchant account immediately after exiting the switched session. * Users authenticating with one-time password (OTP) no longer experience intermittent login failures that require a second authentication attempt. Previously, some users were redirected to the sign-on page after successfully entering a valid OTP. Audience : Business Center users. Technical Details : * The fix introduces a one-time cookie that prevents the previous organization context from being reapplied following a successful switch-back operation. * A stale local storage value was not being cleared during session initialization. As a result, the application bootstrap process incorrectly treated newly authenticated OTP sessions as invalid and removed them. The fix clears the stale flag during session cleanup and adds safeguards to ensure the application initializes successfully. Important Dates : Released on September 16, 2026. **ECP Transactions Now Return the Correct Response Code and Message for Smartpay Code 772** \| RM-47510 ------------------------------------------------------------------------------------------------------- Description : A defect was resolved that caused Electronic Check Processing (ECP) transactions processed through Smartpay to return an incorrect Cybersource response when the processor returned code `772`. Previously, Cybersource mapped the processor response to code `150`, resulting in the message *Unknown error* . Cybersource now correctly maps the response to code `231` with the message *Reason: Invalid DFI account number*. Audience : Merchants processing ECP transactions through the Smartpay processor. Technical Details : * **Processor Response Code:** `772` * **Previous Cybersource Response Code:** `150` * **Message:** *Unknown error*. * **Updated Cybersource Response Code:** `231` * **Message:** *Reason: Invalid DFI account number*. Important Dates : Released on September 16, 2026. Known Issues {#rn-known-issues} =============================== **Transaction History Might Not Display in Alternative Payments** \| EPS-42339 ------------------------------------------------------------------------------ Description : When merchants view the details of an authorization or captured payment transaction for Alternative Payments, the transaction history might not display any related credits that have been processed against the transaction. Additionally, the transaction history displays only the related capture and does not show associated transactions. Audience : Merchants who use Alternative Payments. Technical Details : None. Workaround : Use an alternative transaction identifier, such as the Merchant Reference Number (MRN), to find related transactions. **BIN Data Unavailable for Follow-On Transactions in Business Center Reporting** \| EPS-42464 --------------------------------------------------------------------------------------------- Description : Merchants are unable to view Bank Identification Number (BIN) data for follow-on transactions in Business Center Reports. In the Transaction Request Report (TRR) and Payment Batch Detail Report (PBDR), BIN data is not displayed for settlements, credits, and other follow-on transactions. Audience : Merchants who reference BIN number data in Business Center reports. Technical Details : Follow-on transactions do not store or carry card number information. As a result, BIN data is unavailable for these transactions. Workaround : No known workaround. **Some Account Updater Batches Remain in Processing State** \| EPS-42645 ------------------------------------------------------------------------ Description : For merchants using Account Updater, some batches submitted on August 20, 2026, might remain in a **Processing** state and not complete automatically. As a result, batch results might be delayed until someone manually intervenes. Audience : Merchants who use Account Updater. Technical Details : None. Workaround : No known workaround. **Transaction Search REST API Returns Empty `installmentInformation` Field** \| EPS-42700 ----------------------------------------------------------------------------------------- Description : When merchants use the Transaction Search REST API, the `installmentInformation` field is returned as empty, even when installment data exists for the transaction. As a result, merchants cannot retrieve installment information through Transaction Search. Audience : Merchants who use the Transaction Search REST API. Technical Details : The data source referenced by the Transaction Search REST API does not capture installment information. As a result, the `installmentInformation` field is always returned as empty. A change to the underlying data source is required in order to make this data available. Workaround : Use the Transaction Details REST API, which correctly returns `installmentInformation` data. **Incorrect Merchant Country in Checkout Sessions Might Affect Apple Pay Availability** \| EPS-42780 ---------------------------------------------------------------------------------------------------- Description : When a merchant uses Invoicing or Pay By Link with Unified Checkout, the checkout session is generated with the merchant country set to `US`, even when the merchant is located in another country. As a result, non-US merchants might experience missing or unavailable Apple Pay payment options during checkout. Audience : Non-US merchants who use Invoicing or Pay By Link with Unified Checkout. Technical Details : The Unified Checkout Capture Context generated through Invoicing or PayByLink always populates the merchant country as `US`. Workaround : Use a direct Unified Checkout (UC) or Flex session integration that supplies the correct merchant country when generating the session, rather than relying on the Invoicing or Pay By Link Capture Context generation path. **Acceptance Device List Cannot Be Exported to CSV** \| EPS-42803 ----------------------------------------------------------------- Description : When attempting to export the list of Acceptance Devices to a CSV file, merchants receive the error message *Error: CSV not available* and the export does not complete. Audience : Merchants that use Acceptance Devices. Technical Details : A front-end JavaScript issue prevents the CSV export from being generated successfully. Workaround : No known workaround. **Intermittent Tap-to-Phone Payments Might Fail Before Reaching Transaction Processing Systems** \| EPS-42847 ------------------------------------------------------------------------------------------------------------- Description : Some merchants located within the Democratic Republic of the Congo might experience intermittent Tap-to-Phone payment failures on their production Acceptance device fleets. Affected payments terminate before reaching Cybersource, the acquirer, or the issuer. As a result, the transaction is not processed and does not appear in Business Center for investigation or reconciliation. Audience : Merchants operating in the Democratic Republic of the Congo. Technical Details : None. Workaround : No known workaround. **Report Downloads API Returns Error When Using REST Client Java SDK v0.0.91 with P12 Certificates** \| EPS-43139 ----------------------------------------------------------------------------------------------------------------- Description : Merchants using JWT authentication with the `/reporting/v3/report-downloads GET` endpoint might receive a `401 UNAUTHORIZED_USER` response when using the REST Client Java SDK v0.0.91 with a P12 certificate. As a result, report downloads cannot be retrieved through the API. Audience : Merchants who upgrade to or use the REST Client Java SDK v0.0.91. Technical Details : The issue occurs when using JWT authentication with the `/reporting/v3/report-downloads GET` endpoint in the REST Client Java SDK v0.0.91 and a P12 certificate. Workaround : Revert to a previous version of the REST Client Java SDK. A fix is planned for a future release.