Payment failure alert

A customer can pay for an order by using different payment methods such as credit card, store value card. A credit card must be checked for fraudulent activity and funds availability by a payment system. Similarly, store value cards must be checked for availability of funds. When an order fails payment validation, it is placed on hold and an alert is raised so that the users can take appropriate actions to resolve the alert and process the order.

Solution

The following section describes APIs, user exits, services, and other components.

Credit Card

For a credit card to be validated as a payment method, you must implement the YFSCollectionCreditCardUE user exit. It takes its input from the processOrderPayment API. From that input, XML data is created, and passed to a java class, which in turn calls the YCD_ExecuteCollectionCreditCard_Proxy_1.0 service, a pointer to the YCD_ExecuteCollectionCreditCard_1.0 service, which is responsible for integrating with the external payment system.

If the payment method fails the validation, the value of the ResponseCode attribute that is returned by the user exit determines how to handle the order. If the payment processing fails for any reason, the COLLECTION_FAILED event is raised by the YFSCollectionCreditCardUE user exit. The event calls the YCDOnCollectionFailure action, which invokes the YCD_ProcessCollectionFailure_1.0 service, responsible for calling the appropriate alert service depending on the ResponseCode.

The YCD_ProcessCollectionFailure_1.0 Service — Figure 1. Process collection failure service

APPROVED - This response code is returned if the authorization or charge was successful.
HARD_DECLINE - This response code is returned if the authorization or charge fails because the card is invalid. For example, a lost or stolen credit card. In this case, the order's strike count is increased by 1. The strike count represents how many times the payment was declined for the order with a HARD_DECLINE response code. The maximum allowed number of strikes is configurable.
If the strike count is higher than the maximum allowed number of strikes, the payment method is marked not to retry authorization, suspended, updated with the failure details, and the YCD_PaymentAuthRetryLimitAlert_1.0 alert service is invoked. The alert is sent to the Payment Auth Retry Limit Reached queue, which is monitored by the Fraud Analyst Group users.
If the strike count is lower than the maximum allowed number of strikes, the payment method is marked not to retry authorization, suspended, updated with the failure details, and the YCD_PaymentHardDeclinedAlert_1.0 alert service is invoked. The alert is sent to the Payment Hard Declined queue, which is monitored by the Fraud Analyst Group users.
Note: The strike limit can be configured in the Channel Applications Manager.

Figure 2. YCD_paymentHardDeclinedAlert_1.0 service
SOFT_DECLINE and BANK_HOLD - This response code is returned if the authorization or charge fails because the card was declined. For example, an invalid CVV number or insufficient funds. The payment method is marked not to retry authorization, suspended, updated with the failure details, and the YCD_PaymentDeclinedAlert_1.0 alert service is invoked. The alert is sent to the Payment Declined queue, which is monitored by the CSR group users.
SERVICE_UNAVAILABLE - This response code returns if the credit card authentication service could not be reached. The payment method is marked as retry charge, is not suspended, not updated with the failure details, and the YCD_PaymentServiceUnavailableAlert_1.0 alert service is invoked. The alert is sent to the Payment Service Unavailable queue, which is monitored by the System Group users.

Store Value Card

To charge stored value cards, you must implement the YFSCollectionStoredValueCardUE user exit. This user exit takes its input from the processOrderPayment API. From that input, XML data is created, and passed to a java class, which in turn calls the YCD_ExecuteCollectionSVC_1.0_Proxy service, a pointer to the YCD_ExecuteCollectionSVC_1.0 service responsible for integrating with the external payment system

If the payment method fails the validation, the value of the ResponseCode attribute that is returned by the user exit determines how the order is handled if the payment method fails the validation

APPROVED - This response code is returned if the store value card was charged successfully.
DECLINED - This response code is returned if the application failed to charge the store value card. The payment method is marked not to retry charge, suspended, updated with the failure details, and the YCD_PaymentDeclinedAlert_1.0 alert service is invoked. The alert is sent to the Payment Declined queue, which is monitored by the CSR group users.
SERVICE_UNAVAILABLE - This response code is returned if the authentication service could not be reached. The payment method is marked as retry charge, is not suspended, not updated with the failure details, and the YCD_PaymentServiceUnavailableAlert_1.0 alert service is invoked. The alert is sent to the Payment Service Unavailable queue, which is monitored by the System Group users.

Implementation

This section describes the rules that you must configure.

You can configure the queue to which payment alerts are sent. For more information about configuring the queues for a payment failure alert, see the Configuring supplied and add-on solutions.

You can define how many strikes an order can receive before an alert is sent to the fraud analyst. For more information about configuring the strike limit, see the Configuring supplied and add-on solutions

End-user impact

A user can view alerts raised due to failed payment validations. The user can resolve these alerts by calling the customers and modifying the payment methods appropriately.