Unified Payment
Interface
National Payment Corporation of India
- Akash Chandra
What is NPCI ?
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.
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
How UPI
Functions with
NPCI ?
First Understanding
AEPB and DBT with NPCI
AEPB : Adhaar Enabled Payment Bridge
DBT : Direct Benefit Transfer
Understanding AEPB
and DBT with NPCI
Government Institution
Sponsor Bank Destination Bank
Beneficiary
NPCI Centrally
Mapped Repository
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.
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
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)
Technical
Architecture of
UPI Gateway
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.
Virtual Payment
Address
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.
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
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
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.
Payments
Structure
Types of
Payment Request
 Direct Pay
- Sender/Payer Initiated
- System Initiated
 Collect Pay
- Remote Collect
- Local Collect
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
 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
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.
Collect Pay
Collect Pay Transaction Flow
API Handling
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.
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
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.
19 APIs provided
by UPI
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.
API : RespPay
 To send back the response of the ReqPay API after the transaction.
API : ReqAuthDetails
 Used to authorize payment and also translate the PSP`s virtual address
to global identifiers like Mobile Number, Adhaar Number , Account +
ID)
API : RespAuthDetails
 This API is used by PSPs to authorize payment and send the required
details to NPCI
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.
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.
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
API : List Account
 API allows PSPs to find the list of accounts linked to the
mobile by an account provider.
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.
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).
API : Set Credentials
 This API is required for providing a unified channel for setting and
changing MPIN across various account providers.
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.
API : OTP-Request
 This API allows the PSPs to request for an OTP for a particular customer
from an issuer.
API : Balance-Enquiry
 This API Allows PSP to Request for Balance enquiry for a
user.
API : HeartBeat
Messages
 This API is a mechanism for UPI system monitoring.(monitoring
connection with PSPs and sending EOD to PSPs)
API : Request Pending
Messages
 This API allows PSP to request pending messages against a given
mobile number or Adhaar number
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
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.
Security
Considerations
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.
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.
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.
Thanks!
Thank You !!

Unified Payment Interface

  • 1.
    Unified Payment Interface National PaymentCorporation of India - Akash Chandra
  • 2.
  • 3.
    NPCI NPCI (National PaymentCorporation 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 Interfaceis 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
  • 5.
  • 6.
    First Understanding AEPB andDBT with NPCI AEPB : Adhaar Enabled Payment Bridge DBT : Direct Benefit Transfer
  • 7.
    Understanding AEPB and DBTwith NPCI Government Institution Sponsor Bank Destination Bank Beneficiary NPCI Centrally Mapped Repository
  • 8.
    NPCI Central Repository  NPCI’smaintains 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 Pointof 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`sBank 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)
  • 11.
  • 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.
  • 14.
  • 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 Architecturefor 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 - RuPaycard 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 thevirtual 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.
  • 19.
  • 20.
    Types of Payment Request Direct Pay - Sender/Payer Initiated - System Initiated  Collect Pay - Remote Collect - Local Collect
  • 21.
    Direct Pay  SenderInitiated 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  SenderInitiated 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  RemoteCollect 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.
  • 24.
    Collect Pay Collect PayTransaction Flow
  • 25.
  • 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 APIshave 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.
  • 29.
  • 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 : ListPSP  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 : ListAccount 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 : ListKeys  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 : ListAccount  API allows PSPs to find the list of accounts linked to the mobile by an account provider.
  • 38.
    API : ListVerified 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 : ValidateAddress  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 : SetCredentials  This API is required for providing a unified channel for setting and changing MPIN across various account providers.
  • 41.
    API : CheckTxn 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.
  • 43.
    API : Balance-Enquiry This API Allows PSP to Request for Balance enquiry for a user.
  • 44.
    API : HeartBeat Messages This API is a mechanism for UPI system monitoring.(monitoring connection with PSPs and sending EOD to PSPs)
  • 45.
    API : RequestPending Messages  This API allows PSP to request pending messages against a given mobile number or Adhaar number
  • 46.
    API : RequestTxn 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> <Rulename="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.
  • 48.
  • 49.
    Class of Information Non-Sensitivedata - • 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  AllAPIs 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.
  • 52.