Initialization of QENTA Data Storage

Initialization of QENTA Data Storage


The QENTA Data Storage is used for storing sensitive payment data of your consumer during the payment process of your online shop. By using the functionality (based on JavaScript) you are able to retrieve, send and store e.g. credit card numbers of your consumer without using your web server. This ensures that your online shop and your web server do not need to be PCI-compliant.

Time of initialization

You can initialize the QENTA Data Storage at the beginning of the payment process in your online shop. After initialization, the data storage session for a specific consumer is valid for 30 minutes after the last access from your online shop to the data storage. After 30 minutes the session becomes invalid and a new data storage has to be initialized.

The QENTA Data Storage is only required for the following payment methods which manage sensitive payment data of your consumer:

  • Credit Card

  • Credit Card - Mail Order and Telephone Order

  • Maestro SecureCode

  • SEPA Direct Debit

  • giropay

For all other supported payment methods you do not need to store data in the data storage before starting the payment process itself.

Initializing the QENTA Data Storage

To initialize the QENTA Data Storage, send a server-to-server request from your web server to a specific URL at the QENTA Checkout Server with specific parameters in the POST data.

The URL for the server-to-server initialization is:

Please be aware that it is sometimes necessary to enable server-to-server requests in the configuration of your web server. This issue arises typically on provider managed web servers with PHP.

Please also configure your firewall settings for sending data from your server to (

For a proper request you have to set a correct HTTP header. Therefore you need to set the following HTTP header elements within your request:

HTTP header parameter Description


Domain name of server. Has to be set to the following value:


User agent string of client.


MIME type of the body. Has to be set to the following value: application/x-www-form-urlencoded


Length of body in bytes.


Type of connection. Has to be set to the following value: close

Please be aware that an incorrect setting of the header parameters results in an HTTP 403 error message of the QENTA Checkout Server.

Computing the fingerprint

The fingerprint is computed by concatenating all request parameters without any dividers in between and using the secret as cryptographic key for the hashing function. If you do not use the optional parameters shopId and javascriptScriptVersion you have to omit them in your fingerprint string.

Please be aware that the concatenation of the request parameters and the secret has to be done in the following order:

  1. customerId

  2. shopId

  3. orderIdent

  4. returnUrl

  5. language

  6. javascriptScriptVersion

  7. secret

After concatenating all values to a single string create an HMAC-SHA-512 hash with your secret as cryptographic key. The result is the fingerprint which you add as a request parameter to the server-to-server call.

The QENTA Checkout Server is thus able to check whether the received parameters are manipulated by a 3rd party. Therefore it is essential to keep your secret safe!

Required request parameters

To initialize the QENTA Data Storage you have to set all required parameters to their corresponding values you need within your online shop. If one or more of these required parameters are missing you will get an error message.

Parameter Data type Short description


Alphanumeric with a fixed length of 7.

Unique ID of merchant.



Unique reference to the order of your consumer.



Return URL for outdated browsers.


Alphabetic with a fixed length of 2.

Language for returned texts and error messages.


Alphanumeric with a fixed length of 128.

Computed fingerprint of the parameter values and the secret.


The parameter returnUrl is used for browsers who are not capable of fully supporting CORS (Cross Origin Resource Sharing). In that case the communciation between the HTML page and the QENTA Checkout Server will be done within an iframe where the anonymized payment data are returned to JavaScript objects. This return URL is called by the browser of your consumer. You can find an example for the return page written in PHP within the example code.

Optional request parameters

Parameter Data type Short description


Alphanumeric with a variable length of 16.

Unique ID of your online shop.



Version number of JavaScript.


This parameter defines the version of the used JavaScript for managing the JavaScript based communication between your HTML page and the QENTA Data Storage. If this parameter is not set we will deliver the JavaScript script version that is defined within your setup. You only need to use this parameter if you have at least two online shops which require different versions of the JavaScript script version. Our support teams will inform you if this is necessary.

Format of return values

After you send the data storage initiation request as a server-to-server request from your web server to the QENTA Checkout Server you will get the result of the initiation as key-value pairs returned in the content of the response.

Returned response parameters

For a successful initialization of the QENTA Data Storage you will get the following parameters returned:

Parameter Data type Short description


Alphanumeric with a fixed length of 32.

Unique reference of the data storage for a consumer.



URL to a JavaScript resource which have to be included for using the storage operations of the data storage.

For example, a successful initiation of the QENTA Data Storage would return:


If the initialization did not succeed you will get parameters describing the error:

Parameter Data type Short description



Number of errors occurred.


Numeric with a fixed length of 5.

Numeric error code which you should log for later use.


Alphanumeric with special characters.

Error message in English.


Alphanumeric with special characters.

Error message in localized language for your consumer.

For further details, see Error Codes.

For example a possible error would look like:


Please be aware that we are not able to return a consumerMessage if your configuration is not valid.