Orca

UPI (Unified Payments Interface) ยท a product on this rail

Recurring UPI payment taken under a mandate

A product on UPI (Unified Payments Interface), derived by the build from 16 rules, 1 authorisation, 5 states and 0 code sets that already exist in the corpus. Nothing here is hand-written.

Rail in-upi, governed by Reserve Bank of India. Snapshot 2026-09-20, built 2026-09-26, commit 019924ac64ee0aa0742b8f02a04488a83633385d. Data: data/products/in-upi/recurring.json.

What it is

Corroborated (authoritative primary) The name and summary are the TransactionType record's own, with its own status. This product is derived by the build from 23 records that already exist (2 draft, 21 corroborated; strongest source class authoritative primary), and the page carries no status, confidence or corroboration of its own.

A payment taken again and again from the customer's account on a standing authorisation. The Reserve Bank's recurring payment framework says in its own applicability paragraph that it covers recurring transactions made using UPI, and sets how the mandate is registered and withdrawn, what notice the customer gets before and after each charge, and above what amount the customer must authenticate again.

Anchor
an authorisation of its own, a lifecycle of its own (5 states)
Effective since
2026-04-21
Confidence
medium
Record
in-upi:txn.recurring

Who can use it

  • Customer (the payer) party; gives the authorisation
  • Merchant (the payee in a payment for goods or services) party; receives the authorisation, bound by its rules
  • Payment System Participant (a member of an authorised payment system) institution; bound by its rules
  • Remitter bank (the payer's bank) institution; bound by its rules
  • Third party application provider (TPAP) service_provider; bound by its rules

How it is authorised

UPI recurring payment mandate Corroborated (authoritative primary)

A standing authorisation a customer gives so that money can be taken from their account again and again, which the Reserve Bank's recurring payment framework says covers UPI as well as cards and prepaid instruments. It is registered once behind an additional factor of authentication, carries a validity period the customer can change, and can be withdrawn at any time behind the same authentication. It may be for a fixed amount or for a varying one within a cap the customer sets. The customer is told at least a day before each charge, can opt out of that charge or of the mandate, and is told again after it. Nothing may be charged for having one.

Form
electronic, registered once with the issuer behind an additional factor of authentication
Scope
  • recurring
  • fixed amount
  • variable amount within a customer set maximum
Given by
Customer (the payer)
Given to
Merchant (the payee in a payment for goods or services)
Governed by
The recurring payment framework covers UPI; The first charge under a mandate is authenticated; The customer is told at least a day before each recurring charge; The customer is told after each recurring charge; Recurring payments up to 15,000 rupees need no fresh authentication; Three kinds of recurring payment have a 1,00,000 rupee threshold instead; A recurring mandate costs the customer nothing, and the acquirer answers for its merchants
Cancelled through
Registering a recurring mandate, and getting out of one; UPI AutoPay: revoking a mandate, from either side
Evidenced by
Registering a recurring mandate, and getting out of one
Disputed through
Claim that the customer did not authorise the payment shared with the rail
Record
in-upi:mandate.upi-recurring

States Orca holds

  1. UPI recurring e-mandate: registered Corroborated (authoritative primary)

    The customer has completed the one-time registration and passed the additional factor of authentication, so the issuer holds a live mandate with a stated validity period. Recurring charges may now be taken under it, each announced at least 24 hours ahead; the first charge needs the additional factor too, unless it was taken together with registration. While registered, the customer may change the validity period, and a variable mandate carries the ceiling the customer chose for any single charge.

    Money moved: no. Then: UPI recurring e-mandate: withdrawn by the customer; UPI AutoPay mandate: paused; UPI AutoPay mandate: revoked; UPI AutoPay mandate: expired. in-upi:state.e-mandate-registered

  2. UPI recurring e-mandate: withdrawn by the customer Corroborated (authoritative primary)

    The customer has taken the mandate back, either through the facility the issuer must offer for withdrawing it at any time or by opting out of the whole mandate from a pre-charge notice. Either way the issuer confirms it with the additional factor of authentication and tells the customer it is done. No further charge may be taken under it. Opting out of a single charge is different: the mandate stays registered.

    Terminal. Money moved: no. in-upi:state.e-mandate-withdrawn

  3. UPI AutoPay mandate: paused Draft, unchecked

    The customer has put the mandate on hold, so the debit it would otherwise produce does not go ahead, but the mandate itself survives. NPCI counts opting out of one particular debit as this same pause. The customer can get here from their bank, from their UPI app (unless the mandate is for loan payments or EMI collection) or through UPI HELP, and is told by SMS and in the app. Lifting the pause, which NPCI calls unpause or resume, returns the mandate to its registered state; it can also still be revoked, and it lapses anyway if its validity period runs out.

    Money moved: no. Then: UPI recurring e-mandate: registered; UPI AutoPay mandate: revoked; UPI AutoPay mandate: expired. in-upi:state.upi-autopay-paused

  4. UPI AutoPay mandate: expired Corroborated (authoritative primary)

    The mandate's validity period has come to an end, so it is no longer valid and no debit can be taken under it. Nobody has to act for this to happen: the end date set at registration, or changed later by the customer, does it, and no AutoPay mandate can run for more than 30 years. NPCI's list of operations the customer must be told about does not include expiry for AutoPay, so the customer may not hear about it.

    Terminal. Money moved: no. in-upi:state.upi-autopay-expired

  5. UPI AutoPay mandate: revoked Corroborated (authoritative primary)

    The mandate has been ended through the UPI AutoPay channel and no further debit may be taken under it. This is UPI's own name for the end of a mandate, whichever side the request came from: the customer's bank, the customer's UPI app (not offered there for loan payments or EMI collection), UPI HELP, or the merchant's own website or app. A request made on the merchant's platform must be passed into the AutoPay channel, so the mandate ends at the bank as well, and it needs no additional factor of authentication under UPI's rules. The customer is told by SMS and in the app. Any member that later finds an operation failing because the mandate is revoked deletes its own copy. The Reserve Bank's withdrawal by the customer is one way of reaching this state.

    Terminal. Money moved: no. in-upi:state.upi-autopay-revoked

The states listed are the ones Orca holds for this product, in the order their own records give; a state the corpus does not hold is a gap, not an absence.

Its own codes

No code set or reason code of its own is held for this product.

Timings and limits

RuleParameterAs typed on the record
Recurring payments up to 15,000 rupees need no fresh authentication Corroborated (authoritative primary)limit15,000 rupees per recurring transaction without an additional factor of authentication
Three kinds of recurring payment have a 1,00,000 rupee threshold instead Corroborated (authoritative primary)limit1,00,000 rupees per transaction for insurance premiums, mutual fund subscriptions and credit card bill payments

Its rules, by facet

16 Rules, each in its record's own words with its own status. A rule reached only through the authorisation says so; a rule that also applies to another transaction type names it.

Limits 3

Recurring payments up to 15,000 rupees need no fresh authentication Corroborated (authoritative primary)

A recurring payment under a mandate may go through without an additional factor of authentication up to 15,000 rupees. Above that the customer must authenticate again.

Rests on rule. Confidence high. in-upi:rule.e-mandate-authentication-threshold

Three kinds of recurring payment have a 1,00,000 rupee threshold instead Corroborated (authoritative primary)

Insurance premiums, subscriptions to mutual funds and credit card bill payments may be taken under a mandate without an additional factor of authentication up to 1,00,000 rupees a transaction, rather than the ordinary 15,000.

Rests on rule. Confidence high. in-upi:rule.e-mandate-higher-threshold-for-three-categories

UPI AutoPay: a mandate lasts at most 30 years and lapses at its end date Corroborated (authoritative primary)

No AutoPay mandate is open-ended. Each one is registered with a validity period, and the payee PSP must keep that period to 30 years or less. When the customer sets the mandate up, the merchant's flow must let them change the end date, and afterwards the customer's bank must let them change the validity period whenever they like, having told them at registration that they can. When the period runs out, NPCI's glossary treats the mandate as expired and no longer valid, with no act by either side needed to end it.

Rests on rule. Confidence high. in-upi:rule.upi-autopay-validity-and-expiry

Recall 2

UPI AutoPay: pausing a mandate and lifting the pause Corroborated (authoritative primary)

On UPI a customer can hold back debits under an AutoPay mandate without ending it: NPCI treats opting out of a particular debit and pausing the mandate as one facility, and lifting it again is called unpause (resume in the UPI HELP section). The customer's UPI app must offer the pause, except on mandates in the Loan Payments and EMI Collection categories, where that duty on the app does not apply. The customer's own bank must offer it with no such exception written. NPCI's UPI HELP assistant may also start a pause or a resume, and must then hand the customer to the ordinary AutoPay confirmation screen. On the other side, the payee PSP must make sure every merchant that takes AutoPay payments can cope with a paused mandate. The circular sets no maximum length for a pause and does not say whether one pause may cover several debits.

Rests on rule. Confidence medium. in-upi:rule.upi-autopay-pause-and-unpause

UPI AutoPay: revoking a mandate, from either side Corroborated (authoritative primary)

An AutoPay mandate can be ended from the merchant's side as well as the customer's. Whatever kind of business the merchant is, its payee PSP must see that the customer can revoke from the merchant's own website or app, and the revocation must travel through the UPI AutoPay channel so the mandate ends everywhere, not merely vanish from the merchant's records. A withdrawal made on the merchant's platform needs no additional factor of authentication under UPI's rules. On the customer's side the bank must offer revocation, the customer's UPI app must offer it except on Loan Payments and EMI Collection mandates, and UPI HELP may start one and then pass the customer to the usual AutoPay confirmation screen. Once any member finds a mandate operation failing because the mandate has been revoked or does not exist, it must delete the mandate from its own systems too.

Rests on rule. Confidence medium. in-upi:rule.upi-autopay-revocation

Liability 1

Disputes on a recurring payment, and who bears an unauthorised one Corroborated (authoritative primary)

The issuer must run a way for the customer to complain about a recurring payment. The Reserve Bank's instructions on limiting a customer's liability for unauthorised transactions apply to recurring payments taken under a mandate just as they do to any other.

Rests on rule. Confidence high. in-upi:rule.e-mandate-disputes-and-liability

Consumer law 7

A recurring mandate costs the customer nothing, and the acquirer answers for its merchants Corroborated (authoritative primary)

No charge may be put on the customer for having a recurring mandate. Where cards are involved an existing mandate can be carried over to a reissued card. An acquirer must see to it that the merchants it has taken on comply with the directions.

Rests on rule. Confidence high. in-upi:rule.e-mandate-costs-the-customer-nothing

The first charge under a mandate is authenticated Corroborated (authoritative primary)

The first payment under a recurring mandate needs an additional factor of authentication. Where that first payment is taken at the same time as the mandate is registered, one authentication may serve both. Payments made under a mandate are not subject to any other limits or controls the customer has set.

Rests on rule. Confidence high. in-upi:rule.e-mandate-first-charge

The customer is told after each recurring charge Corroborated (authoritative primary)

After taking the money the issuer must tell the customer, naming at the least the merchant, the amount, the date and time of the debit, the reference numbers of the transaction and of the mandate, the reason for the debit, and how to complain.

Rests on rule. Confidence high. in-upi:rule.e-mandate-notice-after-each-charge

The customer is told at least a day before each recurring charge Corroborated (authoritative primary)

The issuer must tell the customer at least twenty four hours before it actually takes the money. The notice must at the least name the merchant, the amount, the date and time of the debit, the mandate's reference number and the reason for the debit, which is the mandate the customer registered. The customer must be able to opt out of that one payment or of the mandate altogether, with the opt-out confirmed by an additional factor and acknowledged. The notice is not required where the mandate exists only to top up a toll tag or a national common mobility card.

Rests on rule. Confidence high. in-upi:rule.e-mandate-notice-before-each-charge

Registering a recurring mandate, and getting out of one Corroborated (authoritative primary)

A customer who wants recurring payments registers once, and the mandate takes effect only after an additional factor of authentication on top of whatever the issuer normally asks. Every registered mandate carries a validity period, and the issuer must give the customer a way to change that period or withdraw the mandate at any time, and must say so clearly when the mandate is set up. A mandate may be for a fixed amount, or for a varying amount within whatever overall cap the Reserve Bank has set, and for a varying one the customer must be able to set the largest single charge. The customer chooses how they are told before a charge. Changing or withdrawing a mandate needs the additional factor again.

Rests on rule. Confidence high. in-upi:rule.e-mandate-registration-and-withdrawal

UPI AutoPay: the customer hears about every change to a mandate, twice Corroborated (authoritative primary)

Each thing that happens to an AutoPay mandate reaches the customer through two channels: an SMS from their bank and a notification from their UPI app. That covers the mandate's own life (setting it up, changing it, pausing it, lifting the pause, revoking it) as well as each debit (the notice before it, the debit itself and the notice after it). Expiry at the end of the validity period is not on the list for AutoPay.

Rests on rule. Confidence high. in-upi:rule.upi-autopay-every-mandate-event-is-notified

UPI AutoPay: changing a live mandate's amount or payee Draft, unchecked

A registered AutoPay mandate can be changed without being cancelled and set up again, and the change leaves it live. The amount is changed on the merchant's side: the payee PSP must see that its merchants give the customer a way to do it. The end date is changed through the customer's bank, under the validity rule. The merchant's own UPI ID on a mandate is different: a merchant may move to a new UPI ID while keeping its merchant identifier code and every other mandate term, but the payee PSP may let the payee UPI ID on an active mandate change only when a regulator directs it or the payee PSP stops offering the service.

Rests on rule. Confidence medium. in-upi:rule.upi-autopay-modification

Participants 1

The recurring payment framework covers UPI Corroborated (authoritative primary)

The Reserve Bank's consolidated directions on recurring payments state in their own applicability paragraph that they bind every payment system provider and payment system participant for recurring transactions, domestic or cross-border, made using cards, prepaid instruments or UPI. This is one of the few Reserve Bank instruments read for this rail that names UPI in its scope rather than in an example.

Rests on rule. Confidence high. in-upi:rule.e-mandate-framework-covers-upi

No facet on the record 2

Which payments are exempt from two factor authentication, including a UPI tap and pay Corroborated (authoritative primary)

The directions carry a list of use cases already exempted from the two factor requirement, and say that later additions apply too. Two of the listed cases touch UPI directly. A UPI tap and pay payment at a near field communication point of sale terminal is exempt, under a letter the Reserve Bank sent NPCI dated 2 September 2026. Recurring payments after the first one under the e-mandate framework are exempt as well. The list also covers small value contactless card payments, some prepaid instruments, toll collection, small value offline payments and certain corporate travel bookings.

Rests on rule. Confidence high. Also applies to UPI payment to a merchant. in-upi:rule.authentication-exemptions-include-upi-tap-and-pay

A digital payment is authenticated with at least two distinct factors Corroborated (authoritative primary)

Every digital payment must be authenticated with at least two distinct factors, unless it is one of the exempted cases. A factor is something the customer has, something they know or something they are, and the directions give passwords, one time passwords by text message, passphrases, personal identification numbers, card hardware, software tokens and biometrics as examples. Outside a card present payment, at least one factor must be dynamic, meaning the proof sent with the payment is unique to that payment. The factors must be chosen so that breaking one does not weaken the other. An issuer may offer its customers a choice of factors.

Rests on rule. Confidence high. Also applies to UPI transfer of funds to another person, UPI payment to a merchant, UPI 123Pay, a UPI payment from a feature phone. in-upi:rule.two-factors-of-authentication

What it inherits from the rail

  • Finality When is a payment final, and can it be undone?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. When does a UPI payment become final?.

  • Settlement How and when does the money settle between institutions?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. How and when do UPI positions settle?.

  • Hours When does the rail run, and what are its cut-offs?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. When is UPI open?.

  • Return How does a payment come back, and on what deadline?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. What happens when a UPI payment does not reach the payee?.

  • Refund Can the payer get the money back, and on what right?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. How does a UPI refund work?.

  • Messages What messages carry the payment and the answers to it?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. What message standard does UPI use, and what codes does it carry?.

  • Human decision points Where does a rule leave the decision to a bank or a person?

    No rule specific to this product is held for this question. The rail's own answer is linked; whether it applies to this product unchanged is not asserted. Where does a rule leave the decision to a bank or a person?.

Where the rail's answer differs for it

Shared with the rail

  • Claim that the customer did not authorise the payment shared with the rail

    The rail's own exception; this product's records point at it and it is not restated here. Reached from in-upi:mandate.upi-recurring (disputed via), in-upi:rule.e-mandate-disputes-and-liability (part of).