The document discusses the Unified Payments Interface (UPI) system in India. It provides the following key points:
- UPI is an instant real-time payment system developed by NPCI that allows money transfers between bank accounts using a virtual payment address.
- UPI offers features like being open source, mobile-first, interoperable, instantaneous, secure, cheap, simple, innovative and easily adaptable.
- NPCI's central repository maps customers' Aadhaar numbers, mobile numbers and bank accounts to route payments based on these identifiers.
- The UPI system uses a virtual payment address architecture to facilitate payments between parties using identifiers like bank account numbers, Aad
3. NPCI
NPCI (National Payment Corporation of India) is the umbrella
organization for all the retails payments in India, which is set up by RBI
and IBA in April 2009.
NPCI launched the IMPS.
NPCI launched the RuPay card.
NPCI`s current initiative is the launch the UPI.
4. UPI
Unified Payment Interface is a system that provides an architecture
and standard set of APIs to facilitate the online immediate payments.
Core features of UPI :
Open Source
Mobile First
Interoperable
Instantaneous
Secure
Cheap
Simple
Innovative
Easily Adaptable
7. Understanding AEPB
and DBT with NPCI
Government Institution
Sponsor Bank Destination Bank
Beneficiary
NPCI Centrally
Mapped Repository
8. NPCI Central
Repository
NPCI’s maintains an association between customer’s Adhaar number, Mobile
number and Bank accounts. This central repository can be used to route payment
instructions based on Adhaar number or mobile number.
9. UPI with NPCI
Point of Sale
(Payer)
NPCI Centrally
Mapped Repository
UPI
The Payer/Payee information is sent, via PSP, to NPCI.
To identify the details of the second party involved, it
either uses its repository or it contacts the second party
PSP.
PSP to resolve
Virtual Address
10. UPI with NPCI
Payer`s Bank
Payee`s Bank
Point of Sale
(Payee)
Once both PSPs` information is available to NPCI proceeds with the debit and
credit processes.
On successful completion the payer and payee PSPs are notified, which then
notify their customers.
Point of Sale
(Payer)
13. Core Elements
in Payment
Other metadata attributes such as location, product code,
mobile number, device details, etc. as required.
Payer and Payee account and institution details for routing transaction.
Authentication credentials (password, PIN, biometrics, CVV, etc. as required for
debit, can be bank provided or 3rd party provided such as UIDAI).
Transaction amount.
Transaction reference.
Timestamp.
15. Virtual Payment
Address features
Unique mapping to Identifier (Person / Entity ).
Global Identifier ( Adhaar number and Mobile Number ).
PSPs can offer multiple virtual address to customers.
Pay and Collect Money.
Pre authorization of multiple payments using ECS one time
secure authentication and rule based access.
Standard set of APIs.
1-click 2- factor authentication.
16. Virtual Address
Archietecture
Normalized Architecture for payment address “account @ provider“
The address must include : ‘ a – z ‘ , ‘ A – Z ‘ , ‘ 0 – 9 ‘ , ‘ . (dot) ‘ , ‘ – (hyphen)’ .
The Payment Address can be issues by :
Bank : shyam.444@icici
PSP : abdul2014.irctc@mypsp
PPI : 000012346789@myppi
NPCI (using global identifiers )
- IFSC code and account number as account-no@ifsc-code.ifsc.npci
e.g. 12345@HDFC0000001.ifsc.npci
- Adhaar number as aadhaar-no@aadhaar.npci
e.g. 234567890123@aadhaar.npci
- Mobile Number as mobile-no@mobile.npci
e.g. 9800011111@mobile.npci
17. Virtual Address
Archietecture
- RuPay card number as card-no@rupay.npci
e.g. 1234123412341234@rupay.npci
- A one time or time/amount limited tokens issued by a PSP, resolved
directly by that PSP, is represented as token@psp-code
e.g. ot123456@mypsp
18. Virtual Address
Archietecture
If the virtual ID is not created using identifiers that NPCI
understands(Adhaar number, mobile number, IFCS code, Rupay card
number etc.) then NPCI requests PSP to decrypt address using Translate
APIs.
20. Types of
Payment Request
Direct Pay
- Sender/Payer Initiated
- System Initiated
Collect Pay
- Remote Collect
- Local Collect
21. Direct Pay
Sender Initiated
Sender provides his credentials and receiver`s virtual
address using his payment application.
E.g. Sending money to a friend.
System initiated
Digitally signed request with receiver virtual address.
E.g. System generated daily payment to agents.
22. Direct Pay
Sender Initiated
Sender provides his credentials and receiver`s virtual
address using his payment application.
E.g. Sending money to a friend.
System initiated
Digitally signed request with receiver virtual address.
E.g. System generated daily payment to agents.
Direct Pay Transaction Flow
23. Collect Pay
Remote Collect
Payee send the request to the payer (through USSD or Smartphone) on his
phone.
So the payee doesn`t have to enter any credential.
# Local exchange of encrypted credential is not currently supported in UPI.
The sender`s phone on the arrival of request become point of entry of
secure credentials.
Local Collect
Here the payer`s address is captured to send the payment request.
26. Important
features of API
APIs behind the existing systems at NPCI are done over ISO 8583 Messages
(0200/0210).
Asynchronous : The request and response sent via separate API.
Allowing the APIs to work in a non-blocked mode.
Unique Transaction ID for every response.
APIs exposed via HTTPS using XML input and output.
27. Important
features of API
API input data to set to URL in XML format with Content -Type
“application/xml” or “text/xml”
URL :
https://<host>/upi/<api>/<ver>/urn:txnid:<txnId>
host : API server address
upi : Static value to denote UPI transaction.
api : Name of the API URL endpoint
ver : Version of the APIs being used.
txnID : Transaction id which will be used for load balancing purpose at UPI end
28. Acknowledgement
API
All APIs have same ack response as given below:
<upi:Ack xmlns:upi="" api="" reqMsgId="" err="" ts=""/>
Ack : root element name of the acknowledgement message.
api : name of the API for which acknowledgement is given out.
reqMsgId : message ID of the input for which the acknowledgement is given out.
err : this denotes any error in receiving the original request message.
ts : the timestamp at which the receiver sends the acknowledgement.
30. API : ReqPay
Single API will be used for both Direct Pay and Collect Pay.
In Direct Pay, Sender will provide his/her complete credentials and only
the virtual address of the Receiver.
In Collect Pay, the Receiver will provider his complete credentials and
only the virtual address of the Sender.
31. API : RespPay
To send back the response of the ReqPay API after the transaction.
32. API : ReqAuthDetails
Used to authorize payment and also translate the PSP`s virtual address
to global identifiers like Mobile Number, Adhaar Number , Account +
ID)
33. API : RespAuthDetails
This API is used by PSPs to authorize payment and send the required
details to NPCI
34. API : List PSP
This API allows the PSPs to request for all the registered PSPs with NPCI.
This data is used for validating the PSP during the process of
transaction.
35. API : List Account
Providers
This API allows the PSPs to request for all the registered PSPs with NPCI.
This data is used for validating the PSP during the process of
transaction.
36. API : List Keys
This API allows the PSPs to request for and cache the list of public keys
of account providers and other entities in the UPI eco system
37. API : List Account
API allows PSPs to find the list of accounts linked to the
mobile by an account provider.
38. API : List Verified
Address Entries
API allows PSPs to request a and cache the List of Verified Address
Entries to protect customers from attempts to spoof well known
merchants such as LIC, Indian Railways, ecommerce players, telecom
players, bill payment entities, etc.
39. API : Validate Address
This API will be used by the PSPs when their customer wants
to add a beneficiary within PSP application (for sending & collecting
money).
40. API : Set Credentials
This API is required for providing a unified channel for setting and
changing MPIN across various account providers.
41. API : Check Txn
Status
This API allows the PSPs to request for the status of the transaction. The
PSPs must request for status only after the specified timeout period.
42. API : OTP-Request
This API allows the PSPs to request for an OTP for a particular customer
from an issuer.
44. API : HeartBeat
Messages
This API is a mechanism for UPI system monitoring.(monitoring
connection with PSPs and sending EOD to PSPs)
45. API : Request Pending
Messages
This API allows PSP to request pending messages against a given
mobile number or Adhaar number
46. API : Request Txn
Confirmation
This API provides transaction status confirmation from UPI to PSP. At the
end of every transaction, this API will be initiated to second PSP for
status confirmation
47. Time Bound Request
<Rules>
<Rule name="EXPIREAFTER" value="1 miniute to max 64800 minitues"/>
<Rule name="MINAMOUNT" value=""/>
</Rules>
The part of code below shows the time bound aspect of the
transactions.
49. Class of Information
Non-Sensitive data -
• Name, transaction history (amount, timestamp, response code, location, etc.)
• Can be stored in unencrypted form.
Sensitive Data -
• PIN, passwords, biometrics, etc.
• Not to be stored and should only be transported in encrypted form.
Private Data -
• Account number etc..
• May be stored by the PSP, but only in encrypted form.
50. Class of Information
PSP is mandated to use a secure protocol when transmitting sensitive data
such as account details from the device to the PSP server.
With Collect Pay request PSP needs to show the KYC information central
system (using the NPCI`s API).
PSPs is mandated to safeguard account information within PSP system as per
regulatory and the payment card industry (PCI DSS )compliance standards.
51. Protecting Authentication
Credentials
All APIs must be done over a secure channel (HTTPS).
Trusted common library for credentials (MPIN, PASSWORD, PIN BIOMETRIC ) is
provided by NPCI.
Payment Service provider can`t store issuer specific authentication credentials
outside common library.
Credentials encoded with Base64 encoding and are provided only during the
transaction by UPI.
PSP can`t store the encrypted credentials in any permanent storage.
Every messages within the unified system must be digitally signed.
Every message has unique transaction ID (that spans across the organizations
for same transaction) and unique message ID for every request-response pair.