Recurring Payment is a feature that allows merchants to charge customers periodically for products or services that work on a subscription basis. After the customer makes an initial purchase as usual, the merchant can charge the customer periodically without any cooperation required on the customer side.

Prerequisites

1. The customer must make the initial payment using one of the following payment methods: • Invoices • Loans • Card Payments • Part Payments

2. The merchant must declare in advance that the recurring payment option should be offered to the customer by setting the OfferRecPmt flag in the InitializePayment API call to true.

3. The customer must give a consent to be charged periodically by checking a checkbox when filling the check-out form. The checkbox can be made checked by default in which case it is enough if the customer does not uncheck it explicitly.

Workflow

When the customer has finished shopping and is about to procceed to check-out, the merchant should inspect contents of the customer’s shopping cart and decide whether it is a single-time purchase or if there should be recurring payments in the future. The first case would be a normal payment as described elsewhere in the documentation. This article only deals with the second case.

The Initial Payment

1. Same as with single-time payments, the merchant initializes the payment session by calling the InitializePayment API method. The only difference is that in this case, the OfferRecPmt flag must be set to true.
2. The customer fills-in all the information required and optionally checks a checkbox that authorizes recurring payments. The checkbox might have been checked by default in which case it is enough if the customer lets it as it is.
3. The check-out form triggers an event informing the hosting website that the check-out session has been completed.
4. The merchant makes a GetPaymentStatus API call to get the payment status, same as for normal payments.

• If the customer has authorized recurring payments, the response will contain a token. The merchant must store the token value to be able to make recurring payments in the future.
• If the customer did not authorize recurring payments, it is not possible to make any additional payments without the customers consent and the workflow ends at this point. Still, the merchant should check the whole response because the initial payment might have gone through, thus obligating the customer to e.g. a one-month subscription of a particular product.

Subsequent Payments

When it is time to charge the customer again, the merchant must actively initiate a subsequent payment by calling the AuthorizeRecurringPayment API method. Avarda Online is a passive component in this case that only approves or rejects requests made by merchants.

Merchants must provide the token acquired during the initial payment. Without the token no subsequent payment can be made. Thanks to this concept, merchants don’t need to store sensitive information such as personal details or card numbers.

The token is valid for any number of subsequent payments. A recurring payment does not invalidate given token nor does it create a new one. The merchant must specify a list of items and a price same as for the initial payment. However, different set of items can be specified for each recurring payment and the total price may also be different each time.

Limitations

There are certain limitations enforced by Avarda Online regarding Recurring Payments:

• The frequency at which the customer can be charged by merchant automatically is limited to one of the following options, depending on individual conditions for each merchant monthly, weekly or daily
• The maximum amount chargeable in each recurring payment is 150% of the value of the original purchase value.
• If the initial payment has been made using a card, recurrent payments will be possible only up to the card expiration date.