Recurring Payment

You can perform recurring payments by just adding one additional parameter, recurringType, to the payment request.

A recurring workflow consists of two phases:

  1. The initial payment request
  2. Subsequent payment requests

Sending the initial Payment

During the initial payment, marked by the parameter recurringType with the value INITIAL, the customer is present. Therefore this initial request should contain additional parameters that authenticate the customer like card.cvv for card payments, and also additional checks like 3D secure can be executed.

In SecurePay you get this behaviour out of the box, so all you have to do is to follow the SecurePay Integration guide and add to the /checkouts request in step 1 this parameter:


Using the server-to-server integration, you either have the option to append the parameter recurringType to the initial /payments request that also stores the token like in this example:

For some cases you might want to use an alternative approach: If the shopper just registered his data without sending a payment at the same time you would have sent his payment directly to the /registrations endpoint as described here. In the same way as described above, the recurringType=INITIAL parameter can be added to the request to indicate that this is the first in a series of recurring payments.

You can find more details on the server-to-server option using either /payments or /registrations in the the tokenisation tutorial.

Sending a repeated payment

Any payment request following the initial one has to have the parameter recurringType with the value REPEATED. This flag not only indicates that the request is part of a series of payments on this account, but also tells the payment system that no user is present and therefore parameters like card.cvv or the 3D authentication shouldn't be present. This fact in combination with the stored payment data of the registration greatly reduces the number of parameters of such a request: