Payment processing via Server-to-Server

If you wish to design your own forms for entering the payment data you can process your transactions in the background via a Server-to-Server connection. In this case your system saves payment details such as credit card numbers or bank account details and then creates a TLS socket-connection to the

Image Removed

Process of a Server-to-Server payment

Notice: Please note that captures, credits and status inquiries are possible only via the Server-to-Server connection or via Batch.

Payment processing via Batch

Batch Manager lets you transmit payment transactions in the form of files. In this process you assemble transaction data such as the transaction ID, amount and currency in a batch file which you will later transmit to

Security: Payment Card Industry Data Security Standard (PCI DSS)

Where the credit card data is entered and stored is vital for the security of the credit card payments on the Internet. The card organisations have established a security program with the PCI security authorisation (Payment Card Industry) in order to guarantee the secure storage of credit card data. Please note that participation in PCI is compulsory and subject to a charge if you store credit card data. The key factor in this is the Merchant Interface variant:

1)

Multiexcerpt include
SpaceWithExcerpt EN MultiExcerptName Platform-Kurz PageWithExcerpt Wording

HTML form

In this case the credit card data is only saved on the secure 

2) Server-to-Server payment

Credit card data is saved on your systems. Therefore you are obliged under certain circumstances to undergo the MasterCard and VISA PCI Data Security program which is associated with annual authorisation costs and time. You can obtain further details from your credit card acquirer.

Notice: Please note that Visa and MasterCard have established strict security regulations for the protection of credit card data. Anyone who saves credit card numbers on their system or even only transmits such data must undergo –at their own expense - regular security authorisation. You should therefore use the 

3) Batch

Payment data can be submitted as Batch file to

4) PayNow – the Silent Mode

With the PayNow solution the customer enters the data analogue as for the Server-to-Server solution but with the essential difference, that credit card data are transferred directly from the browser (client) to Computop. Above all this saves a lot of effort in the case of complex 3D methods such as Verified by Visa, MasterCard SecureCode and American Express SafeKey. For more details about the PayNow solution see the card processing manual. In order to use this interface the merchant must fulfil the PCI requirement according to SAQ A-EP (https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-A_EP-rev1_1.pdf).

Principles of

Multiexcerpt include
SpaceWithExcerpt EN MultiExcerptName Platform-Kurz PageWithExcerpt Wording

programming

The Merchant Interface is designed to accept transactions across the Internet. This interface can be used not only by shops but also by enterprise resource planning systems, for example to initiate payment capture via the

To ensure compatibility with programming languages and operating systems,

Communication with

Please note, that the

Accepted cipher:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

In this homogenous interface, irrespective of the payment method, the same parameters are transmitted in general to these Internet pages so that all payment methods operate in the same way and require no additional effort.

The most important parameters to be submitted to the

• MerchantID
• Amount and Currency
• URLs for status-messages

The MerchantID is an alphanumerical value which uniquely identifies the merchant within the

The following list shows a typical example with the parameters for processing a payment:

Notice: Depending on the implementation, URLSuccess and URLFailure are called up via a Redirect (HTTP Status 302 Object Moved) which is then dependent on the customer's browser. In order to ensure that the shop has been informed correctly about the status of the payment

Operating principle of the Merchant Interface

In order to send payment orders to the

A payment process looks something like the following:

The simple transmission of a character string has the advantage that you need install no software on the shop server. The interface functions with all current payment methods so that a connection to

Payments via

Multiexcerpt include
SpaceWithExcerpt EN MultiExcerptName Platform-Kurz PageWithExcerpt Wording

forms

In the case of payments via

Image Removed

Process of a payment with

Process of payment

To make payments via

All details required for payment processing are forwarded as parameters. The parameters are encrypted with Blowfish and protected with HMAC-Authentication (see below) to ensure that neither the customer nor a third party can manipulate the data.

When calling the form

After the payment has been made

Request for a

Multiexcerpt include
SpaceWithExcerpt EN MultiExcerptName Platform-Kurz PageWithExcerpt Wording

form

The request for a

All parameters are assembled in a character string and separated by the character &:

Notice: Since the characters "=" and "&" are used as separating characters, these characters cannot be transmitted as values. All values which you transmit without BlowFish-encryption must be URL-Encoded.

A correct parameter character string for

The Data parameter contains the sensitive payment details such as amount and currency. The encrypted bytes are Hex-encoded and completed to two characters from the left with a zero. Encryption is via Blowfish ECB and is available to you as source-code and components.

The Len parameter is very important for encryption because it contains the length of the unencrypted(!)  character string in the Data parameter. Since the data quantity to be encrypted is increased by a multiple of 8 in the case of the Blowfish encryption, the correct length of the character string must be known for decryption. Otherwise accidental characters emerge at the end of the character string.

The parameters are transmitted via HTTPS POST or HTTPS GET. The recommended transmit method is HTTPS POST because the parameter character string in the case of GET is attached to the URL, which is limited to 2048 bytes depending on the browser.

Notice: Please note that the maximum length of a payment request is limited to 5120 characters. If you require longer strings please contact

The following listings show the development of a payment request. The first listing is the unencrypted parameter character string:

Notice: Please note that a value is to be assigned to each parameter. Do not transmit empty parameters, as this can cause the payment to fail.

This character string is encrypted and transmitted as the Data parameter. The HTTPS GET request for a

Notice: Please note that the parameters are transmitted unencrypted for the purpose of layout of the form.

An HTML form is produced for HTTPS POST and all parameters are transmitted as Hidden Fields. Only the Pay button is visible to the customer:

Notification of the shop

After processing the payment

Notice: Please note that the Notify-call is permitted only via Port 443 (TLS) for security reasons.

If the shop’s URLNotify is not accessible (e.g. HTTP-status 500/404), notification is repeated 8 times. In this case the customer transmit to the shop is prior to the URLNotify request. Therefore the shop should analyse and compare both status messages from URLNotify and transmission (URLSuccess, URLFailure).

Time of repeat of Notify respectively calculated after first failed attempt

Notice: The URL encoded parameters are transmitted in key-value pairs (Key1=Value1&Key2=Value2). Please note that new parameters can be added unannounced at any time. Therefore, we recommend the use of the parameter name for the analysis, not the order since this can change at any time. Please do not use case sensitive mechanisms for the spelling of the parameters as this can change at any time. For example, it is recommended switching all parameters “to lower” and continuing in lower case.

For more details please go to:

www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1

Transfer of the customer to the shop

Once payment is complete, the customer is redirected via HTTP GET back to the shop.

Correct testing

Until you have completed the programming your

Notice: Please use only small amounts between 0.11 and 2 euros in test mode because the credit card authorisations are genuine even in the test and reduce the limit of your credit card. If you use large amounts and reach the card limit, your credit card will no longer function temporarily.

In the case of successful payments the

If you wish to test the different error cases,

Test case with timeout

A credit card payment is normally completed within one to two seconds. In a few cases however, payments may be terminated due to long processing times in the banking network.

Payments via Server-to-Server connection

In the case of payments via the Server-to-Server connection, the merchant already holds payment details such as credit card numbers and bank account details. Shop or enterprise resource planning systems create a TLS socket-connection to the 

Image Removed

Process of a Server-to-Server payment

Notice: When processing payments via a Server-to-Server connection your system must control the communication with the

Notice: Please ensure that for one payment (PayID) no multiple requests are submitted simultaneously, because this can lead to errors within transaction processing. Please ensure to have a few seconds between two requests for the same payment/PayID.

Process of a Server-to-Server payment

The request for a payment starts with the correct composition of the parameters which consist of a key and a value and which are separated by an equals sign (=). These are so called Name-Value-Pairs (NVP):

MerchantID=YourMerchantID

All parameters are assembled in a character string and separated by the character &:

Amount=100&Currency=EUR&TransID=12345

Notice: Since the characters "=" and "&" are used as separating characters, these characters cannot be transmitted as values. All values which you transmit without BlowFish-encryption must be URL-Encoded. There is only one exemption from this rule: For credit cards which are registered for Verified/SecureCode/SafeKey/JSecure/ProtectBuy for example the ACSURL is transmitted unencoded.

A correct parameter character string for

MerchantID=YourMerchantID&Len=67&Data=0A67FE96a65d384350F50FF1

The Data parameter contains the sensitive payment details such as amount and currency. The encrypted bytes are Hex-encoded and completed to two characters from the left with a zero. Encryption is via Blowfish ECB and is available to you as source-code and components.

The Len parameter is very important for encryption because it contains the length of the unencrypted(!) character string in the Data parameter. Since the data quantity to be encrypted is increased by a multiple of 8 in the case of the Blowfish encryption, the correct length of the character string must be known for decryption. Otherwise accidental characters emerge at the end of the character string.

The following listings show the development of a payment request. The first listing is the unencrypted parameter character string:

MerchantID=YourMerchantID&TransID=100000001&Amount=11&Currency=EUR&OrderDesc=My purchase&CCNr=1111333355557777&CCCVC=123&CCExpiry=202012&CCBrand=VISA

Notice: Please note that a value is to be assigned to each parameter. Do not transmit empty parameters, as this can cause the payment to fail.

This character string is encrypted with Blowfish:

MerchantID=YourMerchantID&Len=140&Data=D622C5FE7414F73539A1852C2CE7AA0BE904A7E2339DCF9363DA6ACDBE5EF98E169FC3092B1602564DBF2C3C75173A62C484962A247B8A91EA7A544ADCF2A037135421FD0CE092C174A7D1D63517BD45099AC2B682F5E3CD2C942A6F0E741A833C

In order to make payments via a Server-to-Server connection, open a TLS-Socket connection to

As soon as the TLS socket connection is made, a normal HTTP POST, version 1.1 is carried out. In this case the following fields are specified in the HTTP header:

Mandatory information within HTTP-header

The HTTP Body contains the parameter character string. Note that the values must be submitted as URL-encoded parameters. The following listing is an example of a credit card payment:

Notice: Please note that the maximum length of a payment request is limited to 5120 characters. If you require longer strings please contact Computop Support.

The following listing shows a typical

HTTP/1.0 200 OK
Connection: Close
Content-type: text/plain
Content-Length: 228

Len=125&Data=ECF59EC63E9BEE74DF217E27FA2E194B92597C7395BADBAD4340CDFD000DD57129EEFAA0BE904A7E233ACDBE5EF98E1692B1602564DBF2C3C75173A62C484962A247B8A91EA7A544

The decrypted

PayID=a234b678e01f34567090e23d567890ce&XID=50f35e768edf34c4e090e23d567890ce&TransID=100000001&Status=AUTHORIZED&Description=AUTHORIZED&Code=00000000

It is a synchronous communication such that the Socket-connection remains open until

Notice: The URL encoded parameters are transmitted in key-value pairs (Key1=Value1&Key2=Value2). Please note that new parameters can be added unannounced at any time. Therefore, we recommend the use of the parameter name for the analysis, not the order since this can change at any time. Please do not use case sensitive mechanisms for the spelling of the parameters as this can change at any time. For more details please go to:

www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.1