Loading...
Accepting transactions from a number of worldwide alternative payment methods (APMs) not only widens your customer base to more shoppers across the globe, but also provides the added benefit of managing all your payments through our Reporting tool. Integrate using either direct API or our Hosted Payment Page (HPP).
In this API guide, we set up integration fields for five APMs (in addition to our standard authorization fields). This structure gives you access to over 30 APMs (albeit some payment methods may include mandatory or optional additional fields). To see what local and APMs we support, as well as any supplementary fields that are required for each, see Supported Payment Methods.
For full details of the request and response syntax, see the API Reference for Payment Methods.
With our API, you can accept transactions from a number of worldwide payment methods. This not only widens your customer base to more shoppers across the globe, but also provides the added benefit of managing all your payments through our Reporting tool.
For most payment methods, a direct API integration looks like this:
Typical API Integration for Alternative Payment Methods
To facilitate these steps, a “payment method details” block is included in the code. This includes data elements for mandatory and optional fields required per payment method.
These fields are always mandatory:
These fields are optional or mandatory depending on the payment method (and there may be further fields required in addition to the following):
Optional and mandatory field information for each payment method is available on the payment method's designated page. These individual pages can be accessed from our list of Supported Payment Methods.
There are two types of requests that are supported for Payment Method transactions:
payment-set – Used to initiate a payment (SALE) transactionpayment-credit – Used to initiate a credit (REFUND) transactionA typical APM transaction consists of at least two messages, but the full lifecycle of an APM transaction may consist of five or more requests. For the majority of APMs, the customer is redirected to the landing page of the relevant payment method to complete authentication and transaction authorization.
A typical message flow may consist of the following steps, each of which is outlined below:
In an alternative payment transaction, the first request is a payment-set. This is used to advise the payment method of the details of a new transaction and to retrieve the redirect link necessary to facilitate authentication by your customer with their preferred payment method.
For full details of the request and response syntax, see the API Reference for Payment Methods.
Here, we set up a SOFORT transaction.
Following a successful payment-set request, the next step is to redirect the customer to the payment scheme to facilitate authentication and authorization. This can be achieved, for example, using a simple JavaScript redirect. You could also use an HTTP GET (302 redirect).
For full details of the request and response syntax, see the API Reference for Payment Methods.
Next, we redirect the customer to the URL returned in the payment-set response with JavaScript.
<!DOCTYPE html>
<html>
<head>
<title>Sample APM Redirect</title>
<meta charset="UTF-8">
</head>
<body>
<script>
window.location = "https://www.paymentMethodUrl.com/pay";
</script>
</body>
</html>Once the customer completes the transaction with the payment method, they are redirected to the Return URL of the payment-set request. The current status of the transaction will also be returned.
Your application might put the customer on hold for a few seconds while it checks to see if the Status URL was sent a final update. You can then redirect the customer to a final success or failure page once the final status is received.
If the payment method is known to have a long timeout period (that is, can remain in pending state for several hours or days), you may want to advise the customer that the payment is still pending and that you will notify them once it is completed (for example, via email or text message). You would need a separate process to trigger this message once the final status is received, particularly if the transaction goes to “Failed.”
sha1hash=0aa43f1d647819efd238e46fe3301d80076a8648&
timestamp=20181016103012&
merchantid=Merchant ID&
account=internet&
merchanttransactionid=f48856d1c7e4492eb7594e68e2fc682c&
orderid=N6qsk4kYRZihmPrTXWYS6g&
result=01&
Amount=100&
message=PENDING&
paymentpurpose=37TC6LD Test Transaction&
paymentmethod=sofort&
fundstatus=WAITING&
pasref=14627849160897986&
country=DEThe URL specified in the Status URL element of the payment-set request receives the final status. Depending on the payment method used, this can happen at the same time as the customer is redirected to your Return URL, moments after, or potentially, the final status update might come days later.
For payment methods in which you expect the final status update to come days later, your Status URL will need to accept the message sent by us, find the correct order in your application, and update the status accordingly. You may want to inform the customer at this point that their payment was finally accepted (or that it failed). You can also initiate the dispatch of items to the customer.
For full details of the request and response syntax, see the API Reference for Payment Methods.
sha1hash=0aa43f1d647819efd238e46fe3301d80076a8648&
timestamp=20181016103012&
merchantid=Merchant ID&
account=internet&
merchanttransactionid=f48856d1c7e4492eb7594e68e2fc682c&
orderid=N6qsk4kYRZihmPrTXWYS6g&
result=01&
Amount=100&
message=PENDING&
paymentpurpose=37TC6LD Test Transaction&
paymentmethod=sofort&
fundstatus=WAITING&
pasref=14627849160897986&
country=DEBrowse the APMs we support or search for a specific one. If additional fields are required, these will be documented along with the countries and currencies that are available with the payment method.
Explore more functionality to enrich your application.