Server-to-Server Integration Guide

SERVER TO SERVER integration requires you to collect the card data which puts your servers into PCI-DSS Scope. For SERVER-TO-SERVER integrations, we will request a PCIDSS certification done by a PCI (Payment Card Industry) Qualified Security Assessor. If you want to minimise your PCI-compliance requirements, we recommend that you use COPYandPAY.

SERVER TO SERVER is a more complicated implementation than COPYandPAY and requires knowledge and skills in Card Payment Integrations. SERVER to SERVER integrations require more skills than COPY and PAY in supporting the required 3D Secure authentication.

For testing purposes use eu-test.oppwa.com.
For production use eu-prod.oppwa.com.

Full documentation can be found here.

The integration can have 2-3 Steps, depending on the application of 3D Secure to the payment.

The endpoint for the Initial Payment is: https://eu-test.oppwa.com/v1/payments

Full Server to Server documentation can be found here.

It is possible to start with credentials from the on-line documentation. See the entityID and Bearer Token in the examples here.

We can provide credentials specific to the integrator, including login to the Gateway Portal. Our Gateway Portal where you can access real-time information about authorised and rejected transactions. In there you can void and refund transactions.

Method/precondition and redirect is important to know when you use our built in 3D Secure.

There are three options of returns in a server-to-server call.

• Final response
• Frictionless response
• Challenge with redirect link to bank

Frictionless and Challenge can both return method/ precondition data and URL.

This is a request from the card issuer to collect information about the browser used in the transaction. The card issuer is asking the merchant to show a hidden iframe to the user in order for them to be able to collect information from the browser themselves.

Method/precondition data and and URL are not always returned by the card issuer but when they are, it is important to handle it properly. The precondition data must be put to an iFrame.

To see how method data is returned, please see here.

The example shows how standalone 3DS works. For card payments it works the same way except at the end when the customer is returned to the shopperResultURL, you will get a result of the authorisation.

TEST CARDS will give you the different options that can be found here.

• When integrating, for test transactions you need to use the 3DS (3 D Secure) Simulator. See here.
• The simplest way is to use paymentType=DB (one step payment and capture) in your integration.
• It is possible to use two step payments with paymentType=PA and another server-to-server call with paymentType=CP to capture the payment. Tutorial.
• If a customer leaves during a redirect, it will take 30 minutes for the session to time out.
• Include the merchantTransactionId parameter. This is a reference number that should be unique for your transactions. This identifier is often used for reconciliation. Documentation.
• Please look carefully at the 3D Secure Guide. Getting 3D Secure to work right is among the trickiest parts of integrating SERVER to SERVER. Tutorial.
• Pending Transaction Status Codes (non-final):
  See: (/^(300.100.100)/ – Soft Decline) + (/^(000.200)/. = Result codes for pending transactions)
• Both entityId and Token is unique per merchant.

It is advised that you use webhooks to get information about how a transaction ended. If the user is not redirected to the final, receipt, page due to some network issues, webhooks will guarantee that you will receive the result of a payment.

Asynchronous events can be sent to your server with Webhooks. See tutorial here.

• You need to provide an endpoint URL (Uniform Resource Locator) and e-mail for notifications of webhook errors.
• We need to register the URL for you to use it.
• The URL must respond 200 OK to a registration call.
• Webhooks retry for 30 days to deliver the response until a 200 OK is received.

For getting unique values sent back in the webhooks that you would need to find the original order or transaction in your system, use the customParameters in your request and they will be returned by the webhook. Example customParameters[myKey]=myValue will be returned in the webhook as “customParameters”:{“SHOPPER_ myKey”:”myValue”}

• The gateway collects transactions in a 24-hour window that ends at 22:30.
• Reversals can be done only within that time, refunds must be done after that time.
• Refunds have a higher cost, and it is slower to reach the cardholder.

Full documentation can be found here.

3DS2.x test cards can be found here.

These are the links to our Gateway Portal:

• For test here.
• For production here.

To get access to Gateway Portal, the merchant needs to confirm the first/last name and personal corporate email of each person who needs to be granted access.