Transaction Flow

Mandates in UPI can be initiated by payer or a payee (Individual, Corporate,

Merchant etc.)

Payer initiated mandate

Page 26 of 49 Public – UPI 2.0 Product Development Version - 1

 1. Payer creates the mandate on the PSP app against a verified payee UPI ID
by filling in the mandate attributes.
a. UPI provides option of creating one-time mandate. Payer selects a
one-time mandate where he is given an option to choose whether he
wants to intimate the payee (end beneficiary) or not. If payer
chooses not to intimate the payee then the payee PSP doesn’t notify
the payee but saves the mandate details at its end.
b. After entering the mandate details, payer provides credentials (UPI
PIN) to authorize the mandate.
c. Payer PSP creates Universally Unique ID (UUID) based UMN
(Unique Mandate Number).
2. UPI sends the mandate request detail to Payee PSP (verifying mandate
detail).
3. Payee PSP sends the response to UPI with verified details of mandate
4. UPI sends mandate request to the Issuer Bank of the Payer for verifying and
signing the mandate.
5. Issuer validates the request along with credential block (UPI PIN) and if
found valid, blocks the issuer account for the amount of mandate created.
Issuer also "digitally signs" the mandate XML and returns the entire signed
mandate XML in response to UPI.
6. UPI returns the signed XML to the Payer PSP. Payer PSP stores the
digitally signed XML. Payer PSP stores the mandate as a UPI ID
(umn@psp). This UMN is the unique mandate reference number created by
the Payer PSP as mentioned under point 1.c above. The mandate details
can be made available by the PSP in the App under relevant section – for
e.g. - “My Mandates” section for easy reference.
7. UPI also sends the confirmation message to Payee PSP without the digitally
signed XML and payee PSP acknowledges the same.
SMS/ Notification is sent by the Payer PSP to the Payer on the
successful create, modify and revoke action on the mandate.

Page 27 of 49 Public – UPI 2.0 Product Development Version - 1

 Payee (Corporate/Merchant) initiated mandate

Page 28 of 49 Public – UPI 2.0 Product Development Version - 1

 1. Payer provides his UPI ID to the Payee (merchant, corporate) on a web/mobile
interface or by any other means.
2. Payee application initiates mandate creation request via Payee PSP and Payee
PSP sends a create mandate request to UPI and in turn to Payer PSP.
3. UPI sends the mandate request to Payer PSP and Payer would be able to see
this request with all the details in relevant section of the App – for e.g. “pending
request” option on PSP app.
 Payer can choose to either approve the mandate immediately or later
within the time frame specified by Payee PSP.
4. Payer views the request on his mobile and authorizes the mandate by selecting
the debit account and providing the credentials (UPI PIN/biometrics-future use)
and Payer PSP sends mandate details to UPI.
5. UPI forwards mandate request to issuer for validating credentials.
6. Issuer validates request, PIN etc. and if found valid, “digitally signs" the
mandate XML. Issuer returns the entire signed mandate XML within the
response to UPI and the same time the money will be blocked in the
customer’s account.
7. UPI sends mandate confirmation with the digitally signed XML to the Payer
PSP.
8. Payer PSP sends mandate creation confirmation to UPI and Payer PSP stores
the mandate as a UPI ID (umn@psp) and can be viewed by user in relevant
section for e.g. “My Mandates” Option of the PSP application.
9. UPI responds to Payee PSP with the mandate response without the digital
signed XML.

SMS is sent by the Payee PSP to the Payee on the successful create, modify, and
revoke action on the mandate.

Page 29 of 49 Public – UPI 2.0 Product Development Version - 1

 Rules for One time mandate implementation:

Mandate Creation:

 One Time Mandate is accompanied with block fund. Issuer

blocks the amount is customer’s account basis amount entered
during mandate creation
 UMN is created by Payer PSP when mandate is created and
UMN length should be 32 digit as per UUID Logic (UMN should
be random, non-guessable and unique). E.g
130a977ccabb11e7abc4cec278b6b50a@mypsp). Length of 32
digit should be before ‘@’ and the total length of UMN address
can be maximum up to 70 digit including the PSP handle name.
 Mandate can be both Payer initiated and Payee initiated. This is
applicable for both P2P and P2M. However Payee initiated
mandate for P2P is currently not to be allowed.
 Share to Payee can be Y or N when created by payer. This is
applicable only in case of a Peer to Peer (P2P) transaction.
 Revocable flag should also be populated at the creation of
mandate and it can be either “Y” or “N”
 The amount rule provides for a selection of either the exact
amount or the Maximum amount. These are manifested as
“Exact” and “Max”. Amount rule is always set as default to –
“Max”.
 One time mandate has a Start Date and End Date. The period
between these two dates is the timeframe during which the
mandate can be executed.
 The time gap between Creation date and end date should not be
more than 90 days.

Page 30 of 49 Public – UPI 2.0 Product Development Version - 1

  There are possibilities where the Payer is modifying the mandate for
various reasons, wherever permissible. In this case, the Issuer Bank
also needs to reduce or increase the blocked amount basis Payer
changes. Also, the Blockfund flag can be Y or N. Block Fund= Y
Issuing bank should block the fund. Block Fund=N Issuing bank
should unblock the fund
 Block fund should be Y mandatorily when a mandate is created.
 Purpose tag must be populated when a mandate is created and it is
mandatory field for both P2P and P2M.Every mandate must be
associated with a purpose code. Below are few of the Purpose tags:
00-Default/P2P 01-SEBI 02-AMC
03-Travel 04-Hospitality 05-Hospital
06-Telecom 07-Insurance 08-Education
09-Gifting 10-Others

 Purpose Tag will be generally given by the PAYEE at the time of

initiating a transaction. However, in case PAYER is initiating a
transaction, a default purpose code 00 is passed & if there is a need
PAYEE can over write the value as per the Merchant. Thus the
updated Tag value should be considered. Purpose tag as populated
by payee shall always be considered as the final.
 Mandate will not be created in case the customer has insufficient
account balance.
 Initiation mode is also a mandatory tag and it must be populated for
mandate creation. Initiation mode is 11 (mandate) / 13 (mandate QR).
 Recurrence type= “one time” and no other recurrence rule will be
applicable.
 PSP/Bank will have to send SMS & notification to user after creation
of mandate.

Page 31 of 49 Public – UPI 2.0 Product Development Version - 1

 Mandate Modification:

P2P / P2M (Non Verified Merchant) Mandate:

Modify
P2P
Payer Payee
Payer Initiated Mandate Yes No
Payee Initiated Mandate (optional ) No Yes

P2M Mandate (Verified Merchant):

Modify
P2M
Payer Payee
Payer Initiated Mandate (optional) Yes No
Payee Initiated Mandate No Yes

 Mandate can be modified only by the creator of the mandate.

 Modification is only allowed for amount and the end date for the
mandate.
 In case the modification is related to change in the amount of the
mandate then Issuing bank should increase /decrease the blocked
fund amount as and when the modification is done by Payer/ Payee
PSP.
 During modification the block fund tag should be Y to enable the
issuing bank to block the modified amount.
 Mandate can be created at the time of mandate modification
 Mandate modification has to be authorized by the Payer using UPI
PIN.
 PSP/Bank sends SMS/notification to user after modification of
mandate.

Page 32 of 49 Public – UPI 2.0 Product Development Version - 1

 Mandate Revoke:
P2P / P2M (Non Verified Merchant) Mandate:
Revoke
P2P
Payer Payee
Payer Initiated Mandate Yes Yes
Payee Initiated Mandate (optional ) Yes Yes
P2M Mandate (Verified Merchant):
Revoke
P2M
Payer Payee
Payer Initiated Mandate (optional) Yes Yes
Payee Initiated Mandate Yes Yes
 Revocable flag can be both Y and N. Revocable Flag is only
applicable for PAYER i.e. a PAYER can revoke a mandate when the
revocable flag is “Y” and Payer can’t revoke a mandate when Revoke
flag is “N”.
 If Payee PSP populates revocable flag N, Then payer is not allowed
to revoke the mandate. It is discretion of merchant to give an option
of keeping revocable flag Y or N.
 In case of payer initiated revoke, UPI PIN must be entered by the
payer. In case of payee initiated revoke only the DS saved at the
Payer PSP must be passed to the issuer.
 When the *revocable flag is Y then only the “Revoke”
functionality can be invoked by a Payer PSP , in other words only in
this scenario a payer shall be able to revoke the mandate.
 Revoke functionality will only be required if either payer/payee or both
, decide not to execute mandate for any reason.
 In all the above scenarios when mandate is revoked the txn type is
revoke, Revocable flag is Y and the block fund is N.
 Mandate revoked successfully, can’t be undone.
 PSP/Bank sends SMS/notification to user after revoke the mandate.

Page 33 of 49 Public – UPI 2.0 Product Development Version - 1

 Mandate Execution:

 Mandate execution is always initiated by the Payee PSP/Merchant.

 Where Issuing bank needs to unblock the lien marked fund then
Block Fund parameter should be = N
 Issuing Bank should automatically unblock the fund after the
mandate expiry (Issuer to have a scheduler to decide on unblock
the fund post expiry). Unblocking can be made post 23:59 of the
day of expiry. Amount should be unblocked immediately if a
mandate is revoked.
 For one time mandate once executed issuing bank must decline re-
execution of same mandate.
 Any mandate executed post the end date will be declined by issuing
bank.
 If amount is blocked for one time mandate than any other
transaction must be declined if there is less account balance stating
that amount is blocked for mandate and insufficient funds available
for the debit.
 PSP/Bank sends SMS/notification to user after execution of
mandate.
 PSP/Bank sends SMS/notification to user after execution of
mandate.
 Mandate Reinitiate- A mandate transaction can be initiated by
Payee PSP/Merchant if it is declined due to technical reason code,
business reason codes or basis risk score from FRM then mandate
can be reinitiated by payee/merchant till the time mandate gets
executed.
 App deregistration can’t be allowed if any mandate is pending
execution against the UPI ID or any other mandate is active.


Page 34 of 49 Public – UPI 2.0 Product Development Version - 1
 Limits:
 At the central system, the limit shall be on the per mandate only i.e. Rs.2
Lacs
 At the central system there shall be no cumulative limit – neither number
nor amount – for the mandate.
 Each mandate shall have limit based on the purpose code, for eg.01(IPO)
shall be Rs.2 Lacs. Each bank shall have to honor this limit. Similarly, say
for 04(hospitality) if the limit agreed is Rs. 1 Lacs then no mandate can be
created for amount higher than this.
 In other case the limit shall be Rs.2 Lacs. However the issuer bank may
restrict limit basis the customer profile, risk etc.
 To summarize – limit hierarchy will be, purpose code-> bank limit-> Rs.2
Lacs.

Page 35 of 49 Public – UPI 2.0 Product Development Version - 1

 Invoice in the Inbox (View and Pay)
UPI has a provision where the merchants can share Invoices with the customers
before the transaction is authorised. This will help customers to verify the invoice
details such merchant name, amount, due date etc before making the payment.
This functionality shall be available only for the verified merchants.

The invoice can be embedded as URL and that be accessed through clicking link
in a collect request or scanning QR or intent.

The Invoices can either be downloaded as PDF or can be viewed on a browser.

This provision requires the PSP applications to display an option called ‘view to
click the attachment’. This option will be present for collect transactions and
intent/QR initiated pay transactions. Entities/merchants can raise collect request
for all outstanding payments. This collect request may also contain the Invoice
details for the user to check before making a payment.

When the user scans a QR or triggers an intent carrying URL tag then he will get
an option on the app to click that URL. This URL can redirect him to the invoice
which can be either viewed or downloaded (As per the PSP). If URL is not passed
then ‘‘view to click the attachment’ shall be disabled. Similarly for collect requests
received on handset, by clicking the ‘view to click the attachment’ option the URL
can be browsed. The URL embedded in the request should be secure, come
from a secure source and should only display the details relevant to that user.

Page 36 of 49 Public – UPI 2.0 Product Development Version - 1

 The option of viewing the URL will only be available for Verified Merchant UPI
ID’s. For any other UPI ID, the URL option should be suppressed.

a. No URL to be shown to the customer. It can be hyperlinked to text like “Click

to view the attachment”

b. When the customer clicks on “View Invoice”, app will redirect the customer
to the link without showing the URL openly to the customer.

c. The link should also show that it’s from a secured channel (similar to https:
or a green lock symbol)

d. When the customer clicks on back button, customer comes back to the
application and proceed with the transaction by invoking the CL to enter UPI
PIN.

e. On the transaction detail page user have an option to also view the
invoice.

f. Guidelines:
1. Virus Scan to be a mandatory check for all URL links
i. PSP apps to put a check that the URL which is being
displayed by the app should be from a secure source.
ii. Banks verifying the merchant should check that the
merchant sends the URL which is secured and should
have necessary checks at their end.
2. Only the whitelisted entities can send the “URL” which will be showed to
the customer.

Page 37 of 49 Public – UPI 2.0 Product Development Version - 1

 User Flow

<PSP Screens are representation purposes only>

Following suggested screenshot exhibits the flow:

a)

Page 38 of 49 Public – UPI 2.0 Product Development Version - 1

 b)

Rules

 All types of attachments are allowed, however attachment have to be

secured.
 Only verified merchants are allowed to send the link/ attachment in the
collect request
 It’s the responsibility of the acquiring bank to provide domain name of
their own bank and verified merchant who sends the hyperlink /
attachment
 The liability of URL and content is responsibility of the acquiring bank.
 The URL must be opened in a separate window and not in the same UPI
page/ window.

Page 39 of 49 Public – UPI 2.0 Product Development Version - 1

  Content within the URL should not be illegal in nature.
 Website hosting the content should have provision to check that there is
no malware/Virus in the content that can harm the user’s device
 Content having sensitive/private information as per the provision of
existing/evolving privacy law should have adequate provisions for
intended user to verify himself/herself through desired mechanism (such
as password , pin etc) before the content is opened.
 Acquiring PSP changes: - An Acquiring PSP should be able to raise a
collect request in which Tag REF URL should have bill invoice based URL
that can take customer to biller website where invoice is hosted.
 Issuance PSP changes: - A customer PSP should be able to display this
REF URL in pending collect requests. When customer invokes the app &
checks out the pending requests he should be able to click and browse on
the link.
 Transaction History must show the URL always for future customer
reference.

Page 40 of 49 Public – UPI 2.0 Product Development Version - 1

 Signed Intent and QR

Objective of intent/QR based payments is to incorporate simplicity, security and

seamlessness in UPI transactions. Intent/QR method also makes payment
integration easier for merchants providing scope for new use cases.

Existing intent/QR payment method allows the UPI User to complete the
transaction, invoking the PSP application by means of Android/iOS intent, QR,
NFC, BLE and UHF. The invoked application prompts the UPI User to enter UPI
PIN to complete the transaction. The current implementation of intent is invoked by
merchant application shooting intent or merchant terminal pushing channel specific
intent. The existing intent/QR reception on PSP application faces the below
challenges:

a) Any application/terminal can act as a source of an intent/QR and can imitate as

an authorized source or may spoof the UPI User by altering terminal,
populating incorrect payment details.
b) The intent is received by PSP application, the UPI User has to enter
application passcode followed by his UPI PIN to complete the transaction
which acts as an additional step creating friction in payment.

Solution: In order to overcome the challenges in the existing intent/QR mechanism

in UPI signed intent/QR is being introduced. Signed Intent/QR is expected to
provide an additional layer of security, simplify transactions and bring sanity across
ecosystem for intent/QR based payments. With the signed QR, issues related to
tampering QR as well as having non-verified entities shall be reduced.

Page 41 of 49 Public – UPI 2.0 Product Development Version - 1

 Signed intent & QR principles

 “All intent /QR based transactions if not originating from the trusted
sources” (All unsigned intent/QR) will appear as a warning to the end
user

 If QR/intent is signed then the application should bypass passcode

page.

User Flow

a) Signed intent

Page 42 of 49 Public – UPI 2.0 Product Development Version - 1

 b) Unsigned intent

Page 43 of 49 Public – UPI 2.0 Product Development Version - 1

 C) Signed QR

Page 44 of 49 Public – UPI 2.0 Product Development Version - 1

 d) Unsigned QR

Page 45 of 49 Public – UPI 2.0 Product Development Version - 1

 Transaction Flow

Process Flow

The receiving PSP application will “verify the source of intent/QR” and will display
a warning if received from other sources. This will help reducing request from illicit
sources, imitating as merchant. The PSP will also be able to identify any alteration
to payment details passed in intent/QR.

Page 46 of 49 Public – UPI 2.0 Product Development Version - 1

 Note:

 PSPs will have to generate as well as to respond to signed/unsigned intent

and signed/unsigned QR.
 Signed key/token to be stored in a secured manner at the merchant’s
server.
 Only verified merchant is allowed to initiate singed intent/QR.

Rules

 PSP need to Skip the app passcode in case of signed intent

 In case the intent or QR is not signed , a warning message has to displayed on
the customer’s app. Only post confirmation from the customer, app should move
forward.
 Acquiring PSP changes: - An Acquiring PSP should be able to generate a
digital signature based QR/intent for which a public key will be uploaded by
Acquiring PSP into NPCI central system through API MANAGE VAE.
 Issuance PSP changes:- A customer PSP should be able to download public
key of that specific merchant using API LIST VAE. Whenever QR / Intent is
accessed by the customer the validation of public key should happen and if it is
not a singed QR / intent, customer PSP will throw an error “ Unsolicited /
Unauthenticated QR or intent call ” . Thus the choice will be given to the
customer to proceed or decline the txn.
 P2P PSP changes: An bank PSP should be able to generate a digital signature
based QR/intent for which a public certificates will be uploaded by bank PSP
into NPCI central system through API LIST KEYS.
 Bank need to follow the deep linking specs version 1.6 (latest version provided
by NPCI)


Page 47 of 49 Public – UPI 2.0 Product Development Version - 1

Annexure 1: Roles & responsibility Matrix

UPI Mandate

Page 48 of 49 Public – UPI 2.0 Product Development Version - 1

Overdraft Facility, Signed Intent & QR, Invoice in the box

Page 49 of 49 Public – UPI 2.0 Product Development Version - 1