Server-to-Server

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

Synchronous workflow

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

Asynchronous workflow

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.

How it works

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, parameters and optionally a method. If the method is set, it will be set to either GET or POST. If GET, you should append any parameters 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://eu-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}

The payment status can be taken without throttling being applied using the Transaction Reports endpoint.

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:

Show all supported brands