- Getting Started
- Tutorials
- COPYandPAY
- Server-to-Server
- 3D Secure
- Pay By Link
- Mobile SDK
- Manage Payments
- Plugins
- Fraud Management
- Reporting
- Webhooks
- Smart Engage
- Reference
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Risk
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Brands Reference
- Regression Testing
- Data Retention Policy
- API Reference
- FAQ

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.
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
Send an Initial Payment
Sending the request parameters server-to-server and receive the payment response synchronously.
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
Send an Initial Payment
Sending the request parameters server-to-server and receive the redirect
information back.
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:
Brand | Async / sync workflow |
---|