Release Notes {#rn-general} =========================== These release notes cover all releases to the production server for the week ending October 2, 2026. Announcements {#rn-announce} ============================ These announcements are for October 2, 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} Message-Level Encryption Upcoming Mandate {#announcement-mle} ============================================================= An updated version of message-level encryption (MLE) will become required 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](#announcement-mle_http-messaging-migration "") section. * 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) 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 {#announcement-mle_http-messaging-migration} -------------------------------------------------------------------------------------- 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 : * 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 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` 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. 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} ============================================ **Estimated and Incremental Authorization Support for Eligible Processing Connections** \| RM-47041 --------------------------------------------------------------------------------------------------- Description : Cybersource now supports estimated authorizations and incremental authorizations for the FDI Global processor, enabling merchants to obtain an initial authorization for an estimated amount and increase the authorized amount when additional charges are incurred. This enhancement supports lodging, vehicle rental, cruise, healthcare, and other variable-spend industries where the final transaction amount is not known at the time of authorization. Merchants can also maintain a single authorization lifecycle that aligns with card-brand requirements for estimated and incremental authorization processing. Mandate : Does not apply. Audience : Merchants in North America that process transactions through FDI Global. Technical Details : Merchants can identify an authorization as an estimate using processingInformation.authorizationOptions.authIndicator=0 and can increase a previously approved authorization by submitting an incremental authorization request through `/pts/v2/payments/{id}` or `ccIncrementalAuthService_run=true`. Merchants can submit multiple incremental authorizations against the same original authorization while maintaining transaction linkage throughout the authorization lifecycle. This enhancement supports estimated authorization use cases such as lodging, vehicle rental, cruise, and healthcare transactions and is available for Visa, Mastercard, and Discover transactions. Important Dates : Released on September 30, 2026 **Additional Search Fields Added to the Transaction Search API** \| RM-49264 ---------------------------------------------------------------------------- Description : The Transaction Search API now supports searching for transactions using additional identifiers that enable more precise transaction identification and reconciliation. Merchants can now search using a client transaction ID, airline ticket number, or passenger name. Mandate : Does not apply. Audience : Merchants that use the Transaction Search API and need to identify transactions using a client transaction ID, airline ticket number, or passenger name. Technical Details : The Transaction Search API now supports searching for transactions using the `merchant_transaction_identifier`, airline ticket number, and passenger name fields. These additional search criteria help merchants identify and reconcile individual transactions more accurately when multiple transactions share similar attributes. Important Dates : Released on October 1, 2026 Fixed Issues {#rn-fixed-issues} =============================== **User Registration for Direct Merchant IDs Now Completes Successfully** \| RM-47419 ------------------------------------------------------------------------------------ Description : This release resolves an issue that could prevent user registration for direct merchant IDs that do not have a parent reseller. User registration now completes successfully, and activation emails are sent as expected. Audience : Merchants that use direct merchant IDs without a parent reseller, including legacy direct merchant IDs that have not yet migrated to Visa Acceptance Platform. Technical Details : Previously, user registration requests for direct merchant IDs without a parent reseller failed and did not create a user account. Important Dates : Release on September 30, 2026 **Account Updater Configuration Can Now Be Saved at the Merchant Level** \| RM-48214 ------------------------------------------------------------------------------------ Description : This release resolves an issue that prevented merchants from adding and configuring the Account Updater product at the merchant level in the Business Center. Audience : Portfolios that use the Account Updater product in the Business Center. Technical Details : Previously, the default Account Updater template loaded without configuration values, and merchant-level Account Updater settings were not saved when users selected Apply. Account Updater templates now load the expected configuration values, and merchant-level settings are saved correctly. Important Dates : Released on September 30, 2026 **Business Center Login and Session Management Improvements** \| RM-49264 ------------------------------------------------------------------------- Description : This release resolves several issues that could affect user access and session management in Business Center. Users authenticating with OTP-based multi-factor authentication (MFA) can now successfully sign in on the first attempt when a valid One-Time Password (OTP) is entered. Users whose usernames contain a period (.) can now log in successfully. Additionally, opening a new browser tab no longer affects active sessions in other open Business Center tabs. Audience : Business Center users. Important Dates : Release on September 29, 2026 Known Issues {#rn-known-issues} =============================== **.NET REST Client SDK Methods Might Not Return Unified Checkout Transient Token Data** \| EPS-42309 ---------------------------------------------------------------------------------------------------- Description : Developers using the .NET REST Client SDK might find that payment details are not returned when calling methods that retrieve Unified Checkout transient token transaction data. Although the API request completes successfully, the calling application does not receive the requested billing, shipping, or masked card information. Audience : Developers using the CyberSource .NET REST Client SDK to retrieve payment details associated with Unified Checkout transient tokens. Technical Details : The `TransientTokenDataV2Api.GetTransactionForTransientTokenJTI()` and `TransientTokenDataV2Api.GetTransactionForTransientToken()` methods might not return payment data to the calling application. Workaround : No known workaround. **Authorization Decline Webhooks Might Omit the `submitTimeUtc` Field** \| EPS-42702 ------------------------------------------------------------------------------------ Description : Some merchants might find that authorization decline webhook events do not include the `submitTimeUtc` field. This issue can occur when an authorization request is declined, resulting in webhook payloads that omit the field entirely rather than returning it with a null value. Audience : Merchants that consume authorization decline webhooks through an affected gateway integration. Technical Details : For some declined authorization transactions, the `payload.submitTimeUtc` field might be omitted from the webhook payload. This issue affects `payments.authorization.rejected` and `payments.authorization.status.rejected` events and can occur for declined transactions such as those returned with response code `51` and reason `INSUFFICIENT_FUND`. Workaround : No known workaround. **Apple Pay Transactions Might Fail Due to Payment Data Decryption Errors** \| EPS-42773 ---------------------------------------------------------------------------------------- Description : Some Apple Pay transactions might fail during processing and return a decline response instead of being authorized successfully. This issue occurs during the decryption of Apple Pay payment data, preventing the transaction from being completed. Audience : Merchants that accept Apple Pay payments through affected integrations. Technical Details : Some Apple Pay transactions might fail with reason code `102` and the error message `Unable to decrypt encrypted_payment_data`. In affected transactions, the `publicKeyHash` cannot be validated, resulting in the error `Invalid public key hash` and preventing the Apple Pay payload from being decrypted. Workaround : No known workaround. **American Express Transactions Might Be Declined for Non-US and Non-Canadian Billing Addresses** \| EPS-42788 -------------------------------------------------------------------------------------------------------------- Description : Some merchants might experience declined American Express transactions when customers use billing addresses outside the United States or Canada. Although the billing address contains a valid postal code, the transaction might still be declined during authorization, preventing the customer from completing the purchase. Audience : Merchants processing American Express transactions through an affected processing connection when customer billing addresses are outside the United States or Canada. Technical Details : Some American Express transactions with non-US and non-Canadian billing addresses might be declined with Cybersource reason code `236` and processor response code `19`. Although the billing postal code is present in the transaction data, it might not be included in the required authorization field used during transaction processing. Workaround : No known workaround. **Comment Field in Virtual Terminal Might Still Appear When Disabled** \| EPS-42796 ----------------------------------------------------------------------------------- Description : Some merchants might see the comment field displayed on Virtual Terminal receipts even when the Comment Display feature is disabled. Audience : Merchants using Virtual Terminal that have disabled the Comment Display feature. Workaround : No known workaround. **Unsupported Processor Configuration Might Appear in Business Center Portfolio Management** \| EPS-42942 --------------------------------------------------------------------------------------------------------- Description : Some merchants might see an unsupported processor configuration associated with their Business Center portfolio. This issue can occur when processor settings are updated through internal management processes, resulting in a processor being associated with a portfolio that does not support it. Audience : Some merchants using affected portfolio configurations in Business Center. Workaround : No known workaround. **Editing a Subscription Plan May Trigger Immediate Billing and Reset the Billing Schedule** \| EPS-43012 --------------------------------------------------------------------------------------------------------- Description : When merchants edit an existing subscription and change it to a different plan or tier, the subscription might immediately charge the customer and reset the recurring billing date. As a result, the billing cycle may change unexpectedly, and the customer can be charged sooner than intended. Audience : Merchants using Subscription Management or Recurring Billing that modify an existing subscription by changing its plan or tier. Technical Details : When a subscription is updated with a different plan or tier, the subscription start date may be reset, causing the billing cycle to restart. As a result, an immediate charge might be processed and the recurring billing date recalculated based on the date of the change. Workaround : To adjust pricing without changing the billing schedule, merchants can update only the subscription amount rather than changing the plan or tier. If a plan or tier change is required, merchants can cancel the subscription and create a new one with the billing date. **Payment Requests Using Flex and Unified Checkout Transient Tokens Might Return HTTP 400 Errors** \| EPS-43048 --------------------------------------------------------------------------------------------------------------- Description : Some merchants might receive an HTTP `400` response when submitting `POST /pts/v2/payments` requests using Flex or Unified Checkout transient tokens, even when capture context generation and transient token creation complete successfully. Audience : Merchants without a TMS profile that submit REST API payment requests using Flex or Unified Checkout transient tokens. Technical Details : For some merchants without a TMS profile, payment requests might return HTTP `400` because TMS configuration validation is performed even when no TMS profile is present. As a result, the required profile ID information cannot be populated for the request. Workaround : Contact your account representative to discuss temporary TMS enablement. **Confirmation Step Might Appear When Disabled in Unified Checkout** \| EPS-43205 --------------------------------------------------------------------------------- Description : Some merchants might see the confirmation step briefly appear during checkout even when `showConfirmationStep=false` is configured to skip it. Although the checkout flow continues as expected, the confirmation step might momentarily render before being bypassed. Audience : Merchants using Unified Checkout that have configured checkout to skip the confirmation step. Technical Details : When `showConfirmationStep=false` is configured, the confirmation step might still briefly render before the checkout flow continues. Workaround : No known workaround. **Unified Checkout Webhooks Might Not Be Delivered Due to Documentation Configuration Issues** \| EPS-43340 ----------------------------------------------------------------------------------------------------------- Description : Some merchants might not receive Unified Checkout webhooks after completing webhook configuration. This issue can occur when merchants follow webhook configuration guidance that results in an incorrect Message-Level Encryption (MLE) key configuration, preventing webhook delivery. Audience : Merchants in the European Union that use Unified Checkout webhooks. Technical Details : Some Unified Checkout webhooks might not be delivered when the configured MLE key does not match the values used during webhook delivery. A documentation discrepancy can result in merchants configuring a key with `provider=nrtd` and `tenant=yellhsbc`, while webhook delivery attempts to perform the key lookup using `provider=yellhsbc` and `tenant=nrtd`. Workaround : No known workaround. **Debt Repayment Transactions Might Be Processed as Standard Debit Transactions** \| EPS-43598 ---------------------------------------------------------------------------------------------- Description : Some merchants might find that debt repayment transactions are processed as standard debit transactions even when debt repayment indicators are included in the transaction request. Transactions complete successfully, but the debt repayment designation might not be recognized during transaction processing. Audience : Merchants that process debt repayment transactions through an affected processing connection. Technical Details : Transactions submitted with `merchant_category_code: 6051`, `bill_payment=y`, and `debt_indicator=y` might be processed as standard debit transactions rather than debt repayment transactions. Workaround : No known workaround. **Google Pay Transactions Using Payer Authentication Might Fail with an Invalid XID Error** \| EPS-43618 -------------------------------------------------------------------------------------------------------- Description : Some merchants might be unable to complete Google Pay transactions when using Payer Authentication (3-D Secure). Transactions might fail with an invalid XID error even when a valid XID value is provided. Audience : Merchants that use Google Pay with Payer Authentication (3-D Secure). Technical Details : Some transactions might fail with the error message `The field is invalid: xid` even when the `xid` field contains a populated, correctly formatted value. Workaround : No known workaround.