Known Issues

When a customer or merchant sending an API payment transaction incorrectly sets the

card_type

field to a value of

JCB

when the card is Visa or Mastercard, our system identifies the correct card type and sends the transaction correctly to its destination. However, the transaction is incorrectly stored in our system as a JCB card. This defect creates these issues:

The batching and settlement of the transaction treats it as a JCB transaction, causing clearing issues at the acquirer’s end.
Reporting and transaction search results display the transaction as JCB.

Merchants who use our API on Visa Platform Connect.

None.

If you are using the

card_type

field in your API transaction payload, consider adding a validation on your end to catch and correct incorrect customer input.

Credit authorization transactions processed through the SmartPay processor using the Japanese Yen (JPY), with a transaction amount less than 6,500 JPY, are erroneously processed.

Merchants who send credit authorization transactions through SmartPay using the JPY currency.

None.

None.

When a merchant who uses Cielo as a processor sends an authorization transaction during a time when Cielo has high traffic, our system processes it as a timeout and returns an ESYSTEM error to the merchant's system. However, if the transaction later goes through on the Cielo end, they send back a success message that our system ignores because in our system, the transaction is logged as a timeout. If the merchant sends a second message before the Cielo response and it succeeds, the customer might see two pending authorizations in their bank account. However, one of the authorizations will not go through, and the customer will be charged only once.

Merchants that use Cielo as a processor.

None.

None.

The validation performed against the email address entered in the Recurring Billing portal in the Business Center differs from the Virtual Terminal and our APIs. Email addresses with the format

<string>@<string>.<string>-<string>.com

will not be allowed in the Recurring Billing form.

Recurring Billing users.

None.

None.

A defect was discovered that happens when a Payer Authentication Enroll request is sent by a merchant whose account configuration contains an incorrect country code value. The resulting error code is a generic

ESYSTEM

code instead of a more meaningful code that indicates the problem.

Users of Payer Authentication.

None.

Call Customer Support to have your configuration updated to include the correct merchant country code.

A defect was discovered that causes custom reports in the Business Center to fail when the time zone is set to

Asia/Rangoon

.

Merchants who create custom reports in the Business Center.

None.

Choose a different time zone.

A defect was discovered that affects merchants who are payment aggregators and use Amex Direct as their payment processor. When these merchants submit the Merchant Category Code (MCC) through the API, the code does not take precedent over the code that is already stored in their merchant configuration, which could lead to transaction failures.

Merchants processing aggregator transactions on Amex Direct and send the MCC in API requests.

None.

None.

Users who submit Electronic Check Debit requests through Payer Authentication may encounter an error message stating

The following request field is either invalid or missing: IPAddress

. This issue arises when an IPV6 address, which is a 39-character string, is passed into the

deviceInformation

field using the REST API.

Users of Payer Authentication and Electronic Check Debit.

The Cardinal gateway is designed to accept an IP address with a maximum length of 20 characters.

Use an IPV4 address.

Clicking the Pay button multiple times when using Pay By Link can result in multiple charges.

Users of Pay By Link.

None.

None.

The REST API field

merchantInformation.merchantDescriptor.alternateName

is inconsistently validated for some payment services by our servers. This can lead to incorrect information being accepted as successful.

Users of the REST API.

None.