When using Recurring Payments agreements it is important to consider the following time issues:
We calculate all times using GMT.
The end of the debit interval will be the last date of the month, when either debit intervals, or the start of the agreement, are:
In multiples of months or years (for example, when intervalUnit or startDelayUnit are 3 or 4)
And a debit is due on a date which does not exist, for example, 31 February 2008
When using Regular agreements, the end of the debit interval is when we will first attempt to debit the agreement.
When using Limited agreements, the end of the debit interval is the last date by which the debit can be initiated.
For Regular agreements the debit interval ends at 00:00.00 GMT.
For Limited agreements the debit interval ends at 23:59.59 GMT.
If timing is important in your application, use the transTime parameter as a basis for your calculations. This can be found in the Payment Notifications message (callback), which is generated when the agreement is created. You can then calculate when payments should normally be due, or when changes or debit requests can be attempted.
You could also use transTime, transStatus and desc in authorisation Payment Notifications messages (callbacks) to determine when attempts were made, whether they were successful or not, and to which payment they refer.
With Regular agreements, we attempt to debit the agreement sometime during the day on which it is due. If this is unsuccessful, we retry once a day for the following two days. If all three attempts fail, the agreement is suspended. It will remain suspended until the shopper amends the payment details in the Shopper Management System.
If a shopper amends the payment details associated with the agreement, any outstanding payments are attempted by us starting on the following day. One attempt is made each day, until either there are no outstanding payments, or there have been three consecutive failures. If all three attempts fail, the agreement is suspended.
When using option 1 or 3 with Limited agreements, a debit interval is applied, as shown in the following table.
intervalMult |
intervalUnit |
Maximum Interval Length Within Which noOfPayments May Be Taken |
1 |
1 |
Per 1 day |
1 |
2 |
Per 1 calendar week |
1 |
3 |
Per 1 calendar month |
1 |
4 |
Per 1 calendar year |
The number of partial or full intervals, within which noOfPayments may be taken, is defined by the duration of the agreement. This means between:
The time from when it starts
(Set using either startDelayUnit and startDelayMult, an explicit startDate, or from when the agreement is created if neither of these are specified)
To when it is cancelled or expires
(Set using either lengthUnit and lengthMult, an explicit endDate, or never if neither of these are specified)