1.Introduction
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.
2.How does it work
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:
- the user selects AfterPay as the payment method in the checkout process
- on submission, a real-time risk check is done, based on the entered information
- if payment is accepted, the user goes to the standard succces page and the order is placed
- after receiving the order, the user receives an invoice by e-mail
For more information, please see the explanation on the AfterPay website.
3.Payment Methods
Currently, AfterPay supports these payment methods:
Method | Description |
---|---|
B2C invoice NL | AfterPay for Dutch consumers |
B2C invoice BE | AfterPay for Belgium consumers |
B2B invoice NL | AfterPay for Dutch companies |
B2C direct debit NL | AfterPay for Dutch consumers (Direct Debit) |
4.From order to invoice
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.
5.Order maintenance operations
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.
6.Requirements
This section describes the most important requirements in order to integrate AfterPay in your platform.
6.1.Payment method structure
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.
6.2.Add fields to your checkout
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.
6.3.Show validation errors to end-users
In case of a validation error, AfterPay sends a specific response containing the error type and a user friendly message in the field
Of multiple errors occur, all should be listed as provided in the response.
The API documentation has an example of a validation error.
6.4.Show rejection message
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
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:
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:
Note: please link to the contact pages, using the links in the text.
6.5.AfterPay terms and conditions
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.
Method | URL |
---|---|
B2C invoice NL | https://www.afterpay.nl/nl/algemeen/betalen-met-afterpay/betalingsvoorwaarden |
B2C invoice BE | https://www.afterpay.be/be/footer/betalen-met-afterpay/betalingsvoorwaarden |
B2B invoice NL | https://www.afterpay.nl/nl/algemeen/zakelijke-partners/betalingsvoorwaarden-zakelijk |
B2C direct debit NL | https://www.afterpay.nl/nl/algemeen/betalen-met-afterpay/betalingsvoorwaarden |
6.6.Payment method names
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.
Method | Description |
---|---|
B2C invoice NL | AfterPay for Dutch consumers |
B2C invoice BE | AfterPay for Belgium consumers |
B2B invoice NL | AfterPay for Dutch companies |
B2C direct debit NL | AfterPay for Dutch consumers (Direct Debit) |
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:
Method | Name in checkout/external page |
---|---|
B2C invoice NL | AfterPay – achteraf betalen |
B2C invoice BE | AfterPay – achteraf betalen (Belgie) |
B2B invoice NL | AfterPay – achteraf betalen (B2B) |
B2C direct debit NL | AfterPay – achteraf betalen (Eenmalige machtiging) |
6.7.Correction line for rounding errors
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.
6.8.AfterPay service fee
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.
6.9.Dutch language in feedback to end-user
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.
6.10.Logo usage
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.