On This Page

Known Issues

Blank Batch Response Files for Batch Upload
| EPS-43394

Description: Some merchants submitting stand-alone credits through Batch Upload might receive a blank response file even when the transaction processes successfully.

Audience: Merchants using Batch Upload through Payments 2.0 processing flows, including affected Fiserv merchants.

Technical Details: For affected Batch Upload transactions, transaction batch identifiers are not populated during processing through the Payments 2.0 REST/Kafka ingestion channel. As a result, the batch reporting process cannot associate transactions with the submitted batch and returns a blank response file. Transaction processing itself is not affected and successful transactions can continue to be processed normally.

Description: Some customers using Unified Checkout Click to Pay (CtP) with Passkey authentication might receive an indication that cardholder authentication was unsuccessful even when authentication has completed successfully.

Audience: Merchants and integrators using Unified Checkout Click to Pay (CtP) through the UI.

Technical Details: For impacted transactions, the response might return
cardholderAuthenticationStatus
=
false
even though valid authentication data such as CAVV and XID values is present.

Workaround: To determine whether additional 3-D Secure authentication is required, merchants validate the presence of authentication data returned in the Click to Pay payload, including returned 3-D Secure values such as CAVV and XID.

Description: Some transactions might be rejected even though the associated risk profile configuration is not visible in the Business Center, making it difficult for affected acquirers to determine the source of the rejection or identify the merchants assigned to the profile.

Technical Details: Impacted transactions might be rejected with the error message
Your aggregator or acquirer is not accepting this transaction - CARD_CATEGORY_ECI_REFUSED
, triggered by a
off_us_domestic_credit
configuration. In affected cases, the risk profile containing the rule is not displayed in Business Center, preventing users from viewing the configuration or determining which merchant IDs (MIDs) are assigned to the profile.

Description: When a Unified Checkout transaction includes a customer's IP address, Decision Manager does not consider the IP address during evaluation.
Audience: Some merchants using Unified Checkout with Decision Manager.
Technical Details: Some transactions might bypass Decision Manager rules that rely on the customer's IP address because the
deviceInformation.ipAddress
value is not included in risk evaluation. No API error is returned, and non-IP-based Decision Manager rules continue to function normally.
Workaround: No known workaround.