About card payments

General information about card payments

Pay-Jet Cockpit processes all major cards and currencies worldwide. Card data is protected against unauthorised access by TLS encryption. Additional security functions are integrated fraud prevention and risk management. Our standardized settlement files guarantee a straightforward reconciliation processes in your accounting.

Verified by Visa and MasterCard SecureCode secure your payment claim by password validation if a customer disputes the payment later. American Express SafeKey also uses the 3-D Secure technology, which means that the card holder must confirm their identity with a password.

Transaction processing can be made via Cockpit standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise Cockpit can process transactions from stationary terminals.

Using the card form provides several advantages:

1. Merchants can bypass the costly PCI-security authorisation
2. The programming of 3-D Secure with forms is much easier and quicker than via Server-to-Server connection

Process of 3-D Secure payments

MasterCard SecureCode (UCAF), Verified by Visa (VbV), Diners ProtectBuy, JCB J/Secure and American Express SafeKey are authentication methods which verify the identity of the card holder before making the payment. The name 3-D Secure used by technicians describes only the protocol. The correct brand names are Verified by Visa, MasterCard SecureCode, SafeKey, ProtectBuy and J/Secure.

Merchants benefit from authentication with 3-D Secure because the card schemes provide a liability shift: If you are using Verified by Visa, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or American Express SafeKey, the burdon of proof and thereby generally the liability is shifted from the merchant to the card issuing bank, should the customer dispute the payment. Irrespective of whether the card holder actually uses the authentication you obtain a very high protection against payment defaults / chargebacks in case the customer states they have not authorised the card payment. Your Acquirer will be able to discuss the details of 3-D Secure and the cover that it provides.

From a technical perspective 3-D Secure is not a payment method but an authentication process which precedes the payment: Once the credit card data has been entered, Cockpit checks the identity of the card holder and does not process the payment until after the authentication.

For further steps it is crucial if the credit card connection is made via form interface or via Server-to-Server-connection. In the first case the Pay-Jet Cockpit form assumes the further authentication process, with Server-to-Server-connection the merchant has to manage the authentication through a separate interface.

Notice: Please make sure to review our EMV 3D Secure Specification to integrate according to the newest standards.

Process of a transaction with 3-D Secure via form interface

The customer selects the Credit card payment method in the Internet shop and enters the card number and expiry date. Pay-Jet Cockpit receives the card number and checks, via a connection to Visa, MasterCard, Diners, JCB or American Express, whether this credit card is registered for Verified, SecureCode, Diners ProtectBuy, JCB-Card J/Secure or SafeKey. If the credit card is not registered a credit card payment is carried out with TLS. With that the transaction gets a flag which identifies payments with 3-D Secure. This marking tells the Acquiring Bank that you use the authentication and a secured payment claim is obtained based on the Liability Shift in case the card holder disputes the payment.

If the customer's credit card has been registered by the issuing bank for Verified by Visa, MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or American Express SafeKey the authentication process now starts: Pay-Jet Cockpit opens a new browser window which connects the customer to its bank. In this window the customer enters the password received by its bank.

Process of a transaction with 3-D Secure via Server-to-Server-connection

To carry out authentication, Cockpit connects the card holder to his bank, which confirms the identity. A payment process with Verified by Visa or MasterCard SecureCode, Diners ProtectBuy, JCB-Card J/Secure or American Express SafeKey comprises two steps: authentication and payment.

Following scheme illustrates the processes of a Server-to-Server-payment with 3-D Secure.

In the next phases there are three different cases in which Pay-Jet Cockpit responses differ. The individual connection parameters can be found in the credit card payments section of the handbook.

Case 1: Credit card not registered for 3-D Secure

Pay-Jet Cockpit initially contacts Visa or MasterCard, Diners, JCB or American Express Directory Server to determine whether the purchaser’s credit card is registered for Verified or SecureCode or SafeKey.

Case 2 with Popup: Credit card registered for a 3-D Secure system

IMPORTANT NOTICE: We strongly recommend the use of the iFrame solution since MasterCard has revised the regulations. MasterCard prohibits the use of a popup. For this an excerpt from the regulations (Excerpt from: MasterCard® SecureCode™ Merchant Implementation):

“Inline window implementations, which have proven to virtually eliminate the issues caused by pop-up authentication windows, are required for all new merchant implementations and existing pop-up implementations must convert to inline windows.”

If the credit card is registered for Verified or SecureCode, ProtectBuy, J/Secure or SafeKey, Pay-Jet Cockpit returns the socket-connection HTML source code with a JavaScript function. This JavaScript function creates the connection to the bank with which the customer is authenticated by entering its password into a popup-window. The HTML source code with the JavaScript function Initiate3DSec() which Pay-Jet Cockpit sends to the shop must be embedded in the response page which the shop displays in the customer's browser.

Notice: Please note that the use of a popup window can lead to problems with popup blockers in the customer's browser. Therefore case 3 describes an alternative in the form of an Inframe variant.

The following listing shows a response page in which the HTML code is embedded:

Notice: You can also use this code if you only want to verify the identity of the card holder without making a credit card payment. Our Support team can set your account in a way that Pay-Jet Cockpit can carry out just the authentication with Verified or SecureCode, ProtectBuy, J/Secure or SafeKey without payment (Authentication Hosting).

After the customer has been authenticated with its bank, the bank's Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters via GET (QueryString) to the TermURL of the shop: MID, PayID and TransID. The PARes parameter is transferred via POST.

Notice: The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.

The parameter must be transferred in whole via POST to the following URL:

Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.

Case 3 without Popup: Credit card registered for a 3-D Secure system

Alternatively to the popup window the card holder can also carry out authentication with the bank in an iFrame variant; this avoids difficulties with popup blockers in the customer's browser. Provided the card is registered on the Directory Server, Pay-Jet Cockpit returns the following parameters via the socket connection.

Response parameters of Socket-connection for the Authentication Request

Example for correct processing of ACSURL and TermURL:

acsurl=a?b=c&d=e&pareq=f&termurl=g?PayID=h&TransID=i&MID=j
ACSURL: a?b=c&d=e
TermURL: g?PayID=h&TransID=i&MID=j

Notice: Please note in this process that data must sometimes be transferred directly from the bank network. Therefore e.g. the ACSURL parameter is not URL-encoded, although Pay-Jet Cockpit uses other URL-encoded data.

These parameters should be included as HIDDEN fields in an HTML page which posts itself to the ACS-URL. The following listing shows one such HTML page, in which the return parameters are embedded:

Notice: You can also use this code if you only want to verify the identity of the card holder without immediately making a credit card payment (Authentication Hosting). Pay-Jet Support can configure your checkout so that Pay-Jet Cockpit can carry out Verified by Visa or SecureCode without payment.

After the customer has been authenticated with its bank, the bank's Access Control Server (ACS) requests the TermURL in the shop. In the case of this Request the ACS transfers the following parameters via GET (QueryString) to the TermURL of the shop: MID, PayID and TransID (unencrypted). The PARes parameter is transferred unencrypted via POST.

Notice: The PAResponse parameter must be URL encoded but not Blowfish-encrypted since the content can include special characters.

The parameter must be transferred in whole via POST to the following URL:

Notice: If you forward the PARes and MID of the ACS parameters please use the specified parameter name MerchantID, PAResponse for the direct3d.aspx page.

Credit card brands

Definitions

Data formats

Abbreviations

Notice: Please note that the names of parameters can be returned in upper or lower case.

Integration

Please find here further information for

Credit card - interface via form

Detailed information of integration via Payment forms

Card processing - interface Server-to-Server

Detailed information of integration via Server-to-Server API

Card processing - Capture / Credit / Reversal / PayNow / Batch

Detailed information how to integrate further processes

EMV 3-D Secure

Information and integration of EMV 3-D Secure / 3-D Secure 2.x