Known Issues

Applications using sign-only message security cannot submit Simple Order API requests after upgrading the .NET SOAP SDK from version 1.4.10 to version 1.4.11. Affected requests fail with an identity-check error before they are sent.

Some merchants using version 1.4.11 of the .NET SOAP SDK for the Simple Order API with sign-only message security.

Version 1.4.11 incorrectly applies an identity-verification check to sign-only connections. As a result, the SDK can throw

System.ServiceModel.Security.MessageSecurityException

with an

Identity check failed for outgoing message

message before submitting the request.

Continue using version 1.4.10 of the .NET SOAP SDK until a corrected version is available.

Some transactions appear in Transaction Search, but their Transaction Details pages display

Unable to Load Transaction Data

. The transaction data remains available in the underlying system.

Some

Cybersource

users viewing transactions with unusually large linked transaction histories.

The Transaction Details page can time out while retrieving and assembling a transaction history containing an exceptionally large number of related attempts. This issue does not indicate that the transaction data is missing.

Use Transaction Search to view the available transaction summary. Contact Customer Support if the complete transaction history is required.

Some successful payment authorizations can return an HTTP

500

response with

SYSTEM_ERROR

. The authorization might still appear as successful in Transaction Management.

Some merchants submitting payment authorization requests through the REST API.

This issue occurs when the authorization succeeds but the returned decision code is not recognized during API response transformation. The successful backend result is then replaced with a system-error response.

Before retrying an affected authorization, use Transaction Management or the Transaction Search API to verify whether the original request succeeded.

Some UnionPay Payer Authentication configuration updates can appear successful after an earlier update was rejected. A subsequent attempt can report that no changes were submitted even though the configuration was not accepted by the authentication service.

Some merchants configuring UnionPay Payer Authentication through Business Center or the Payer Authentication configuration API.

When an update to the default-currency configuration is rejected, the submitted acquirer information can still be stored in the local Payer Authentication profile. Retrying the same update can then return a successful

No changes in request

response without resubmitting the configuration for validation.

No known workaround.

Some eCheck transactions processed through Unified Checkout can contain an incorrect billing state when billing-address collection is disabled. For affected US addresses, Unified Checkout can replace the submitted state with

AL

.

Some US merchants accepting eCheck payments through Unified Checkout.

This issue occurs when Billing Address is disabled and the capture mandate does not require billing-address collection. Under these conditions, the submitted value in

orderInformation.billTo.administrativeArea

might not be preserved.

In

Cybersource

, enable

Billing Address

under

Payment Configuration > Unified Checkout > Customer Information and Payment Flow

, and select

Zip only

or

Full address

.

Some authorization requests can be declined when a Payer Authentication outage occurs and another Strong Customer Authentication (SCA) exemption is already present. Affected requests return reason code

102

and indicate that only one SCA exemption can be submitted per authorization.

Some merchants using Payer Authentication and SCA exemptions in Europe.

During some directory-server outages, the Payer Authentication response can add an outage exemption without recognizing an existing exemption. The authorization request is then declined because it contains more than one SCA exemption.

No known workaround.

Some Processor Events Detail Reports display multiple processor events as comma-separated values in a single report row. The underlying event records and amounts remain correct.

Some merchants using Processor Events Detail Reports.

This issue occurs when a transaction has more than one processor event in the selected report period. The report combines the events into one row instead of displaying each event separately.

No known workaround.

Some merchants submitting custom reconciliation references for PayPal order, capture, or session requests receive system-generated references instead. As a result, merchants might be unable to use their submitted values to reconcile affected PayPal transactions.

Some merchants using PayPal through alternative payments and submitting custom reconciliation references.

Values submitted in

processingInformation.reconciliationId

or

orderInformation.invoiceDetails.invoiceNumber

are not included in affected PayPal order, capture, and session requests. PayPal refund requests preserve the submitted reference correctly.

No known workaround.

Some merchants using hybrid Payer Authentication receive an authentication failure when validating successful 3-D Secure authentication results. Affected requests return reason code

479

and the message

Unable to validate response access token.

Some merchants using hybrid Payer Authentication in Europe.

The affected validation flow does not recognize the JSON Web Token (JWT) issuer used for some migrated Payer Authentication sessions. As a result, a successful authentication result can fail validation when

responseAccessToken

is submitted.

No known workaround.

Some newly onboarded merchants cannot enable 3-D Secure Payer Authentication through

Cybersource

or API Onboarding. Activation fails and can incorrectly indicate that the merchant has already been created.

Some newly onboarded merchants enabling 3-D Secure Payer Authentication through

Cybersource

or API Onboarding.

A newly created Payer Authentication profile might not be available when the system immediately attempts to use it as the merchant's default profile. The activation request then fails even though the new profile was created successfully.

Contact Customer Support to complete Payer Authentication profile generation and synchronization for the affected merchant.

Some Mastercard e-commerce transactions using 3-D Secure authentication are incorrectly classified as manually entered transactions and rejected during clearing.

Some merchants processing Mastercard e-commerce transactions through an affected processing connection in the US.

Affected sale and credit authorization messages do not include the required e-commerce classification and authentication information in ISO Field 63. As a result, transactions can receive Mastercard International Payment Management rejection code

8679

during clearing even when authorization completes successfully.

No known workaround.