- Getting Started
- Tutorials
- Reference
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Response Parameters
- Card On File
- Chargeback
- Transaction Workflows
- Result Codes
- Brands Reference
- Regression Testing
- Data Retention Policy
- API Reference
- FAQ
![Home](https://planetpaymentgateway.com/authentication/static/images/8a8394c44a58889a014abfe564bc376e.png)
Recurring Payment
You can perform recurring payments by just adding one additional parameter, standingInstruction
, to the payment request.
A recurring workflow consists of two phases:
- The initial payment request
- Subsequent payment requests
Sending the initial Payment
During the initial payment, marked by the parameter standingInstruction.mode
with the value INITIAL
, standingInstruction.type
with the value UNSCHEDULED
and standingInstruction.source
with the value CIT
, 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 PIPE you get this behaviour out of the box, so all you have to do is to follow the PIPE Integration guide and add to the /checkouts request in step 1 this parameter:
Use Case 1 :standingInstruction
parameters.
Using the server-to-server integration, you either have the option to append the parameter standingInstruction
to the initial /payments request that also stores the token like in this example:
![](/sites/default/files/ajax-loader.gif)
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 standingInstruction.mode=INITIAL
, standingInstruction.type=UNSCHEDULED
and standingInstruction.source=CIT
parameters 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 standingInstruction.mode
with the value REPEATED
, standingInstruction.type
with the value UNSCHEDULED
, standingInstruction.source
with the value MIT
and standingInstruction.initialTransactionId
with a value as ID received in the response of the initial CIT transaction. 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:
standingInstruction
parameters.
![](/sites/default/files/ajax-loader.gif)