About card payments
General information about card payments
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.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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
standard form, via customized forms, via server-to-server-connection or via batch transfer. Likewise Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Kurz PageWithExcerpt Wording
can process transactions from stationary terminals.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Kurz PageWithExcerpt Wording
Using the card form provides several advantages:
- Merchants can bypass the costly PCI-security authorisation
- The programming of 3-D Secure with forms is much easier and quicker than via Server-to-Server connection
| Page properties | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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,
checks the identity of the card holder and does not process the payment until after the authentication.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Kurz PageWithExcerpt Wording
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
form assumes the further authentication process, with Server-to-Server-connection the merchant has to manage the authentication through a separate interface.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
Notice: Please make sure to review our EMV 3D Secure Specification to integrate according to the newest standards.
| Note |
|---|
| 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.
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.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
Communication for credit card payments with 3-D Secure with
formsMultiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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:
opens a new browser window which connects the customer to its bank. In this window the customer enters the password received by its bank.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
Example of a password request for 3-D Secure with form connection
If the password is correct
obtains confirmation in the form of a signature. Only after confirmation does Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
start the payment and send the transaction with the signature to the Acquiring Bank.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Kurz PageWithExcerpt Wording
Process of a transaction with 3-D Secure via Server-to-Server-connection
To carry out authentication,
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.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Kurz PageWithExcerpt Wording
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
responses differ. The individual connection parameters can be found in the credit card payments section of the handbook.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
Case 1: Credit card not registered for 3-D Secure
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.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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,
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 Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
sends to the shop must be embedded in the response page which the shop displays in the customer's browser.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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
can carry out just the authentication with Verified or SecureCode, ProtectBuy, J/Secure or SafeKey without payment (Authentication Hosting).Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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,
returns the following parameters via the socket connection.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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. |
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
uses other URL-encoded data.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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).
can configure your checkout so that Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Helpdesk-Name PageWithExcerpt Wording
can carry out Verified by Visa or SecureCode without payment.Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Platform-Name PageWithExcerpt Wording
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
| Multiexcerpt | |||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||
|
Multiexcerpt include SpaceWithExcerpt ENWORK MultiExcerptName Definition PageWithExcerpt Definition EN
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