On This Page

Known Issues

Validation and Capture Requests Return an Unexpected Response for CVN Soft Declines
| EPS-43280

Description: Some merchants using the Payments API receive an unexpected response when a combined validation and capture request encounters a card verification number (CVN) soft-decline condition. Instead of receiving the expected review status, the request returns a response indicating a CVN failure even though the transaction is authorized.

Technical Details: Combined validation and capture requests submitted to
POST /pts/v2/payments
can return
CV_FAILED
for certain CVN soft-decline scenarios. Affected transactions can be authorized successfully while returning an unexpected response status.

Description: Some merchants using Stand-Alone Credit through Batch Upload receive incomplete processing information when batch uploads fail. Request IDs might not be searchable in the Business Center, Token IDs might not be displayed for affected transactions, and OLP (Offline Processing) batch response files might be blank.
Audience: Some merchants using Stand-Alone Credit through Batch Upload.
Technical Details: Failed batch uploads can return the error message
invalidField_0=recurringSubscriptionInfo_subscriptionID
.
Workaround: No known workaround.

Description: Occasionally, merchants experience issues after upgrading to certain SDK versions. These issues include payment instrument requests that might return incomplete data, and capture context requests that might fail with a JSON parsing error instead of returning a capture context.

Technical Details: In
CyberSource.Rest.Client.NetStandard v0.0.1.56
and later, payment instrument requests might return null values for count, total, and state data. In
CyberSource.Rest.Client v1.0.1
and later, capture context requests might fail before returning a response.

Workaround: For payment instrument requests, count values can be derived by counting the returned payment instruments. For capture context requests, remaining on
CyberSource.Rest.Client v1.0.0
avoids the issue.

Description: Some merchants using customer invoicing webhooks do not receive webhook notifications for invoice lifecycle events such as invoice creation, sending, payment, or cancellation. Webhook subscriptions remain active and configured correctly, but webhook events are not dispatched for affected invoices.

Technical Details: Invoice lifecycle events are not always generated for webhook processing, which prevents customer invoicing webhook notifications from being dispatched.

Description: Some merchants using Invoice Webhooks do not receive webhook notifications after invoice payments are processed successfully. Webhook subscriptions remain active and health checks succeed, but payment-completion notifications are not delivered.
Audience: Some merchants using Invoice Webhooks.
Technical Details: Some Invoice-payment events are not generated for webhook delivery processing even though payment processing completes successfully.
Workaround: This issue has been resolved per the "Fixed Issues" entry RM-49120.

Description: Some merchants find that invoice receipts display Apple Pay as the payment solution even when Apple Pay was not used to complete the transaction.

Technical Details: Certain card-brand values can be incorrectly interpreted as payment-solution values when invoice receipts are generated. As a result, some transactions can be displayed as Apple Pay even when a different payment method was used.