Release Notes {#rn-general} =========================== These release notes cover all releases to the production server for the week ending August 14, 2026. Announcements {#rn-announce} ============================ These announcements are for August 14, 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 "") 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 newly submitted 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. This 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 the following 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: * Review the affected endpoint(s). * Update the URL(s) to an acceptable endpoint. * 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} Features Introduced This Week {#rn-features} ============================================ **Message-Level Encryption Support for TSS Endpoints** \| RM-46978 ------------------------------------------------------------------ Description : Cybersource now supports optional message-level encryption (MLE) for selected Transaction Search Service (TSS) endpoints. Merchants enabled for MLE can receive encrypted response payloads from the affected TSS APIs. Merchants not using MLE can continue to use these endpoints without any changes to their integration. Mandate : Does not apply. Audience : Merchants who are enabled for MLE and use the TSS APIs. Benefit : Merchants can adopt encrypted message handling for TSS API responses based on their security requirements, with no impact to existing non-MLE integrations. Technical Details : These TSS endpoints now support optional MLE for response payloads: * `GET /tss/v2/transactions/{id}/general` * `GET /tss/v2/transactions/{search-id}` * `GET /tss/v2/transactions/{id}` * `POST /tss/v2/searches` Existing request and response behavior remains unchanged for merchants who are not configured for MLE. Important Dates : Released on August 11, 2026. **Unified Checkout Locale and Payment Enhancements** \| RM-47302 ---------------------------------------------------------------- Description : Unified Checkout now supports additional Latin America and Caribbean locales, gives merchants more control over which payment types display during checkout, supports a capture-only transaction mode, adds support for Unified Click to Pay (UCTP) v0.10 and Mastercard FIDO/Passkey authentication, and adds support for PayPal vaulting. {#rn-features_dl_vmj_cr1_gkc} Mandate : Does not apply. {#rn-features_dl_l5k_cr1_gkc} Technical Details : * **Unified Checkout supports additional locales** * **Products:** Unified Checkout, Click to Pay Drop-in UI * **Tech Details:** Unified Checkout supports these additional locales: * es-CR (Costa Rica) * es-DO (Dominican Republic) * es-GT (Guatemala) * es-PA (Panama) * es-PY (Paraguay) {#rn-features_ul_zmj_cr1_gkc} {#rn-features_ul_ymj_cr1_gkc} * **PayPal vaulting** * **Products:** Unified Checkout * **Tech Details:** Support for PayPal vaulting enables merchants to securely store customer PayPal payment credentials for future transactions, supporting recurring payments and streamlined repeat purchases. {#rn-features_ul_anj_cr1_gkc} * **FIDO/passkey support** * **Products:** Unified Click to Pay (UCTP) * **Tech Details:** Support for UCTP v0.10 and Mastercard FIDO/Passkey authentication. Eligible Mastercard Click to Pay cardholders can authenticate using a registered passkey, such as Face ID or fingerprint recognition, enabling a faster, more seamless checkout experience with enhanced security. {#rn-features_ul_bnj_cr1_gkc} * **Allowed payment methods in checkout SDK** * **Products:** Unified Checkout * **Tech Details:** Enables the multi-integration model where different parts of the page own different payment methods. For example, supporting checkout for Apple Pay or Google Pay in the same Unified Checkout session request while loading components for card and Click to Pay payment methods. {#rn-features_ul_cnj_cr1_gkc} * **Additional complete mandate function to fully suppress complete mandate** * **Products:** Unified Checkout * **Tech Details:** Support for completeMandate.suppress set to `true` or `false`, which lets merchants fully suppress the complete mandate step where it is not required and offer a capture-only transaction mode. {#rn-features_ul_dnj_cr1_gkc} {#rn-features_ul_xmj_cr1_gkc} Important Dates : Released on August 13, 2026. {#rn-features_dl_wmj_cr1_gkc} Fixed Issues {#rn-fixed-issues} =============================== No customer-facing fixes were released this week. Known Issues {#rn-known-issues} =============================== There are no known issues this week.