Sign up

  1. Introduction
  2. Get started
  3. Integration with Server-to-server
  4. Use additional possibilities


Our Server-to-server solution allows you to exchange all transaction-related data between your server and our platform directly. Your customers remain in your webshop environment during the whole payment process, which enables you to

Before you process live transactions, use our test environment. Get to know our solution without costs or any commitments involved! Once you want to go live, check out here how to get a production account or contact us!

The graph above graphic provides you a broad overview on the parties involved and their responsibilities in the payment process.

If you do not use this solution in conjunction with either recurring payments or our Hosted Tokenization Page, you need to handle sensitive card data. This requires a very high PCI DSS compliance. Make sure your infrastructure fulfils all necessary security standards!

Target most up-to-date API base URL

We encourage you to always target the most up-to-date API base URL when sending requests to our platform. Have a look at our dedicated guides for a full overview:

To allow you a smooth transition, previous API base URLs remain available until further notice.

Get started

To process transactions on our platform with this solution, make sure that

Are you all set? Then learn how to use our Server-to-server in the next chapter!

Integration with Server-to-server

Your customers stay in your webshop environment during the whole payment process. As you send all the data directly to our platform and receive the (intermediate) result in real-time, no other party becomes visible to your customers (except for 3-D Secure challenge flow transactions). This way, you are completely free to design the look and feel of the payment page.

Target endpoint URLs in test / live

Our platform allows you to send requests either to our Test environment or Live environment:

  • Endpoint URL TEST:{merchantId}/payments
  • Endpoint URL LIVE:{merchantId}/payments

For transactions with no financial impact, use the TEST-URL. The transactions will be sent to our test environment thereby to your test account

For transactions with a financial impact, use the LIVE-URL. The transactions will be sent to our live environment thereby to your live account

Understand payment flow

Our Server SDKs come with a Payments API. It includes all the methods you need to perform all the steps of a typical payment flow:

  1. Your customer goes to your check-out page and enters her/his credit card data to finalise the purchase

  2. You send a CreatePayment request to our to our platform, including the mandatory 3-D Secure properties. A typical request looks like this:
    2'(optional). We perform a Fraud check
  • You can replace the sensitive data in Card with a (temporary) token, significantly reducing your PCI-DSS compliance level. Learn more in our dedicated chapter
  • When processing online transactions, keeping track of your conversion rate is paramount. We are eager to help you with this, via our MyPerformance tool or via our transaction databases our customer support team is happy to share with you.

    To ensure we can provide you with the most precise conversion rate data, we highly recommend the following best practices:

    • When submitting a transaction request to our platform, always send the customer email address order.customer.contactDetails.emailAddress
    • When resubmitting a transaction request to our platform for a unique order (i.e. after having received a status.statusOutput=2 during the first try), always send the same order.references.merchantReference from your first try
  1. Our platform sends a response containing a MerchantAction object.
    It instructs you how to proceed with the payment. Based on the response, these scenarios are possible:

    a) 3-D Secure frictionless flow authentication (MerchantAction.ActionType=null): Your customers use a 3-D Secure enrolled card. The 3-D Secure properties in your CreatePayment request prove to be sufficient for the authentication step. We submit the transaction to the acquirer and provide the result in property StatusOutput.StatusCode. The flow continues at step 9)

    b) 3-D Secure challenge flow authentication (MerchantAction.ActionType=REDIRECT): Your customers use a 3-D Secure enrolled card. They need to identify themselves as the rightful card owner. The flow continues at step 4)

    c) No 3-D Secure authentication (MerchantAction.ActionType=null): Your customers use a non-3-D Secure enrolled card. We submit the transaction to the acquirer and provide the result in property StatusOutput.StatusCode. The flow continues at step 9)

Find a detailed overview about the implementation of 3-D Secure in our dedicated guide 

  1. You redirect the customers to their issuing bank to the MerchantAction.RedirectData.RedirectURL. Your customers perform the 3-D Secure check
  2. Our system receives the result from the issuer. Based on the result, two scenarios are possible:

    a) If the identification was unsuccessful, we redirect your customers to your ReturnUrl, ending the flow. You can request the transaction result as described in step 8)

    b) If the identification was successful, the flow continues at step 6)

  3. We submit the actual financial transaction to the acquirer to process it. We receive the transaction result

  4. We redirect your customers to your ReturnUrl

  5. You request the transaction result from our platform via GetPayment or receive the result via webhooks

  6. If the transaction was successful, you can deliver the goods / services

Use additional possibilities

Our Server-to-server solution offers many more possibilities. Learn here all about its available features.

Replace sensitive data with token

Handling credit card data by yourself requires you to fulfil the highest PCI DSS compliancy level. This might not be desirable or feasible for you. Therefore, we have designed this solution to accept a token instead of sensitive card data as described in step 2. This way, you can reduce your PCI DSS compliancy level significantly and use this integration mode at the same time!

A token is a credit card profile safely stored on our platform. There are two different types of tokens:

A typical request replacing card data with a permanent/temporary token looks like this:

If you send a CreatePayment request after initialising a HostedTokenization session, you can also send the hostedTokenizationId instead of the tokenId. Learn more about using either option in the dedicated chapters of our Hosted Tokenization Page guide:

Was this page helpful?

Do you have any comments?

Thank you for your response.