Credit card

Credit cards must be validated for fraudulent activity and availability of funds. The application must verify credit cards and authorize the payments.

Solution

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

The application enables the user to validate a credit card payment method by using a payment validation system that is compliant with the PA-DSS.

During order creation, when a user is adding or modifying a credit card payment method, the application verifies whether the value of the token property is Y, if the value is Y, the createAccessToken API is called to generate an authentication token, which in turn is passed to the payment validation system.

The month list is populated by using the common code, YCD_MONTH, which is cached.

The card type list is populated by using the YCD_CREDIT_CARD_TYPE or YCD_PAYMENT_SUBTYPE common code.

The name on the card is defaulted with the first name and last name present in the "Bill to" address.

A mashup is used to display the expiration year list. The expiration range is five years starting with the current calendar year.

The expiration month and year are concatenated together to form the credit card expiration date.

In order to setup encryption for credit card name and expiration date, you must implement the logic for payment encryption and enable the "Encrypt Credit Card Name and Expiration Date" rule in the Sterling™ Business Center. The application displays asterisks in place of the characters in the credit card name and expiration date fields.

When the user enters the credit card number and tabs out of the field, the credit card number is automatically passed to the payment validation system, which in turn validates the credit card.
  • If validation succeeds, it returns a generated credit card token, a display number, and a credit card type to the application. The display number is shown instead of the credit card number.
  • If the card type returned by the payment validation system is not the credit card type that was selected by the user, the Card Type field is updated to reflect the credit card type that is returned by the payment validation system. If the credit card validation fails, an appropriate error message is displayed, indicating that the credit card number is invalid. The error message can be customized through the payment validation system.
When the user chooses to capture credit card information, the system verifies whether real-time authorization is enabled.
  • If the real-time authorization is disabled, the credit card information is collected and the order is confirmed. The payment agents execute and authorize the payment method, before processing the order.
  • If the real-time authorization is enabled, the user is allowed to capture the CVV number of the credit card. This number is a secure credit card verification value. As it is confidential, the number is not recorded within any logs and is never saved against the payment method on the order. The CVV number is stored in the local screen memory. When the user confirms the payments for the order, the number is passed in the SecureAuthenticationCode attribute to the processOrderPayment API.

    The SecureAuthenticationCode attribute can be hidden in the logs by changing the default layout filter in the logfilter.properties_ycd_ext file as follows: filterset.paymentFilter.includes = com_layout.

    The logfilter.properties_ycd_ext is located in the <INSTALL_CIR>/properties directory.

If the credit card fails validation, an alert is raised and sent to the appropriate queue. For more information, see "Payment failure alert".

To validate the credit card payment method, you must implement the YFSCollectionCreditCardUE user exit. The user exit receives inputs from the processOrderPayment API. From that input, the following XML data is created. 
<Payment AuthorizationId="" bPreviouslyInvoked="" ChargeTransactionKey=""
CreditCardExpirationDate="" CreditCardName="" CreditCardNo="" CreditCardType=""
Currency="" EnterpriseCode="" MerchantId="" OrderHeaderKey="" OrderNo=""
PaymentType="" RequestAmount="" ...>

Here ''...'' refers to the additional attributes that can be passed in the XML. These attributes can be either extended attributes or attributes that are defined in the Javadoc. For more information about extra attributes that can be defined, refer to the Javadoc.

This XML data is 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 that is responsible for integrating with the external payment system.

You must create your own custom service to handle the integration with the external payment system, and modify the YCD_ExecuteCollectionCreditCard_Proxy_1.0 service to point to your service.

The expected output of the YCD_ExecuteCollectionCreditCard_Proxy_1.0 service is as follows:
<Payment ResponseCode="" AsynchRequestProcess="" AuthAVS="" AuthCode=""
AuthorizationAmount="" AuthorizationExpirationDate="" AuthorizationId=""
AuthReturnCode="" AuthReturnFlag="" AuthReturnMessage="" AuthTime=""
BPreviousInvocationSuccessful="" CollectionDate="" DisplayPaymentReference1=""
HoldOrderAndRaiseEvent="" HoldReason="" InternalReturnCode=""
InternalReturnFlag="" InternalReturnMessage="" PaymentReference1=""
PaymentReference2="" PaymentReference3="" RequestID="" RetryFlag=""
SCVVAuthCode="" SuspendPayment="" TranAmount="" TranRequestTime=""
TranReturnCode="" TranReturnFlag="" TranReturnMessage="" TranType=""/>
The value of the ResponseCode attribute determines how to handle the order.

Implementation

The following section describes the rules that you must configure.

Configure the following rules appropriately.
  • Use A Single Field To Enter The Name On The Credit Card In The User Interface: The rule allows the use single or multiple fields for credit card name on the user interface at the time of capturing payment information. You can configure this rule at the enterprise level. When the user captures the details of a credit card, the screen behaves based on the configuration of this rule for the seller organization.
  • Authorize Credit Cards In Real Time for Draft Orders: The rule allows the user to authorize payments for an order in real time
  • Payment Types and Payment Card Types.
  • Encrypt Credit Card Name and Expiration Date.

For more information about APIs and user exits, see the Javadoc.

End-user impact

The user can ensure authorized payments through credit cards during order confirmation.