Recurring card payments in India

You can accept recurring card payments in India for the following types of payments:

• Subscriptions: A recurring transaction made at regular intervals for a product or a service. These payments use the Subscription recurring processing model.
• Automatic top-ups: Contracts that occur on a non-fixed schedule using stored card details. This includes automatic top-ups when the cardholder's balance drops below a certain amount. These payments use the UnscheduledCardOnFile recurring processing model.

To process recurring card payments in India, you need to perform some extra steps:

• You provide information about the shopper's billing plan in the payments request.
• Based on this information, the shopper creates a mandate between them and their issuer.
• You initiate a pre-debit notification before you charge the shopper.

How it works

Set up a recurring contract and a mandate:

1. In your payment form, a shopper selects their card and fills in their details.
2. You send a /payments request, specifying the required details to set up a recurring contract and mandate.
3. The shopper is redirected to the issuer and performs 3D Secure 2 authentication.
4. The shopper is redirected back to your website.
5. You send a /payments/details request, and include the data that you received in the /payments response.
6. You get a response from the /payments/details request. When the result is successful, the mandate is created and you can start processing recurring Subscription or UnscheduledCardOnFile payments for your shoppers.

Use the recurring contract to make a payment:

1. Notify the issuer that you will charge the shopper. We recommend that you do this at least 72 hours before you intend to charge the shopper.
2. At least 24 hours before the recurring charge, the issuer sends the shopper a pre-debit notification that the recurring amount will be charged. To send a notification to the shopper, the issuer can use an SMS, or an e-mail, for example.
3. You send a /payments request, specifying the required details to make a recurring payment.

Set up a recurring contract

To start a recurring contract for a shopper, you need to store their payment details and create a mandate with their issuer. The issuer uses this mandate to have visibility of the shopper's recurring payments. They can then let the shopper cancel (or pause/unpause) the mandate on their side.

In the examples on this page, you set up a subscription for a shopper.

Make a payment

Make a POST /payments call, including:

Field	Required	Description
paymentMethod.type		scheme
paymentMethod.encryptedCardNumber		The shopper's encrypted card number.
paymentMethod.encryptedExpiryYear		The shopper's encrypted card expiry year.
paymentMethod.encryptedExpiryMonth		The shopper's encrypted card expiry month.
paymentMethod.encryptedSecurityCode		The shopper's encrypted card CVC.
paymentMethod.holderName		The name on the shopper's card.
mandate.amount		The amount the shopper will be charged per recurring debit in minor units. Must be more than or equal to the transaction amount. The recurring charge does not need to go through 3D Secure authentication if the amount is less than or equal to INR 15,000.
mandate.amountRule		Possible values: max (default) and exact. max - The shopper can be charged any amount between INR 1 to the amount in the amount field. exact - The shopper can only be charged the amount in the amount field.
mandate.frequency		The frequency at which the shopper will be charged. Possible values: monthly and adhoc.
mandate.startsAt		Start date of the billing plan, in YYYY-MM-DD format. The default value is the transaction date.
mandate.endsAt		End date of the billing plan, in YYYY-MM-DD format.
mandate.remarks		Limited to 50 characters, no special characters.
browserInfo		The shopper's browser information.
shopperEmail		The shopper's email address.
shopperIP		The shopper's IP address.
storePaymentMethod		Set to true to store shopper's payment details.
shopperInteraction		Set to Ecommerce.
recurringProcessingModel		Possible values: Subscription or UnscheduledCardOnFile.
shopperReference		The shopper reference associated with the billing plan (minimum length three characters).

The details in the mandate object are used to create the mandate for the shopper's billing plan.

The /payments response is:

The response contains an action object. Your next step is to Handle the redirect.

Handle the redirect

Handling the redirect is similar to handling a regular 3D Secure redirect, but with a few differences for recurring card payments in India:

• Testing
  To test the 3D Secure 2 authentication flow, you can use a test card and static One Time Password (OTP) from the Test and go live section.
• Mandate details returned in the response
  You will receive the mandate details as additional data in the /payments/details response.

For more detailed information about handling the redirect in the different integration types, see:
Web Drop-in
Web Component
iOS Drop-in
iOS Component
Android Drop-in
Android Component
API only

If the payment was successful, the shopper created the mandate with their issuer, and you will get a /payments/details response with:

• resultCode: Authorised

• additionalData.recurring.recurringDetailReference: The token for the saved payment details. You will need this to make future payments for the shopper.

  To get the recurringDetailReference synchronously in your payments response, you have to enable this feature.

• additionalData.mandate: The details on the shopper's mandate. This contains the mandate details that you provided in your request, as well as:

  • mandate.mandateId: This field will include the identifier for the mandate created by the issuer. Currently, this is a placeholder field and we return an empty string as the value. When issuers start passing the mandateId, we will return the value in this field.
  • mandate.providerId: The ID returned by the provider.
  • mandate.status: The status of the mandate.
  • mandate.txVariant: The transaction variant.

• pspReference: Our unique identifier for the transaction.

You will need the recurringDetailReference and shopperReference to make subsequent payments.

Present the payment result

Use the  resultCode from the /payments/details response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.

You can receive the following resultCode values:

Webhook

You'll receive a webhook with the final status of the payment.

You can receive the mandate details as part of your standard webhooks. To do this:

1. In your Customer Area, go to Developers > Webhooks.
2. Next to Standard webhook, select the edit webhook icon .
3. Under Additional Settings, select Include Mandate Details.
4. Select Save Configuration.

Make recurring payments

For every subsequent payment in a billing plan, for example a subscription, you need to:

1. Initiate a pre-debit notification.
2. Make the recurring payment.

Initiate a pre-debit notification

A pre-debit notification is an email or SMS notification sent to a shopper to inform them of their impending billing plan charge. You need to inform the issuer when the notification needs to be sent out and subsequently the issuer sends the email or SMS. When they receive the notification, shoppers can choose to cancel the mandate. Shoppers receive the pre-debit notification at least 24 hours before every recurring payment in the billing plan.

To send a pre-debit notification to your shopper, make a POST call to /notifyShopper:

• storedPaymentMethodId: The token for your shopper's stored payment details.
• merchantAccount: Your merchant account associated with the shopper's stored payment details.
• shopperReference: The shopper reference associated with the billing plan.
• amount: The amount you are going to charge the shopper. If you have configured max for the mandate.amountRule, the shopper can be charged any amount between INR 1 to the amount in the mandate.amount field. If you have configured exact, the shopper can only be charged the amount in the mandate.amount field.
• billingDate: The date the shopper will be charged.
• reference: The notification reference. This field is shown to the shopper if the displayedReference field is left blank or is not sent.
• displayedReference: Optional. The reference shown to the shopper in the pre-debit notification they receive from their issuer. If this field is left blank or is not sent, the reference field will be shown instead.

The /notifyShopper response contains:

• message: Information about the status of the pre-debit notification.
• shopperNotificationReference: Unique reference to the pre-debit notification. Store this value to make the subsequent payment.

If the /notifyShopper request fails, you will receive a response with resultCode set to Refused.

If there was an issue with the /notifyShopper request, you will receive a response containing an errorCode and a message explaining the error. For a list of possible values, refer to Generic error codes.

Make a recurring payment

Once the shopper has received the pre-debit notification, you can carry out a recurring payment, for example for a subscription.

1. To do so, make a POST /payments call, including:

   Field	Required	Description
   amount		Include the currency and value of the shopper's subscription payment.
   paymentMethod.type		scheme
   paymentMethod.storedPaymentMethodId		The token value for the shopper's stored payment information.
   paymentMethod.shopperNotificationReference		Unique reference to the pre-debit notification from the /notifyShopper response.
   shopperEmail		The shopper's email address.
   shopperIP		The shopper's IP address.
   merchantAccount		Your merchant account
   shopperReference		The shopper reference associated with the subscription.
   shopperInteraction		Set to ContAuth.
   recurringProcessingModel		Set to Subscription or UnscheduledCardOnFile.

2. The /payments response contains:

   • resultCode: Authorised

   If the payment is not successful, the resultCode will be Refused.

3. You'll receive a webhook with the final status of the payment.

   eventCode	success field	Description	Action to take
   AUTHORISATION	false	The transaction failed.	Cancel the order and inform the shopper that the payment failed.
   AUTHORISATION	true	The shopper successfully completed the payment.	Inform the shopper that the payment has been successful and proceed with the order.

Cancel a mandate

If a shopper has ended their mandate with their issuer, you will receive a webhook with the eventCode DISABLE_RECURRING.

If a shopper contacts you to cancel their mandate, you have to send a request to Adyen to cancel that shopper's mandate. We are working on an endpoint so you can do this directly, but for now you can contact our Support Team. Adyen will then send a request to the issuer to cancel the mandate.

Test and go live

You can use the following test card numbers:

Card number	Static OTP	Expiry	CVV	Type	Country/region	3DS enrolled
6071489876543261		12/2029	123	RuPay test card	IN
5400000000000005	123456	12/2029	123	Mastercard test card	IN
5400000000000013	123456	12/2029	123	Mastercard test card	IN
4000000000000002	123456	12/2029	123	Visa test card	IN
4000000000000010	123456	12/2029	123	Visa test card	IN
36000000000008	123456	12/2029	123	Diners test card	IN
370000000000010	123456	12/2029	123	Diners test card	IN
370000000000002	123456	12/2029	123	American Express test card	IN
36000000000016	123456	12/2029	123	American Express test card	IN

To receive the recurringDetailReference synchronously in the payments response in your test environment, do the following:

1. Log in to your test Customer Area.
2. Go to Developers > Additional data.
3. Select Recurring details and save your settings.

You can enable receiving the RECURRING_CONTRACT event code as part of your standard webhooks. For instructions, see non-default event codes and additional settings.

Before going live, make sure to go to your live India Customer Area and follow the exact instructions as described above.

See also