Server-to-Server

NOTE: This integration variant requires you to collect the card data which increases your PCI-compliance scope. If you want to minimize your PCI-compliance requirements, we recommend that you use COPYandPAY.

You can perform different types of initial payments using our server-to-server REST API.

Preauthorization (PA)

Debit (DB)

Preauthorization (PA)

A PA is created by sending a POST request over HTTPS to the /v1/payments resource. The request should include all required information such as your authentication credentials, the type of transaction, the amount and the payment information such as card details. A capture may be sent against a successful PA to request that the funds are sent for clearing. See backoffice operations for more details.

In the Try it out section you can see, modify and send an example transaction, which has the required parameters pre-filled.

Debit (DB)

A DB is created by sending a POST request over HTTPS to the /v1/payments resource. The request should include all required information such as your authentication credentials, the type of transaction, the amount and the payment information such as card details. A DB request effectively combines a PA and capture request, automatically requesting that the funds are cleared if the authorization was successful.

In the Try it out section you can see, modify and send an example transaction, which has the required parameters pre-filled.

For a full list of parameters that can be sent in the initial payment request, please see the API Reference

Please note that for a HTTP POST request all the parameters are expected to go into the message body and not into the URL.

Each paymentBrand follows one of two workflows: asynchronous or synchronous. In a synchronous workflow the payment data is sent directly in the server-to-server initial payment request and the payment is processed straight away.

How it works

Try it out

In an asynchronous workflow a redirection takes place to allow the account holder to complete/verify the payment. After this the account holder is redirected back to the shopperResultUrl and the status of the payment can be queried.

1. Send an Initial Payment

The first step is to send a server-to-server initial payment request with the paymentBrand and shopperResultUrl. The shopperResultUrl must be url-encoded.

2. Redirect the shopper

The next step is to redirect the account holder. To do this you must parse the redirect object, that contains a url, parametersmethod. If the methodparameters to the url. If POST, you send HTTP POST the parameters to the URL. If the method is not sent, you should default to POST.

3. Get Payment Status

Once the payment has been processed, the customer is redirected to your shopperResultUrl along with a GET parameter resourcePath.

IMPORTANT: The baseUrl must end in a "/", e.g. "https://test.oppwa.com/".

To get the status of the payment, you should make a GET request to the baseUrl + resourcePath, including your authentication parameters.

Example for a resourcePath:

resourcePath=/v1/payments/{id}

IMPORTANT: A throttling rule applies for get payment status calls. Per transaction, it is allowed to send two get payment requests in a minute.

Payment Brands

The list of paymentBrands below shows which are asynchronous and which are synchronous i.e. those that require a redirect and those which require the payment data: