Page tree

Search

Skip to end of metadata
Go to start of metadata


About card payments

General information about card payments

Computop Paygate 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 Paygate standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise Paygate 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

 

Logo
Info

Computop Paygate processes all major cards and currencies worldwide. Transaction processing can be made via Paygate standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise Paygate can process transactions from stationary terminals.

TypePayments by Credit Card EN

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, Paygate 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 Computop Paygate 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.

Please notice that in case of Fallback to 3-D Secure 1.0 the URLSuccess or URLFailure is called with GET. Therefore your systems should be able to receive parameters both via GET and via POST.

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. Computop Paygate 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.

Communication for credit card payments with 3-D Secure with Computop Paygate forms


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: Computop Paygate opens a new browser window which connects the customer to its bank. In this window the customer enters the password received by its bank.

Example of a password request for 3-D Secure with form connection


If the password is correct Computop Paygate obtains confirmation in the form of a signature. Only after confirmation does Paygate start the payment and send the transaction with the signature to the Acquiring Bank.


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

To carry out authentication, Paygate 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.

Communication for credit card payments with 3-D Secure via socket connection

 

In the next phases there are three different cases in which Computop Paygate 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

Computop Paygate 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, Computop Paygate 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 Computop Paygate 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:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

       <SCRIPT language="javascript">

<!--

<Response excerpt from request: HTML with JavaScript>

       //-->

       </script>

       </HEAD>");

       <BODY onload="javascript:Initiate3DSec();">

<table><tr>

<td align="center"><font face="Verdana" size="-1"><b>Please identify yourself with 3-D Secure!</b></font></td>

</tr></table>");

</BODY>

</HTML>

 

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 Computop Paygate 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, Computop Paygate returns the following parameters via the socket connection.

Parameter

Format

CND

Description

ACSURL

ans..

C

Only in the case of registered credit cards: URL of the Access Control Server of the card issuer with attached request parameters (not URL-encoded!). It is possible to use ACS server ampersand and question mark as value within the URL; everything before parameter PAReq is part of ACSURL.

PaReq

ans..

M

Payer Authentication Request, which must be URL-encoded.

MD


M

Merchant Data is an empty value, which must be transferred for compatibility reasons

TermURL

ans..

M

Shop return address. Computop Paygate adds the parameters PayID, TransID and MID as request parameters to the initial TermURL seperated with a question mark.

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 Computop Paygate 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:

<HTML>

<HEAD>

<META http-equiv=Content-Type content="text/html; charset=unicode">

<A content="MSHTML 6.00.2800.1106" name=GENERATOR>

</HEAD>

<BODY onload="sendpareq.submit();">

<FORM action="[ACSURL]" method="POST" name="sendpareq">

<input type="hidden" name="MD" value="">

<input type="hidden" name="PaReq" value="[PaReq]">

<input type="hidden" name="TermUrl" value="[TermUrl]">

</FORM>

</BODY>

</HTML>

 

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). Computop Helpdesk can configure your checkout so that Computop Paygate 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

Credit card brand, correct spelling for CCBrand

MasterCard

VISA

AMEX

DINERS

CBN

JCB

Dankort

Maestro

Cartes Bancaires

Discover

Bancontact

Hipercard

Elo

Aura

Carte 4Etoiles

AirPlus

CUP

NARANJA

SHOPPING

CABAL

ARGENCARD

CENCOSUD

KOOKMIN

KEB

BC

SHINHAN

SAMSUNG

HYUNDAI

LOTTE

1euro

echequevacances

cofidis3xcb

cofidis4xcb

facilypay-3x

facilypay-3xsansfrais

facilypay-4x

facilypay-4xsansfrais

RuPay


Definitions

Data formats

Format

Description

a

alphabetical

as

alphabetical with special characters

n

numeric

an

alphanumeric

ans

alphanumeric with special characters

ns

numeric with special characters

bool

boolean expression (true or false)

3

fixed length with 3 digits/characters

..3

variable length with maximum 3 digits/characters

enum

enumeration of allowed values

dttm

ISODateTime (YYYY-MM-DDThh:mm:ss)


Abbreviations

Abbreviation

Description

Comment

CND

condition


M

mandatory

If a parameter is mandatory, then it must be present

O

optional

If a parameter is optional, then it can be present, but it is not required

C

conditional

If a parameter is conditional, then there is a conditional rule which specifies whether it is mandatory or optional


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


Integration

Please find here further information for

Card processing - 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