3. Create Subsequent Payments

Available in🇮🇳 India

Once the customer’s mandate is registered and the token is in the confirmed state, you can execute subsequent payments (debits) against the mandate. Perform the following steps to charge your customer:

Create an Order to Charge the Customer
Create a Recurring Payment

3.1. Create an Order to Charge the Customer

You have to create a new order every time you want to charge your customers. This order is different from the one created when you initiated the mandate registration. Razorpay supports two types of flows for auto-debits: the coupled flow and the decoupled flow.

Coupled flow: You create the order and the payment together. Razorpay immediately sends the Pre-Debit Notification (PDN) to the customer, and schedules the debit and its retries.
Decoupled flow: You create the order first and send the notification object. You then create the payment after ensuring that a minimum of 24 hours has passed since the PDN was sent to the customer.

Handy TipsWe recommend choosing between the coupled and decoupled flow for your whole UPI Autopay integration on your merchant account. To maximise the collection success rate, you can use the coupled flow, as it needs the least intervention from your end.

Use the below endpoint to create an order: POST /orders

curl -u [YOUR_KEY_ID]:[YOUR_KEY_SECRET] \
-X POST https://api.razorpay.com/v1/orders \
-H "Content-Type: application/json" \
-d '{
   "amount":10000,
   "currency":"INR",
   "payment_capture": true,
   "receipt": "Receipt No. 1",
   "notification": {
     "token_id": "token_M7K2eFBU7vToaQ",
     "payment_after": 1634057114
   }
}'

$api = new Api($key_id, $secret);

$api->order->create(array('amount' => 100, 'payment_capture' => true, 'currency' => 'INR', 'receipt' => 'Receipt No. 1', 'notification' => array('token_id' => 'token_M7K2eFBU7vToaQ', 'payment_after' => '1634057114')));

var instance = new Razorpay({ key_id: 'YOUR_KEY_ID', key_secret: 'YOUR_SECRET' })

instance.order.create({
  "amount":1000,
  "currency":"INR",
  "payment_capture": true,
  "receipt": "Receipt No. 1",
  "notification": {
    "token_id": "token_M7K2eFBU7vToaQ",
    "payment_after": 1634057114
  }
})

client = razorpay.Client(auth=("YOUR_ID", "YOUR_SECRET"))

client.order.create({
    'amount': 1000,
    'payment_capture': True,
    'currency': 'INR',
    'receipt': 'Receipt No. 1',
    'notification': {'token_id': 'token_M7K2eFBU7vToaQ',
    'payment_after': 1634057114}
    })

import ( razorpay "github.com/razorpay/razorpay-go" )
client := razorpay.NewClient("YOUR_KEY_ID", "YOUR_SECRET")

data:= map[string]interface{}{
  "amount":1000,
  "currency":"INR",
  "payment_capture": true,
  "receipt": "Receipt No. 1",
  "notification": map[string]interface{}{
    "token_id": "token_M7K2eFBU7vToaQ",
    "payment_after": 1634057114,
  },
}
body, err := client.Order.Create(data, nil)

{
   "id":"order_1Aa00000000002",
   "entity":"order",
   "amount":10000,
   "currency":"INR",
   "receipt":"Receipt No. 1",
   "notification":{
     "token_id":"token_M7K2eFBU7vToaQ",
     "payment_after":1634057114,
     "id":"notification_00000000000001"
   },
   "status":"created",
   "attempts":0,
   "created_at":1455696638,
   "notes":[
      
   ]
}

Request Parameters

integer

required

Amount in currency subunits. For cards, the minimum value is 100 (₹1).

string

required

The 3-letter ISO currency code for the payment. Currently, we only support INR.

boolean

required

Determines whether the payment status should be changed to captured automatically or not. Possible values:

true: Payments are captured automatically.
false: Payments are not captured automatically. You can manually capture payments using the Manually Capture Payments API.

string

A user-entered unique identifier for the order. For example, Receipt No. 1. You should map this parameter to the order_id sent by Razorpay.

object

Details of the pre-debit notification. Use this object to decide between the coupled and decoupled flow. If you send this object, Razorpay does not automatically schedule the debit or its retries. If you do not pass this object, we automatically try to debit 25 hours after the pre-debit notification is delivered, and retry 3 times if the debit attempts fail.

Watch Out!We will not attempt any retry if the debit fails for tokens with the notification object in the created order. You should manually retry the debit attempt.

string

required

The token_id generated when the customer successfully completes the authorisation payment. Different payment instruments for the same customer have different token_id.

integer

required

UNIX timestamp post which the debit is supposed to happen. Mandatory for the decoupled flow.

3.2. Create a Recurring Payment

Once you have generated an order_id, use it along with the token_id to create a payment and charge the customer. Use the below endpoint to create a payment and charge the customer. POST /payments/create/recurring

curl -u [YOUR_KEY_ID]:[YOUR_KEY_SECRET] \
-X POST https://api.razorpay.com/v1/payments/create/recurring \
-H "Content-Type: application/json" \
-d '{
  "email": "gaurav.kumar@example.com",
  "contact": "9000090000",
  "amount": 1000,
  "currency": "INR",
  "order_id": "order_1Aa00000000002",
  "customer_id": "cust_1Aa00000000001",
  "token": "token_1Aa00000000001",
  "recurring": true,
  "description": "Creating recurring payment for Gaurav Kumar",
  "notes": {
    "note_key 1": "Beam me up Scotty",
    "note_key 2": "Tea. Earl Gray. Hot."
  }
}'

$api = new Api($key_id, $secret);

$api->payment->createRecurring(array('email'=>'gaurav.kumar@example.com','contact'=>'9000090000','amount'=>100,'currency'=>'INR','order_id'=>'order_1Aa00000000002','customer_id'=>'cust_1Aa00000000001','token'=>'token_1Aa00000000001','recurring'=> true,'description'=>'Creating recurring payment for Gaurav Kumar'));

var instance = new Razorpay({ key_id: 'YOUR_KEY_ID', key_secret: 'YOUR_SECRET' })

instance.payments.createRecurringPayment({
  "email": "gaurav.kumar@example.com",
  "contact": 9000090000,
  "amount": 100,
  "currency": "INR",
  "order_id": "order_1Aa00000000002",
  "customer_id": "cust_1Aa00000000001",
  "token": "token_1Aa00000000001",
  "recurring": true,
  "description": "Creating recurring payment for Gaurav Kumar",
  "notes": {
    "note_key 1": "Beam me up Scotty",
    "note_key 2": "Tea. Earl Gray. Hot."
  }
})

client = razorpay.Client(auth=("YOUR_ID", "YOUR_SECRET"))

client.payment.createRecurring({
    'email': 'gaurav.kumar@example.com',
    'contact': 9000090000,
    'amount': 1000,
    'currency': 'INR',
    'order_id': "order_1Aa00000000002",
    'customer_id': "cust_1Aa00000000001",
    'token': 'token_1Aa00000000001',
    'recurring': True,
    'description': 'Creating recurring payment for Gaurav Kumar',
    'notes': {'note_key 1': 'Beam me up Scotty',
              'note_key 2': 'Tea. Earl Gray. Hot.'}
    })

import ( razorpay "github.com/razorpay/razorpay-go" )
client := razorpay.NewClient("YOUR_KEY_ID", "YOUR_SECRET")

data:= map[string]interface{}{
  "email": "gaurav.kumar@example.com",
  "contact": "9000090000",
  "amount": 1000,
  "currency": "INR",
  "order_id": "order_1Aa00000000002",
  "customer_id": "cust_1Aa00000000001",
  "token": "token_1Aa00000000001",
  "recurring": true,
  "description": "Creating recurring payment for Gaurav Kumar",
  "notes": map[string]interface{}{
    "note_key 1": "Beam me up Scotty",
    "note_key 2": "Tea. Earl Gray. Hot.",
  },
}
body, err := Client.Payment.CreateRecurringPayment(data, nil)

require "razorpay"
Razorpay.setup('YOUR_KEY_ID', 'YOUR_SECRET')

para_attr = {
  "email": "gaurav.kumar@example.com",
  "contact": "9000090000",
  "amount": 1000,
  "currency": "INR",
  "order_id": "order_1Aa00000000002",
  "customer_id": "cust_1Aa00000000001",
  "token": "token_1Aa00000000001",
  "recurring": true,
  "description": "Creating recurring payment for Gaurav Kumar",
  "notes": {
    "note_key 1": "Beam me up Scotty",
    "note_key 2": "Tea. Earl Gray. Hot."
  }
}
Razorpay::Payment.create_recurring_payment(para_attr)

{
  "razorpay_payment_id" : "pay_1Aa00000000001",
  "razorpay_order_id" : "order_1Aa00000000001",
  "razorpay_signature" : "9ef4dffbfd84f1318f6739a3ce19f9d85851857ae648f114332d8401e0949a3d"
}

Once our system validates and successfully processes the payment request, a razorpay_payment_id is returned. In the case of some banks such as HDFC Bank and Axis Bank, the payment entity returned will be in the created state since the charge system of these banks are file-based and can take a few hours.

Request Parameters

string

required

The customer’s email address. For example, gaurav.kumar@example.com.

string

required

The customer’s phone number. For example, 9876543210.

integer

required

The amount you want to charge your customer. This should be the same as the amount in the order.

string

required

3-letter ISO currency code for the payment. Currently, only INR is allowed.

string

required

The unique identifier of the order created. For example, order_1Aa00000000002.

string

required

The customer_id for the customer you want to charge. For example, cust_1Aa00000000002.

string

required

The token_id generated when the customer successfully completes the mandate registration. Different payment instruments for the same customer have different token_id.

boolean

required

Determines if recurring payment is enabled or not.

true: Recurring Payment is enabled.
false: Recurring Payment is not enabled.

string

A user-entered description for the payment. For example, Creating recurring payment for Gaurav Kumar.

object

Key-value pair that can be used to store additional information about the entity. Maximum 15 key-value pairs, 256 characters (maximum) each. For example, "note_key": "Beam me up Scotty".

3.3 Razorpay Retries for Auto-Debits

NPCI allows up to 3 retries against a single pre-debit notification (PDN), so one PDN can carry up to 4 debit attempts in total: the first attempt and 3 retries. Who performs those retries depends on the flow you integrate with:

Who retries	Flow	How you set it up
Razorpay	Coupled (recommended)	Do not pass the `notification` object when you create the order. Razorpay raises the PDN, attempts the debit 25 hours later and runs the retries defined by your retry template, spacing them to stay outside NPCI peak hours.
You	Decoupled	Pass the `notification` object with `payment_after` to control the notification and the debit timing yourself. Razorpay does not retry a decoupled debit.

We recommend the coupled flow. Razorpay controls the debit timing on this flow, so we schedule retries around NPCI peak-hour restrictions and tune the retry pattern to your business. You can build both of these yourself on the decoupled flow, but it is additional work to set up and maintain. The decoupled flow is available if you need direct control over when each debit fires. If you use it, implement your own retry logic rather than treating the first failure as final. A debit that fails because of insufficient balance or a temporary bank issue often succeeds on a later attempt, and leaving that recovery on the table costs you revenue. When you get a final status. On the coupled flow, the payment stays in the created state from the moment the PDN is raised until an attempt succeeds or every retry is exhausted. Razorpay does not send a final status before that point, and how long this takes depends on your retry template. See 3.3.2. On the decoupled flow there are no Razorpay retries, so the result of each attempt arrives within 6 to 8 hours.

3.3.1 How Retries Work Against an Order

One order is one PDN. The order_id is what identifies the PDN. The razorpay_payment_id identifies a debit attempt against it.

Coupled flow: the debit and all its retries happen under a single razorpay_payment_id. That payment stays in the created state until an attempt succeeds or the retries are exhausted. You create one payment against the order, as described in 3.2. Do not create additional payments yourself, as they will fail.
Decoupled flow: you create each attempt as a fresh razorpay_payment_id against the same order_id. You can create up to 4 payment IDs against one order ID before the PDN’s allowance is exhausted.

NPCI allows one successful mandate execution under one PDN. In practice this means one successful debit per PDN for as_presented mandates, and one successful debit per billing cycle for fixed-frequency mandates. Once the retries against a PDN are used up, any further attempt needs a new order, which raises a new PDN. You can do this to continue recovering a genuinely collectable payment.

Wait for a final payment status before retryingOn the coupled flow, Razorpay’s retries may still be in flight while the payment sits in created. Do not start your own recovery (a fresh order and debit) until you have received a final status. Plan your collection process around the timings in 3.3.2.

3.3.2 Retry Templates

On the coupled flow, your retry behaviour is governed by a retry template. The template fixes how many attempts you get and how far apart they sit.

Template	Debit attempts	When retries are attempted	Final status by
Hourly retries (default)	3	1 hour and 2 hours after a failed debit	~42 hours
3 hourly retries	4	3, 6 and 9 hours after a failed debit	~42 hours
Daily (24 hours retries)	4	24, 48 and 72 hours after a failed debit	~120 hours (T+5)
No retries	1	No retry	~32 hours

All timings run from the PDN, which is raised 25 hours before the first debit attempt. The Final status by column already allows for attempts being deferred out of peak hours, so use it as the point at which to treat a payment as failed.

Handy Tips

The Hourly retries template is applied by default to every merchant onboarding onto UPI Autopay. If you have not asked for a different template, this is the one you are on.
A self-serve option on the Dashboard is planned. Until then, raise any template revision request with the Razorpay Support team.
A template change applies to fresh PDNs raised after the change. A debit already in progress finishes on the template it started on.

3.3.3 Recommended Templates by Business Type

Choose the template that fits how your business collects. The table below gives a starting point for lending, investments and insurance.

Business	Recommended template	Why
Lending (EMI collection)	Hourly retries or No retries	Gives a final status the same day, so dunning, field collection and internal reporting can act on the failure without waiting on a long retry chain.
Investments (SIP instalments)	Daily (24 hours retries)	Spreading attempts over 24, 48 and 72 hours gives the customer’s balance time to be topped up and catches salary-credit and payday cycles. Plan for a final status up to T+5.
Insurance (premium collection)	3 hourly retries	Uses the full retry allowance within roughly a day and a half, recovering across the whole debit day without waiting until T+5.

These MCCs are exempt from the peak-hour restriction (see 3.3.4), so their attempts run at the scheduled time. If you are not sure which template fits your use case, reach out to Razorpay Support.

3.3.4 Peak Hours

NPCI circular OC 215A restricts UPI Autopay debit attempts and their retries during two windows each day. This does not affect mandate registration journeys.

Peak window (IST)
10:00 to 13:00
17:00 to 21:30

An attempt that falls inside a peak window is rescheduled to the next non-peak slot. Deferred attempts are not all released at the moment the window closes, because that would simply move the load spike to 13:00 and 21:30. Razorpay queues them FIFO, in the order the requests arrive, and spaces them across the available non-peak hours so the debits do not overload the gateway when the window reopens. How this plays out depends on your flow:

Coupled flow: an attempt due between 10:00 and 13:00 runs the same afternoon or the same night. An attempt due between 17:00 and 21:30 runs overnight. You receive a payment ID and an order ID straight away. What follows, either a further retry being scheduled or the final payment status webhook being fired, happens once the attempt has been processed in its turn.
Decoupled flow: your request is acknowledged immediately with a payment ID and an order ID, and the debit itself fires once the window closes. A decoupled debit stays bounded to 6 to 8 hours.

The following are exempt from the peak hour restriction:

The first debit at mandate registration, within 5 minutes of registration.
Any execution the customer authenticates with their UPI PIN, including AFA collect requests on debits above the threshold for your category. See the AFA limits in Best Practices.
FASTag auto top-up (MCC 4784).
RuPay NCMC auto top-up (MCC 7412).
Insurance (MCC 5960, 6300, 6381, 6399, 6529).
Security brokers (MCC 6211).
Financial institutions, merchandise and services (MCC 6012).
Loan repayment (MCC 7322).

Exemptions are in effect until further notice and can be withdrawn by NPCI.

Handy TipsOn the coupled flow you control when the PDN goes out and therefore when the debit is attempted 25 hours later, but you do not control the retries. Razorpay schedules those against your template, and they can still fall inside a peak window and be deferred. On the decoupled flow you control the PDN, the debit and the retry timings, so you can plan all three around the peak windows yourself.NPCI has not yet applied the peak-hour restriction to pre-debit notifications. When it does, Razorpay will automatically defer PDNs raised during a peak window to the next non-peak slot for the applicable MCCs, so no change is needed at your end.

3.3.5 Confirming Payment and PDN Status

When you create a recurring payment, a razorpay_payment_id is returned once the request is accepted. Treat that as an acknowledgement, not an outcome. The debit result arrives later, by webhook or through the Fetch Payment API.

What you want to know	How to confirm it
The debit succeeded	`payment.captured` and `order.paid` webhooks. See Check Payment Status using Webhooks.
The debit failed	`payment.failed` webhook. On the coupled flow this arrives once all retries are exhausted. On the decoupled flow there are no Razorpay retries, so it usually arrives within a few hours.
The PDN was delivered	`order.notification.delivered` webhook.
The PDN failed to deliver	`order.notification.failed` webhook. Re-trigger another notification before attempting a fresh debit.
Current state, at any point	Fetch Payment API, using the `razorpay_payment_id`.

Handy TipsThe order.notification.delivered and order.notification.failed webhooks currently fire only if you passed the notification object when creating the order, that is, on the decoupled flow. Support for coupled flow merchants is coming soon. On the coupled flow, Razorpay handles the PDN and the debit together, and the debit is attempted 25 hours after delivery. See Check Notification Status using Webhooks.Set your dunning schedules, ledger posting and customer communication to the payment and order webhooks rather than to the moment you created the order. On Daily (24 hours retries), a debit raised on the 1st may not reach a final status until the 5th. If your billing cycle closes on the 3rd, you will be reporting instalments as missed while they are still being recovered.

3.4 Error Scenarios

For the error reasons of a failed auto-debit and the recommended next steps, refer to UPI Error Codes.

3.5 Best Practices

Best Practices

For Recurring Payments, it may take between 24-36 hours for the subsequent payment to reflect on your Dashboard.
This is because of the failure of pre-debit notification and/or any retries that we attempt for the payment.
Do not create another subsequent payment until you get the status of the previous one.
NPCI allows only one successful debit on a token per billing cycle. For example, if the billing frequency is monthly, you can execute only one successful debit per month on that token.
The subsequent payment may fail if there is late authorisation of an earlier payment.
For mandates with fixed frequency, do not create orders on the last day of the billing cycle. Doing so will fail the debit.
Always check the token status before attempting the debit. If the token is not confirmed, do not attempt the debit.
Razorpay sends the pre-debit notification immediately when you submit the Create Order API. We recommend timing the notification as per the customer’s billing cycle.
Sometimes the customer modifies the token after you send the pre-debit notification. In such cases, you immediately receive the corresponding status change webhook and the payment moves to the failed state.
For coupled flow merchants, the payment remains in the created state until the debit is attempted and the payment succeeds or all retries are exhausted. Since Razorpay schedules the debits and retries, wait for the final payment status before taking a call on the subscription status of the customer. Depending on your retry configuration, this can take between T+1 and T+5 days.
If the debit amount exceeds ₹15,000 for regular industries (or ₹1,00,000 for lending and investment categories), the customer will receive a collect request on their UPI app and must enter their PIN to approve the payment. Ensure your system handles this Additional Factor of Authentication (AFA) flow gracefully.

Features

JSON

3. Create Subsequent Payments

3.1. Create an Order to Charge the Customer

Request Parameters

3.2. Create a Recurring Payment

Request Parameters

3.3 Razorpay Retries for Auto-Debits

3.3.1 How Retries Work Against an Order

3.3.2 Retry Templates

3.3.3 Recommended Templates by Business Type

3.3.4 Peak Hours

3.3.5 Confirming Payment and PDN Status

3.4 Error Scenarios

3.5 Best Practices

​3.1. Create an Order to Charge the Customer

​Request Parameters

​3.2. Create a Recurring Payment

​Request Parameters

​3.3 Razorpay Retries for Auto-Debits

​3.3.1 How Retries Work Against an Order

​3.3.2 Retry Templates

​3.3.3 Recommended Templates by Business Type

​3.3.4 Peak Hours

​3.3.5 Confirming Payment and PDN Status

​3.4 Error Scenarios

​3.5 Best Practices

3.1. Create an Order to Charge the Customer

Request Parameters

3.2. Create a Recurring Payment

Request Parameters

3.3 Razorpay Retries for Auto-Debits

3.3.1 How Retries Work Against an Order

3.3.2 Retry Templates

3.3.3 Recommended Templates by Business Type

3.3.4 Peak Hours

3.3.5 Confirming Payment and PDN Status

3.4 Error Scenarios

3.5 Best Practices