Navigating Recurring Payments in India: A Backend Perspective

Summary

India’s October 2021 Reserve Bank of India (RBI) directive required recurring payments to use payer-authorized e-mandates, Additional Factor of Authentication (AFA), and pre-debit notifications at least 24 hours before charges. Shopify’s billing platform therefore had to model e-mandates, support recurring and one-time payments across cards and Unified Payments Interface (UPI), and integrate a local payment provider. The payment service reused its source object for the e-mandate token, recorded the temporary authorization as a charge for auditability, and refunded it asynchronously. To avoid two consecutive card authentication flows, the team used recurring-payment tokenization for both payment paths, accepting an atypical notification experience as a short-term trade-off; UPI required asynchronous webhook-driven handling and a hard mandate limit. After the beta launch, billing-payment success rates in India increased from pre-project levels, and the team said it would soon make UPI generally available to Indian merchants.

Context

The RBI directive introduced new requirements for recurring payments in India, including e-mandates registered through AFA, threshold-dependent authorization, and pre-debit notifications. Shopify’s payment service also needed to support recurring and one-time payments, cards and UPI, and a new local payment provider.

Approach / What changed

The team treated an e-mandate as a chargeable source whose remote_reference stored the provider token, while creating and asynchronously refunding a charge record for the temporary authorization’s audit trail. It used recurring-payment tokenization for both card payment paths, and relied heavily on provider webhooks for asynchronous UPI onboarding and payment handling.

Takeaways

• An e-mandate was modeled using the existing source object, with the provider’s token stored as remote_reference and a separate charge record retained for auditing the temporary authorization.
• Using one recurring-payment card token for both recurring and one-time payments avoided two consecutive AFA challenges, but produced an atypical notification experience for some one-time purchases.
• UPI onboarding and payments were more asynchronous than card flows because users approved notifications in their UPI applications, requiring the payment service to rely heavily on provider webhooks.

Related reading