Quick Guide for Developers

Quick Guide for Developers

To integrate QENTA Checkout Page into an online shop, three general topics are relevant:

  1. Invoking QENTA Checkout Page

  2. Handling the Response

  3. Back-end Operations

For PHP we provide an example code on GitHub. Also, several integrations into shop systems are available.

Invoking QENTA Checkout Page

To initiate the payment process with QENTA Checkout Page a POST request needs to be sent to:


This request needs to contain at least the required request parameters, such as customerId, language, amount, currency, and should at least contain the optional parameters confirmUrl, orderNumber, customerStatement. For all possible request parameters refer to Request Parameters.

For testing purposes QENTA provides data for demo and test mode, e.g. customerId and secret including payment method specific data.

Some payment methods require additional required request parameters and may have different requirements regarding the length for parameter values.

The authenticity of these parameters is checked using the secret which is calculated by concatenating all request parameter values in the same order which you describe by the parameter requestFingerprintOrder.

In case an error is returned, refer to the error code listing.

Handling the response

When defining the request parameters the URLs leading the consumer back to the shop also need to be set. There are four relevant URLs depending on the payment state:

  • successUrl - if the payment was successful.

  • cancelUrl - if the payment process was canceled by the consumer.

  • failureUrl - if the payment failed, e.g. due to a wrong 3-D Secure Code.

  • pendingUrl - if the payment is pending (listed as optional parameter but is highly recommended).

Your consumer is redirected to one of these URLs, depending on the result of the payment. This redirect includes all payment process result data as a POST request. You can submit the same URL for all four parameters and provide the appropriate content after interpreting the payment process results correspondingly.

The confirmUrl should be defined, serving as the primary URL to receive, log and process the resulting data. For security reasons "https" is recommended. Ensure that these URLs are reachable.

To prevent fraud, check the authenticity of the returned data for pending and successful payments calculating the fingerprint by concatenating all response parameter values as defined in the parameter responseFingerprintOrder. The resulting fingerprint has to be identical to the value of the response parameter responseFingerprint.

Save all relevant data persistently.

Improving usability

If the payment process is working successfully consider the different customization possibilities for QENTA Checkout Page.

Back-end operations

Before integrating the back-end operations you need to decide upon the required payment method since certain back-end operations might not be available for all payment methods. For more information and details compare the following tabular overview.

Please refer to Technical Implementation for QENTA Checkout Page for integrating back-end operations in general and to each operation: