UPI 2 0 Product Document - 25072017-1

UPI 2.
0 Product doc
UPI 2.0 Product Paper
1|Page
NPCI 1001A, B wing, 10th Floor, The Capital, Bandra-Kurla Complex, Bandra (East), Mumbai - 400 051
UPI 2.0 Product doc
Purpose:
The purpose of this document is to describe the product related changes/enhancement that
are proposed in the next version of UPI, known as UPI 2.0. The rationale for these
enhancements, impact on the users behaviour, usability and overall impact of UPI are
described in this document.
The transaction flow for UPI 1.0 (Functionalities currently available) is not explained in this
document and the reader is expected to read the earlier document to be familiar with the
terms.
Background
NPCI launched Unified Payments Interface (UPI) with 21 member banks on 25th August, 2016,
since then UPI has grown strong to a family of over 50 member banks adopting UPI as the
method of payments. UPI is bank agnostic and allows users to send and receive money using
their own unique id known as UPI ID (also known as virtual payment address) in addition to
Account number + IFSC and Aadhaar number.
UPI supports person to person transfers as well as merchant payments and has a hassle-free
user on-boarding (registration , linking bank account) process.
Conceptualized as a mobile application based solution primarily catering to internet

compatible phones ( smart-phone users) , UPI is also available for non-internet based mobile
devices ( smartphone as well as basic phones ) in the form of *99# ( USSD based mobile
banking service) .
The rapid increase in transaction in UPI can be attributed to the expanding ecosystem
promotion by member banks and increasing adoption by the users.
2|Page
UPI 2.0 Product doc
INTRODUCTION
User convenience and security are the most important attributes that require continuous
vigilance, scrutiny and enhancement in the retail payment system. While these two may
appear to be divergent requirement, a fine balance between the two is required and with the
technological advancement this has become possible.
UPI 2.0 targets to address both these aspects i.e. UPI user convenience and security through
introduction of following functionalities:
Transaction authorization using Biometrics
UPI Mandate
Signed Intent and QR
3|Page
UPI 2.0 Product doc
Table of Contents
Purpose: .................................................................................................................................................. 2
Background ............................................................................................................................................. 2
Introduction ............................................................................................................................................ 3
High level architecture ........................................................................................................................... 5
Detailed requirements ........................................................................................................................... 6
TRANSACTION AUTHORIZATION USING BIOMETRIC .......................................................................... 6
Background ..................................................................................................................................... 6
Solution ........................................................................................................................................... 6
Process flow .................................................................................................................................... 7
Biometrics registration flow ............................................................................................................ 9
Transaction Flow ........................................................................................................................... 13
Terms and Conditions.................................................................................................................... 16
Benefits ......................................................................................................................................... 16
UPI Mandate ..................................................................................................................................... 17
Background ................................................................................................................................... 17
Solution ......................................................................................................................................... 17
User Flow....................................................................................................................................... 18
User interface ................................................................................................................................ 20
Transaction flow ............................................................................................................................ 30
UPI Mandate QR Specs .................................................................................................................. 33
Use Cases ...................................................................................................................................... 36
Benefits ......................................................................................................................................... 40
SIGNED INTENT and QR .................................................................................................................... 41
Background ................................................................................................................................... 41
Solution ......................................................................................................................................... 41
Process flow .................................................................................................................................. 42
Benefits ......................................................................................................................................... 43
OTHER FEATURES .............................................................................................................................. 44
Certification .......................................................................................................................................... 44
Glossary ................................................................................................................................................ 45
Disclaimer ............................................................................................................................................. 45
4|Page
UPI 2.0 Product doc
HIGH LEVEL ARCHITECTURE
5|Page
UPI 2.0 Product doc
DETAILED REQUIREMENTS
TRANSACTION AUTHORIZATION USING

BIOMETRIC
Background
Currently transactions in UPI are authorized using UPI PIN. The user has the option of self-
generating this UPI PIN with or without ATM PIN as a second factor authentication and also
has the option of changing the UPI PIN, whenever required.
While PIN has been used across the payment systems, the issues related to this such as users
having to remember multiple PINs, forgetting PIN or entering wrong PIN have been the major
cause of the transaction declines.
The security concerns that user may have in case of lost mobile phone or others able to access
their UPI PIN and able to do fraudulent transactions, warrants availability of alternative
mechanism for users to authenticate transactions.
Solution
Biometrics is a security identification and authentication feature that uses automated

methods of verifying or recognizing the identity of a living person based on a physiological or
behavioural characteristic. These characteristics include fingerprints, facial images and Iris
prints. Biometrics is emerging as an effective mechanism to both identifying users as well as
authorizing any financial transactions.
The Unique Identification Authority of India (UIDAI) has been created, with the mandate of
providing a Unique Identity (Aadhaar) to all Indian residents. The UIDAI provides online
authentication services via authorized entities (AUAs) which includes biometric
authentication and OTP authentication. With more than 116 crore residents having Aadhaar,
use of Aadhaar authentication and eKYC services is increasing day by day.
6|Page
UPI 2.0 Product doc
The mobile manufacturers are launching devices that are capable of capturing Fingerprint/Iris
information of the users. Also, add-on devices are now available that can be integrated with
mobile phones to capture the desired information.
UPI will include the functionality of transaction authentication using Biometric (Fingerprint
/Iris). This functionality will be available to the entire UPI ecosystem and users with
compatible smartphones shall be able to use this as an alternative to authorize transaction.
Inclusion of Iris authentication and fingerprint into UPI will not only make payments more
secure but will also take a huge leap towards integrating next generation technology with
current payments system.
Use of Aadhaar Registered Devices allow secure capture of biometrics that is done within
UIDAI approved Registered Devices Service installed within the mobile which is integrated
from UPI Common Library via Aadhaar Registered Devices interface specification.
CL (Common Library) will allow discovery and listing of Aadhaar compliant RD services. PSP
application can provide the choice to the customer to choose an authentication mode within
the app using CL provided utilities. For this option to be used, user should have linked Aadhaar
to their bank account and also explicitly provide consent to enable this.
The entire biometric data capture will be managed by UPI common library page making it
secure and seamless.
Process flow
In case of an existing user the device capability to accept biometrics is checked after the
customer upgrades his app and enters his passcode.
In case of a new user who has never installed the app before, the device capability to
accept biometrics is checked immediately after he sets his passcode.
The below process remains common for an existing user with bank accounts configured, an
existing user adding a new bank account and a new user adding a bank account for the first
time.
The PSP app invokes the NPCI common library which in turn invokes the registered
device service (RD) to identify whether the device is capable of capturing biometrics.
7|Page
UPI 2.0 Product doc
If the device has the capability of capturing biometrics then the user is asked for his
consent to opt for biometrics. The user has an option for giving his consent
immediately or at a later stage through the relevant option in the app.
The user consent would need to be stored by the PSP. The PSP can decide whether
they want to take a user consent each time an account is added or can have a
consolidated consent for all accounts added or which will be added in future.
The List account API is called along with Aadhaar consent. The response from the
issuing bank would inform the PSP whether the account is Aadhaar enabled or not via
Aadhaar enabled bank account (aeba) flag and whether UPI Pin is set or not via mobile
banking enabled account (mbeba) flag. Aadhaar number will be returned by the
issuing bank only if Aadhaar consent is Y.
If aeba flag is Y and Aadhaar number is returned then the PSP app will display the
masked Aadhaar number to the User and seek his confirmation.
If the User confirms the Aadhaar details, then the Aadhaar number is stored in an
encrypted manner at the PSP end and is displayed in a masked manner to the user.
PSP must ONLY maintain the Aadhaar number on its server in encrypted form and
masking must be done on the server side before sending to PSP application.
If the User response is negative i.e. the Aadhaar number available with the bank is
incorrect then the user is advised to contact the bank where he holds the banking
relationship with.
If aeba flag is N i.e. Aadhaar number is not available, the user is advised to contact
the bank where he holds the banking relationship with.
If the user doesnt give his consent for biometrics and/or if the mbeba flag is N then
the user is prompted to create his UPI PIN.
Note: Creation of UPI PIN is mandatory however opting for Biometrics is optional.
8|Page
UPI 2.0 Product doc
Biometrics registration flow
Important Points to remember

1. PSP is expected to store the Aadhaar consent of the user
2. PSP app to display the Aadhaar number in a masked format to the user.
3. PSP to store the Aadhaar number and other PII in an encrypted/hashed secure
manner in the database/server.
4. PSP will have to adhere to all the Aadhaar related guidelines as specified by UIDAI.
9|Page
UPI 2.0 Product doc
1) User consent
2) New user
10 | P a g e
UPI 2.0 Product doc
3) Aadhaar number is incorrect or not available at the bank end
4) Existing customer with multiple bank accounts
11 | P a g e
UPI 2.0 Product doc
5) Selecting biometrics from the menu options
(Disclaimer: UI and flows shown are only for illustrative purpose , PSP can have their own
implementation of the UI )
12 | P a g e
UPI 2.0 Product doc
Transaction Flow
1. Payer enters the details of the Payee in the PSP app and clicks on send.
2. If the Payers device is not capable of capturing biometrics or payer has not given his
consent for biometrics or biometrics is not turned on then the only option available for
the payer for authorizing a transactions is UPI PIN
3. If the Payers device is capable of capturing biometrics or payer has given his consent for
biometrics then the Payer PSP calls the common library which in turn calls the RD service,
depending on the response of the RD service the user is given three options to authorize
the payment.
a) UPI PIN
b) Finger-print
c) Iris
4. On selection of Finger-print/Iris Payer PSP sends the pay request to UPI.
5. UPI sends the request to the respective Payee PSP for address resolution.
6. Payee PSP resolves the address and sends the payee account details to UPI.
7. UPI invokes the biometric authentication API on behalf of the issuing bank and forwards
the data to UIDAI.
13 | P a g e
UPI 2.0 Product doc
8. At the UIDAI CIDR, Aadhaar system decrypts the biometric, verifies integrity, matches it,
and returns a yes/no in digitally signed format.
9. UIDAI sends the Success or decline response to UPI switch which is forwarded to the Payer
PSP to be shown to the payer.
10. On a successful UIDAI response, UPI sends the debit request to issuer bank.
11. Issuer bank debits the Payers account and sends the confirmation to UPI.
12. UPI sends the credit request to the Beneficiary Bank.
13. Beneficiary Bank credits the Payees account and confirms the same to UPI.
14. UPI sends the successful confirmation to the Payee PSP.
15. Payer PSP confirms the same to the user.
16. In case of a decline from UIDAI the transaction is declined and the Payer PSP is informed
on the same.
Suggested authorization flow is for users whose device is capable of capturing biometrics
and who have given consent for biometrics for users whose device is not capable of
capturing biometrics the existing flow of UPI Pin only holds good.
1) User can select anyone of the authorization method as default the moment he does the 1 st
financial transaction.
14 | P a g e
UPI 2.0 Product doc
2) On Subsequent transactions the transaction progresses with the already set default
method of authorization.
3) User is given a choice to change the default authorization setting in the Biometrics tab of
the PSP app.
15 | P a g e
UPI 2.0 Product doc
Terms and Conditions
The agreement for enabling this functionality for their Users will be the prerogative of the
issuer banks and this will be done through their agreement with UIDAI.
Any liability owing to transaction authorization using biometrics shall be on the issuer
bank
Benefits
Introduction of Biometric is expected to make the entire transaction life-cycle frictionless
and will enhance the user convenience.
Errors related to wrong UPI PIN entry shall be eliminated that will improve the transaction
success rate.
16 | P a g e
UPI 2.0 Product doc
UPI Mandate
Background
Users have an inherent need to make payments that are either one time or recurring in
nature, for e.g. utility bills payment, insurance premium etc. Such payments have mechanism
already in place that include concept of billing cycle , last date of payment and penalty in case
of delay/default in payment. To have better control for such payments and have hassle free
process, users are opting for mechanism of providing mandate to the
biller/merchant/corporate for debiting their accounts.
While the mandate creation is a one- time activity, it allows users account to be debited as
per the agreed terms and condition, without the user to authenticate the transaction every
time. UPI currently does not have the functionality of generating mandate or authorizing
recurring payments through one time authentication. This option is introduced in UPI 2.0 to
enable UPI users to perform recurring payment transactions with the same ease and
convenience. This functionality shall have its own mechanism of generating/accepting
mandates; independent of any similar services available in the ecosystem.
Solution
UPI will offer the mandate service that will allow both payer and payee to create mandates
or standing instructions (SI) through their respective PSPs/banks. This mandate shall be
registered immediately post the one time authentication by the payer. To start with UPI will
support only revocable mandates and mandates can be created on UPI ID / VPA (all valid UPI
VPAs are supported) only.
17 | P a g e
UPI 2.0 Product doc
User Flow
Mandates in UPI can be initiated by payer or a payee (Individual, Corporate, Merchant etc.)
Payee/Corporate initiated mandate
1. Payer provides his VPA to the Payee (merchant, corporate, individuals) on a web/mobile
interface or by any other means.
2. Payee application initiates creation request via Payee PSP and Payee PSP sends a create
mandate request to UPI and in turn to Payer PSP.
3. Payer would be able to see this request with all the details in the Request Received
option on his PSP app
4. Payer can choose to either approve the mandate immediately or later within a time frame
of 72 hours.
5. Payer views the request on his mobile and authorizes the mandate by selecting the debit
account and providing the credentials (UPI PIN/biometrics).
6. Payer PSP sends mandate Detail to UPI.
7. UPI forwards mandate request to issuer for validating credentials.
8. Issuer validates request, PIN, etc. and if found valid, digitally signs" the mandate XML.
9. Issuer returns the entire signed mandate XML within the response to UPI.
18 | P a g e
UPI 2.0 Product doc
10. UPI sends mandate confirmation with the digitally signed XML to the Payer PSP.
11. UPI responds to Payee PSP with the mandate response without the digital signed XML.
12. Payer PSP stores the mandate as a VPA (umn@psp) and can be viewed by user in the My
Mandates Option of the PSP application.
Payer initiated mandate
1. Payer creates the mandate on the PSP app against a verified payee VPA by filling in the
mandate attributes.
a. UPI provides option of creating one-time as well as recurring mandate. If the Payer
selects a one-time mandate then he is given an option where he can choose to
intimate the payee or not. All recurring payments are by default intimated to the
Payee PSP.
b. After entering the mandate details, payer provides credentials (UPI
PIN/Biometrics) to authorize the mandate.
c. Payer PSP creates UUID based UMN (Unique Mandate Number)
2. Payer PSP now sends a create mandate request to UPI.
3. As the VPA address is already verified, UPI sends mandate request to the Issuer Bank of
the Payer for verifying and signing the mandate.
19 | P a g e
UPI 2.0 Product doc
4. Issuer validates the request, cred block etc. and if found valid, "digitally signs" the
mandate XML and returns the entire signed mandate XML within the response to UPI.
(Issuer may or may not store the signed XML and may choose to validate the request each
time when the mandate is executed).
5. UPI returns the signed XML to the Payer PSP.
6. UPI also sends the confirmation message to Payee PSP without the digitally signed XML
provided the user has chosen to inform Payee.
7. Payer PSP stores the mandate as a VPA (umn@psp) and can be viewed under My
Mandates
8. SMS is sent by the Payer PSP to the Payer on the successful create, modify, suspend and
revoke action on the mandate
User interface
The PSP app gives the User an option to Create / Modify / Suspend / Revoke / Approve
Mandates.
20 | P a g e
UPI 2.0 Product doc
Create mandate
Mandates can be created for/by individuals, corporates or merchants.

Payer can initiate a one-time / recurring mandate by entering Payee VPA as well create
a mandate by scanning a QR.
In case of payer initiated one-time mandate, he is given the option whether he would
want to intimate the payee on the mandate created. If the user opts for it, then UPI
then sends this information to Payee PSP who then shows the same to the payee.
Payer can share the one-time mandate address (umn@psp) with the payee through
any communication mechanism such as messaging app or the payee/merchant can
scan the umn@psp address via QR.
In case of recurring mandate initiated by the payer, UPI will send the information to
the Payee PSP who in turn informs the payee.
Payer can set a nickname for the mandates at the time of creation or approval for easy
identification, however no transaction can be performed on a nickname. A transaction
note/remarks can also be set for mandates.
Mandate Rules:
o Mandate frequency can be one on the following - One time / Daily/ Weekly /
Bi-Monthly / Monthly/ Quarterly / Half yearly / Yearly / As-Presented.
o If frequency is Weekly value should be between 1 and 7 only.
o If frequency is one time, daily or As-Presented then before/on/after is not
applicable, for other frequency types the payer can choose the day on which
the debit will take place by selecting on/before/after.
o Validity of the mandate can be set with Start date and End date.
o Payer has the facility to set the maximum amount for each mandate.
o UMN will be created by customer/Payer PSP and will be of maximum length 35,
the UMN should be random, non-guessable and active UMN should be unique
within the PSP. The PSP has a prerogative to repeat the UMN number after a
period of 3 months if the mandates are non-active.
21 | P a g e
UPI 2.0 Product doc
1) Payer initiated one-time payment by entering Payee VPA.
22 | P a g e
UPI 2.0 Product doc
2) Payer initiated recurring payment by entering Payee VPA.
23 | P a g e
UPI 2.0 Product doc
3) Payer initiated recurring payment by scanning dynamic or static QR.
24 | P a g e
UPI 2.0 Product doc
4) Payee initiated P2P mandate request on the PSP app.
The suggestive SMS text to be sent by the Payer PSP to the Payer
Dear Customer,
You have successfully created a mandate on <payee vpa> for a frequency of <frequency>
starting from <start date> for amount <amount>.
25 | P a g e
UPI 2.0 Product doc
Accept / Reject mandate request (Payee initiated mandates)

All the payee initiated requests will be visible in the Request received option.
Payer has the option of approving or rejecting any mandate request and will be informed
through the notification and SMS about the mandate request.
1) Approving Payee initiated mandate.
26 | P a g e
UPI 2.0 Product doc
2) Declining Payee initiated mandate.
The suggestive SMS text to be sent by the Payer PSP to the Payer in case of approval of a
mandate
Dear Customer,
You have successfully approved a mandate on <payee vpa> for a frequency <frequency>
starting from <start date> for amount <amount>.
Dear Customer,
You have declined a mandate on <payee vpa> for a frequency <frequency> starting from
<start date> for amount <amount>.
View mandate
All existing mandates are displayed in the My Mandates page.
User can view/modify/suspend/revoke mandates created by him and can
view/suspend/revoke mandates created by a payee on him. In other words one who
creates the mandates only can modify it. There would be no change to the UMN number
when the mandate is modified.
Suspended/Paused mandate can be activated however revoked mandate cannot be
undone.
Suspend is an action only between Payer and Payer PSP.
27 | P a g e
UPI 2.0 Product doc
Any transaction initiated on a suspended mandate would be declined with an error code.
1) Modify Payer Initiated mandate.
Note: Payee initiated mandates can be modified only by payee and will be sent for approval to
payer. The approval SMS would be sent to Payer and Payer has a choice to Accept or reject the
modification request.
28 | P a g e
UPI 2.0 Product doc
2) Payee initiated mandates can only be suspended and revoked by Payer.
3) Payer initiated mandate revoked.
29 | P a g e
UPI 2.0 Product doc
Mandate history
All mandates created will be available to the payer in Mandate history. Mandate history will
also contain the number of instructions pending execution.
Transaction flow
30 | P a g e
UPI 2.0 Product doc
Once mandate is successfully created, transactions are completed through following steps
and user authorization doesnt take place as the mandate has all necessary information to
raise a request. Payer PSP and the remitting bank will respond to the mandate raised by
Payee:
1. Payee PSP initiates the collect request to UPI either through an interface/scheduler (for
recurring mandates), manually entering the VPA or by scanning the VPA QR code.
2. UPI sends the request to Payer PSP.
3. Payer PSP decides whether the collect request sent is a mandate by doing a lookup on the
mandate table or any other structure where it stores mandate information. Payer PSP also
validates the parameters of the mandate and if certain on the type of the request as
mandate will append the cred block to it and send to UPI which then sends the debit
request to issuing bank. If the lookup to the mandate fails then the Payer PSP treats the
request as a normal collect request and the existing process holds good.
4. In case of mandate, issuing bank debits the Payers account and sends the confirmation
to UPI.
5. UPI sends the credit request to the Beneficiary Bank.
6. Beneficiary Bank credits the beneficiarys account and confirms the same to UPI.
7. UPI sends the successful confirmation to the Payee PSP/Corporate PSP.
8. Payer will be able to view the status of the mandate transaction in transaction history.
9. All mandates pending execution can be viewed in Mandate History option.
10. Payer PSP informs the customer via SMS , in-app notification or emailers (to those
customers where the email id is registered on the PSP app) on the success/failure of the
mandate transaction
The suggestive SMS text to be sent by the Payer PSP to the Payer
In case of successful mandate execution
Dear Customer,
The mandate of amount <amount> has been raised by <payee vpa> on <date> and is
successfully executed
In case of failed execution
Dear Customer,
31 | P a g e
UPI 2.0 Product doc
The mandate of amount <amount> has been raised by <payee vpa> on <date> and has
failed.
32 | P a g e
UPI 2.0 Product doc
UPI Mandate QR Specs
UPI 2.0 provides the functionality of creating mandate QR that contains all the mandate
related information and is different from the existing UPI QR that are used for making
payments.
The UPI PSP app should be able to read UPI QR/Bharat QR and UPI Mandate QR.
UPI Mandate QR created by Corporate/Merchant/Payee

The corporate/merchant/payee would create a mandate QR basis the below specs which
the UPI PSP app is expected to scan and populate the create mandate screen on the PSP
app.
UPI specific parameters for UPI Mandate QR are listed in below table. (M-Mandatory, O-
Optional)
Parameter Data Mandatory/ Mapped to Description

name type Optional UPI API field
pa String M Payee addr Payee VPA
pn String O Payee name Payee name
mn String O mandate Mandate name, specifies the
name purpose of mandate
tid String O Txn id This is the transaction id to
be passed for mandate
creation.
type String O mandate type Future use
validitystart String M mandate Defines start time of

validity start mandate validity
validityend String M mandate Defines end time of
validity start mandate validity
am String M mandate Transaction amount in
Amount value decimal format.
amrule String M mandate MAX or EXACT rule
Amount rule applied to mandate
(Optional, default value to
be passed in online message
in case amrule is not passed
in QR is 'MAX')
33 | P a g e
UPI 2.0 Product doc
recur String M Mandate Specifies the frequescy of

Recurrence mandate debit (ONETIME|
DAILY| WEEKLY|
BIMONTHLY| MONTHLY|
QUARTERLY| HALFYEARLY|
YEARLY| ASPRESENTED)
recurvalue String M Mandate Specifies date along with

Recurrence 'recurtype' for debit
rule value
recurtype String M Mandate Can have

Recurrence values:(BEFORE|ON|AFTER
rule type ), Specifies date along with
'recurvalue' for debit
tr String M TxnrefId Transaction reference ID.
This could be order number,
subscription number,
booking ID, insurance
renewal reference, etc.
url String O TxnrefUrl This should be a URL when
clicked provides customer
with further mandate details
or schemes of the service
being availed with mandate.
cu String O Payee Currency code. Currently
Amountcurr ONLY "INR" is the supported
value.
mc String O Payeemcc Payee merchant code
If present then needs to be
passed as it is.
tn String O Txnnote Transaction note providing a
short description of the
transaction.
URL link
upimandate://payee?pa=&pn=&mn=&tid=&type=&validitystart=&validityend=&am=&am
rule=&recur=&recurvalue=&recurtype=&tr=&url=&cu=&mc=&tn=
34 | P a g e
UPI 2.0 Product doc
QR created by Payer
UPI specific parameters for UPI Mandate QR created by a Payer are listed in below table.
(M-Mandatory, O-Optional, C- Conditional)
Parameter Data Mandatory/ Mapped to Description

name type Optional UPI API field
umn String M Payee addr Unique mandate number
shared by payer for the
payee to initiate the debit.
am String C* Payeeamount The amount to debited using
value mandate.
*(Note): if the mandate
created by payer has,
Mandate Amount Rule
as EXACT then am tag
needs to be populated with
the amount value of
mandate e.g. am=5000. If
Mandate Amount Rule
is MAX then am tag
should be dropped or
passed as null am=null.
tn String O Txnnote Transaction note providing a
short description of the
transaction.
URL link
upimandate://payer?umn=&am=&tn=
35 | P a g e
UPI 2.0 Product doc
Use Cases
Payer Initiated Mandate
Example 1: Vikram has to pay his driver a salary of Rs.10000 every month. He decides to
create a mandate for this recurring payment payable on the 1st of every month for Rs.
10000.
Vikram opens the UPI PSP app. he enters his drivers VPA/UPI ID, Amount Rs. 10000,
validity date ( 1st August 2017 to 31st July 2018),frequency as monthly ,amount rule as
Fixed and debit day as 1st of every month. The UPI mandate is created once Vikram
authorizes the request either with his UPI PIN or biometrics.
On the 1st of every month the drivers account is credited with the salary.
Example 2: Sameer goes to an electronics store to buy a television set worth Rs. 60000 on
a monthly EMI basis , he decides to create a mandate for the same and share it with the
store owner for debit to his account once a month.
Sameer opens the UPI PSP app and enters the electronics store owners UPI ID/VPA,
amount as Rs.5000 with a validity of 1 year (1st August 2017 to 31st July 2018) , frequency
as monthly , amount rule set as Fixed and debit day set as 10th of each month. The UPI
mandate is created once Sameer authorizes the request either with his UPI PIN or
biometrics.
The electronics store owners account is credited with the EMI amount against the
purchased television set on the 10th of each month for a period of 1 year.
Example 3: A company decides to give the top 10 performers of the month a gift voucher
of Rs.1000. The company official opens his UPI PSP app and creates a mandate individually
for all the 10 employees by entering the UPI ID/VPA of the performer, amount as Rs. 1000
with a validity of 1 year (1st August 2017 to 31st July 2018) frequency as as-presented,
amount rule as Fixed. The UPI mandate is created once the official authorizes the request
either with his UPI PIN or biometrics. The official can view the QR created in the My
Mandates screen and shares the QR created via email to the performers.
The performer opens his UPI App and scans the QR and is able to receive the credit in his
account.
Example 4: Aruns expense on groceries for a month is Rs 10000, for this he decides to
create a mandate. Arun opens his UPI PSP app and creates a mandate on the local grocery
store by entering the stores UPI ID/VPA, amount as Rs. 10000 with a validity of 1 month
(1st August 2017 to 31st August 2017) frequency as as-presented and amount rule as
Max. He then authorizes the mandate using his UPI PIN or biometrics. He can then view
his mandates in My Mandates option in the UPI PSP app.
When he goes to the grocery store, after his purchase he shows the QR generated for the
mandate to the shopkeeper who then opens his UPI PSP app to scan the QR and enters
the amount of purchase, if the amount entered by the shopkeeper is within the limit of
the mandate the transaction goes through without Arun having network connectivity on
his mobile at the time of payment.
36 | P a g e
UPI 2.0 Product doc
Payee Initiated Mandate
Example 1: Ganesh wants to pre book an upcoming phone model, he goes to the website,
selects the phone model and other details basis which a QR is generated.
He then opens his UPI PSP app and scans the QR generated on the website, authorizes the
mandate created from the QR with either his UPI PIN or biometrics. A mandate is created
and the web site is informed on the same.
Example 2: Ashok has a policy from LIC and LIC has come up with a functionality to pay
the premiums on a monthly basis, Ashok has decided to avail this and hence LIC has
decided to create a mandate for Ashok for amount Rs. 1500, validity date as long as the
term period i.e. 10 years (1st August 2017 to 1st August 2026), frequency of monthly,
amount rule as max and debit day on 3rd of the month and sends a create mandate
request to Ashok.
Ashok opens his UPI PSP app and authorizes the collect mandate request with UPI PIN or
biometrics.
The mandate transaction gets executed on the 3rd of each month.
Example 3: Ethan and Evan were planning a Goa trip in the month of September, for this
they need to book flight tickets however Evan doesnt have the money hence Ethan paid
the whole amount and decides to create a mandate on Evan for Rs.5000.
Ethan opens the UPI PSP app and goes to Request Mandate option and enters Evans UPI
ID/VPA, amount as Rs.5000, validity (1st September 2017 to 10 September 2017),
frequency as one time, amount rule set as Fixed and debit day set as 1 st of September and
sends the create mandate request to Evan. Evan opens his UPI PSP app and authorizes the
mandate using his UPI PIN or biometrics.
On 1st September Ethans account gets credited with Rs.5000.
Example 4: Mr. Dharmendra wants to collect the rent from his tenant named Shreya on
monthly basis so he creates a mandate on Shreya for Rs. 7000.
Mr. Dharmendra opens the UPI PSP app and enters Shreyas UPI ID/VPA, Amount Rs.
7000, validity date ( 1st August 2017 to 31st July 2018),frequency as monthly ,amount rule
as fixed and debit day on 3rd of the month. Shreya receives the create mandate request
from Mr. Dharmendra. She opens the UPI PSP app and authorizes the mandate request
with UPI PIN or biometrics.
Mr. Dharmendras account gets credited for rent on the 3rd of each month.
37 | P a g e
UPI 2.0 Product doc
Use case of wedding gift given by Bivek to Anjali with screen flow
Bivek opens his UPI PSP and creates a mandate for Anjali of Rs. 5100 as her wedding gift.
38 | P a g e
UPI 2.0 Product doc
On Anjalis wedding day Bivek shares with her the gift mandate created through WhatsApp
On the next day of her wedding Anjali scans the gift mandate QR by picking it from the
gallery and receives the gift in her account.
PSPs /Banks should have the mechanism of generating and verifying the UPI mandate.
PSPs are required to store the mandates in a secured manner.
Payer PSP needs to validate the business rule set against the mandate each time a
mandate collect request is made. Any liability arising on wrong execution of the mandate
request lies with the Payer PSP.
39 | P a g e
UPI 2.0 Product doc
Benefits
Introduction of mandate in UPI shall cater to those user segments who depend on other
means for scheduling their recurring payments
Mandate process in UPI shall simplify mandate lifecycle process.
This process shall be a boon to the merchant/corporate segment as UPI user base will be
available to them for their existing payment needs.
40 | P a g e
UPI 2.0 Product doc
SIGNED INTENT and QR

Background
Objective of intent based payments is to incorporate simplicity, security and seamlessness in

UPI transactions. Intent method also makes payment integration easier for merchants
providing scope for new use cases.
Existing intent 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 reception on PSP application
faces the below challenges:
a) Any application/terminal can act as a source of an intent and can imitate as an authorized
source or may spoof the UPI User by altering terminal, populating incorrect payment
details.
b) Payment details passed in intent are raw strings and can be altered specially in case of QR
or NFC, Wi-Fi based terminals.
c) After 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 mechanism in UPI signed intent is
being introduced. Signed Intent is expected to provide an additional layer of security, simplify
transactions and bring sanity across ecosystem for intent based payments. The signed intent
functionality will have following underlining principle:
All intent based transactions if not originating from the trusted sources will appear as a
warning to the end user.
41 | P a g e
UPI 2.0 Product doc
The onus of ensuring the implementation of signed or verified intent shall be on the
PSPs (in case of P2P apps) and on the acquiring PSPs/banks for the merchant initiated
intent requests.
This functionality can be extended to QRs as well making them more secure for
identification of any alteration of payment detail.
Process flow
The receiving PSP application will verify the source of intent 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.
a) Suggested flow for a signed intent
42 | P a g e
UPI 2.0 Product doc
b) Suggested flow for an unsigned intent
PSPs should have the capability 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 merchants server.
Benefits
The implementation of signed intent shall enhance the security functionality for intent
based UPI transactions.
In case of request received through genuine intent, PSP app may not request for APP
passcode and only prompt for authentication using UPI PIN or Biometric/Iris. This will
ensure a frictionless transaction experience for the users.
43 | P a g e
UPI 2.0 Product doc
OTHER FEATURES
Beneficiary name for Account no + IFSC and Aadhaar based transactions
The member banks are requested to send the customers name as per core banking in
the tags provided under RespValAdd (maskName) and RespPay (regName)
Certification
All the members upgrading to the newer version of UPI would need to undergo extensive
certification by NPCI. The process and modalities along with requisite test cases shall be
finalized basis discussions and implemented accordingly.
44 | P a g e
UPI 2.0 Product doc
Glossary
Sender / Payer Person/Entity who pays the money. Account of payer is debited as
part of the payment transaction.
Receiver / Payee Person/Entity who receives the money. Account of payee is
credited as part of the payment transaction.
User An individual person or an entity that has an account and wishes
to pay or receive money.
Payment Account Any bank account or any other payment accounts (PPI, Wallets,
(or just Account) Mobile Money, etc.) offered by a regulated entity where money
can be held, money can be debited from, and can be credited to.
Payment System Bank, Payment Bank, PPI, or any other RBI regulated entity that is
Provider (PSP) allowed to acquire Users and provide payment (credit/debit)
services to individuals or entities.
NPCI National Payment Corporation of India.
RBI Reserve Bank of India.
UIDAI Unique Identification Authority of India which issues digital
identity (called Aadhaar number) to residents of India and offers
online authentication service.
2-FA Two factor authentication.
*99# USSD based mobile banking service
UPI Unified Payments Interface
API Application Programming Interface
AUA Authentication User Agency
AEBA Aadhaar enabled bank account
MBEBA Mobile enabled bank account
Disclaimer
All the screenshots used are for the illustrative purpose only.
NPCI reserves the right to change/alter any process flow as it deems fit.
45 | P a g e

UPI 2 0 Product Document - 25072017-1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UPI 2 0 Product Document - 25072017-1

Hochgeladen von

Copyright:

Verfügbare Formate

UPI 2.

UPI 2.0 Product Paper

Conceptualized as a mobile application based solution primarily catering to internet

technological advancement this has become possible.

introduction of following functionalities:

Transaction authorization using Biometrics

Signed Intent and QR

HIGH LEVEL ARCHITECTURE

TRANSACTION AUTHORIZATION USING

Biometrics is a security identification and authentication feature that uses automated

Biometrics registration flow

Important Points to remember

3) Aadhaar number is incorrect or not available at the bank end

4) Existing customer with multiple bank accounts

5) Selecting biometrics from the menu options

Terms and Conditions

Introduction of Biometric is expected to make the entire transaction life-cycle frictionless

and will enhance the user convenience.

Payer initiated mandate

Mandates can be created for/by individuals, corporates or merchants.

1) Payer initiated one-time payment by entering Payee VPA.

2) Payer initiated recurring payment by entering Payee VPA.

3) Payer initiated recurring payment by scanning dynamic or static QR.

4) Payee initiated P2P mandate request on the PSP app.

Accept / Reject mandate request (Payee initiated mandates)

1) Approving Payee initiated mandate.

2) Declining Payee initiated mandate.

1) Modify Payer Initiated mandate.

2) Payee initiated mandates can only be suspended and revoked by Payer.

3) Payer initiated mandate revoked.

In case of failed execution

UPI Mandate QR Specs

UPI Mandate QR created by Corporate/Merchant/Payee

Parameter Data Mandatory/ Mapped to Description

validitystart String M mandate Defines start time of

recur String M Mandate Specifies the frequescy of

recurvalue String M Mandate Specifies date along with

recurtype String M Mandate Can have

Parameter Data Mandatory/ Mapped to Description

Payer Initiated Mandate

Payee Initiated Mandate

Terms and Conditions

PSPs are required to store the mandates in a secured manner.

request lies with the Payer PSP.

means for scheduling their recurring payments

Mandate process in UPI shall simplify mandate lifecycle process.

SIGNED INTENT and QR

Objective of intent based payments is to incorporate simplicity, security and seamlessness in

b) Suggested flow for an unsigned intent

Terms and Conditions

PSPs should have the capability to generate as well as to respond to signed/unsigned

Signed key/token to be stored in a secured manner at the merchants server.

Das könnte Ihnen auch gefallen