Scheduled Payments allows customers to pay for a purchase in several instalments, instead of one single payment. This is usually done for large amounts, so that the customer doesn't have to spend too much at once for an order. The scheduling and amount calculation is done entirely by the merchant.
2. Additional parameters
To indicate that you wish to settle a new transaction in multiple instalments, you must submit some additional parameters.
The following hidden fields are used to transmit scheduled payments to our system (in e-Commerce and DirectLink mode):
||Full amount to be paid (MULTIPLIED BY 100, as the format of the amount cannot contain any decimals or other separators).
||The amount to be paid on the day of the initial transaction (MULTIPLIED BY 100).
||The amount of the second payment (MULTIPLIED BY 100).
This field can be repeated N times, changing the digit at the end of the field name (AMOUNT3, AMOUNT4, etc.).
The execution date of the second payment.
This field can be repeated N times, changing the digit at the end of the field name (EXECUTIONDATE3, EXECUTIONDATE4, etc.).
||The amount of the last payment.
||The execution date of the last payment.
Note that there is no “EXECUTIONDATE1”, as the first payment will naturally be the date of the initial transaction.
- To avoid initial authorization data from expiring before the occurrence of the following payment request, the maximum number of days between two execution dates (EXECUTIONDATEN and EXECUTIONDATEN+1) within a series of scheduled payments is limited to 43 days.
- All execution dates should be within the retention period defined by the first execution date (EXECUTIONDATE1) and the maximum number of days set under Configuration>Account>Data Retention Management in the Back-Office.
Our system will check that all the dates and amounts are correct, and then process the first payment. If the first operation is successful, the subsequent instances are stored and executed on the dates you requested.
All scheduled payment fields should be contained in the SHA-IN Signature.
A customer buys something on your website for 300 EUR on 10/04/2015. You give your customer the option to either pay the full amount in one go or to pay in three instalments: 1/3 now, 1/3 the following month (on 10/05/2015) and 1/3 in two months (on 10/06/2015).
Hidden field in the event that your customer pays the full amount in one payment:
<input type="hidden" name="AMOUNT" value="30000">
Hidden fields in the event that your customer pays the amount in three instalments using Scheduled Payments:
<input type="hidden" name="AMOUNT" value="30000">
<input type="hidden" name="AMOUNT1" value="10000">
<input type="hidden" name="AMOUNT2" value="10000">
<input type="hidden" name="EXECUTIONDATE2" value="10/05/2015">
<input type="hidden" name="AMOUNT3" value="10000">
<input type="hidden" name="EXECUTIONDATE3" value="10/06/2015">
3.2 Payment page
When using scheduled payments, the payment page will appear as shown below, so that the customer can review what has been planned. This information is repeated in the confirmation email.
Note that as only credit cards are supported at this time, other payment methods are (intentionally) hidden on the payment page.
A customer buys something on your website for 300 EUR on 10/04/2014. You give your customer the option to either pay the full amount in one go or to pay in three instalments: 1/3 now, 1/3 the following month (on 10/05/2014) and 1/3 in two months (on 10/06/2014).
- Query string in the event that your customer pays the full amount in one payment:
- Query string in case you customer pays the amount in three instalments using Scheduled Payments:
5. Transaction feedback
Scheduled Payments have a single reference (PAYID) with multiple payments.
By default, a transaction with Scheduled Payments will have a status “56 - OK with scheduled payments”. After the last scheduled instalment has been cleared, the transaction status will be “9 - Payment requested”.
In the event of an error with one of the scheduled payments, the transaction status will be “57 - Error on scheduled payments”. By default, if a scheduled payment is refused or has an error, the system will retry it once a day, for up to 10 days. If you wish to amend the retries for all future scheduled payments, please contact the helpdesk.
If the initial payment is refused, the transaction status will be 2 (refused), just as for a standard transaction, and no scheduled payments will be triggered.
5.2 ePDQ account
The transaction view page has a new button at the bottom, indicating how many scheduled payments are upcoming. Once a scheduled payment has been executed, it will appear in the list of operations for the order.
Clicking this button will take you to the following screen, where you have a detailed overview. If necessary, a “Delete” button allows you to cancel future occurrences.
5.3 Operation code
When performing scheduled payments, the initial payment will be processed using the Default Operation code as defined in the "Global transaction parameters" tab of your Technical information page.
Note: If you capture your initial payment after the next scheduled payment date, the scheduled payment in question will be triggered on that same day.
However, all subsequent (scheduled) payments will be processed as Direct Sales, irrespective of your configuration.
5.4 Maintenance operations
If you have performed your initial payment using the "Authorisation" operation code (transaction status is "5 - Authorised") you may cancel, capture and even partially capture the initial amount, but the scheduled payments will not be triggered until the initial amount has been fully processed. Please note also that partial cancellations are not supported.
If you have the option activated, you may refund a transaction completely or partially. Please note that if you perform a partial refund with the "last operation" checkbox ticked, the transaction status will be "8 - Refunded" and future scheduled payments will not be triggered. In other cases, as long as the transaction is in status 56, future occurrences will take place.
You can only refund an amount inferior or equal to what has already been captured.