Platform integration guide

The purpose of this guide is to give an overview of:

• what AfterPay is and how payment works for an end-user
• how payments are processed
• the functional requirements for integrating AfterPay in your platform

Complete technical requirements and specifications can be found in the API documentation. References to the API documentation can be found in this guide when relevant.

AfterPay is an post-delivery payment method. You don’t need a creditcard, account or e-reader to use AfterPay.

In general, this is how AfterPay can be used for payments:

1. the user selects AfterPay as the payment method in the checkout process
2. on submission, a real-time risk check is done, based on the entered information
3. if payment is accepted, the user goes to the standard succces page and the order is placed
4. after receiving the order, the user receives an invoice by e-mail

For more information, please see the explanation on the AfterPay website.

Currently, AfterPay supports these payment methods:

Technically, AfterPay is similar to the creditcard payment model.
This is how an AfterPay payment is processed:

1. Authorization
After placing the order, an authorization request is sent to AfterPay, using the data from the checkout. The AfterPay webservice checks if the data sent is correctly formatted and complete. If so, then it does a risk check using that data. If the payment request is accepted, the total amount of the order is reserved and can be invoiced.

The API documentation has an overview of all possible responses and how to process them.

2. Capture
After the order has been shipped, the reserved amount can be captured fully or partially. The captured amount is then set to be invoiced.

3. Invoicing
Within a few days, AfterPay sends an invoice by e-mail for the captured amount.

The webservice also supports other order maintenance operations. For example, a cancel can be used if the the complete order is cancelled before capture/invoicing. AfterPay will not send an invoice.

In case of a full or partial return, a full or partial refund can be used. AfterPay will send an update by e-mail, stating the remaining amount to be paid.

The API documentation has a complete description of all order maintenance operations. It also provides an overview of use-cases, which describes how to use the operations in specific scenario’s.

This section describes the most important requirements in order to integrate AfterPay in your platform.

A merchant can have one or more webshops, each webshop can have one or more payment methods. See the structure below.

Merchant

• Webshop A
  — Payment method 1
  — Payment method 2
  — Payment method X
• Webshop B
  — Payment method 1
• Webshop X
  — Payment method 1
  — Payment method 2
  — Payment method 3

For each payment method, a unique combination is used for authorization:

• merchant ID
• portfolio ID
• portfolio password

Therefore, it should be possible to configure these 3 for each payment method separately, per webshop, in your platform/backoffice.

Each AfterPay payment method requires personal- and address information (to do a risk check). Please make sure you ask for this information in your checkout. Add fields where needed. You can choose to only ask for certain info (like date of birth or gender) when choosing AfterPay.

If  fields are already available for gender, DOB etc. then do not ask for that information again. (you can have them as optional for example, in that case check if there is a value. If not then ask for them when choosing AfterPay)

The required fields are listed in the API documentation.

In case of a validation error, AfterPay sends a specific response containing the error type and a user friendly message in the field . This message should be visible to the end-user, with the option to change the data and try again.

Of multiple errors occur, all should be listed as provided in the response.

The API documentation has an example of a validation error.

In case of a rejection, a generic rejection message should be shown, plus the reason of rejection. The latter is sent in the response of the AfterPay webservice in the field . The API documentation has an example of a rejection response.

Below you will find the text to be used, for both Dutch and Belgium payment methods.

Dutch payment methods (B2C invoice NL, B2B invoice NL, B2C direct debit NL):
Het spijt ons u te moeten mededelen dat uw aanvraag om uw bestelling achteraf te betalen op dit moment niet door AfterPay wordt geaccepteerd. De reden hiervoor is: . Voor vragen over uw afwijzing kunt u contact opnemen met de Klantenservice van AfterPay. Wij adviseren u voor een andere betaalmethode te kiezen om alsnog de betaling van uw bestelling af te ronden.

Belgium payment methods (B2C invoice BE):
Het spijt ons u te moeten mededelen dat uw aanvraag om uw bestelling achteraf te betalen op dit moment niet door AfterPay wordt geaccepteerd. De reden hiervoor is: . Voor vragen over uw afwijzing kunt u contact opnemen met de Klantenservice van AfterPay. Wij adviseren u voor een andere betaalmethode te kiezen om alsnog de betaling van uw bestelling af te ronden.

Note: please link to the contact pages, using the links in the text.

Legally, an end-user has to agree with the AfterPay terms and conditions. Below you will find the links to the relevant T&C per method. A link to the T&C should be shown in the checkout process, preferably with a checkbox. This could be when choosing AfterPay in the checkout, or on a separate payment page, for example.

Backoffice
In your backoffice/plugins, please refer to the payment methods in line with the table below. The idea is that a mechant can clearly distinguish the different methods.

Webshop / HPP
In the webshop of the merchant or on a separate payment page, please use this name always:

AfterPay – achteraf betalen

Usually, payment options are filtered based on country or type (b2c/b2b), which results in AfterPay shown with just this name.

However, if different methods are shown together, please use the following names:

The AfterPay webservices expects that the sum of all orderlines is equal to the total order amount. If not, payment will fail.

For example:

• 1x product 1 –  €5,00
• 2x product 2 –  €3,99
• 1x product 3 – €2,99
• shipping – €4,95

The sum is €20,92. The webservice expects this exact amount in the totalorderamount field.

Now, sometimes, due to different tax calculations and settings, rounding errors can occur in the webshop of a merchant. While ideally, this can be corrected by the merchant on their side, this is not always an option or even possible.

To prevent failed payments in these situations, please add a correction line to the request automatically. With this added (positive or negative) correction, the sum always equals the total. A correction line can be sent as an orderline, just like any other. Please see the example request for more details.

If allowed by contract, merchants may charge an extra fee to their customers for paying with AfterPay. It should be possible for a merchant to set this fee, through either the settings of a plugin/app or in your backoffice.

If an end-user gets feedback, for example in case of a validation error or rejection, the language of the message should always be Dutch.

Everywhere payment logo’s are used, you need to show the AfterPay logo as well. This could be in check-out (using plugins), external payment page, your backoffice etc.