marcopolo Online payment
Sign up

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

Introduction

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!

Server to server connections require your systems to process card data at some point. This method brings in a very large number of the PCI requirements.

However, you can significantly reduce the scope of your assessment and the number of PCI requirements: Replace the card number with a token via our Hosted Tokenization Page. This allows you to completely outsource the handling of the card data to our platform. Any of your systems using tokens will not require assessment.


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: https://payment.preprod.anzworldline-solutions.com.au/v2/{merchantId}/payments
  • Endpoint URL LIVE: https://payment.anzworldline-solutions.com.au/v2/{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.

Server to server connections require your systems to process card data at some point. This method brings in a very large number of the PCI requirements.
Obtaining a token from our system dramatically via our Hosted Tokenization Page solution reduces the number of your systems that would require assessing as they no longer have card data. 

  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

Server to server connections require your systems to process card data at some point. This method brings in a very large number of the PCI requirements.
Obtaining a token from our system dramatically via our Hosted Tokenization Page solution reduces the number of your systems that would require assessing as they no longer have card data. 

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.