Download as PDF

Download as PDF

Introduction

The Unified Payment Interface allows payments to be initiated by the payer, or by the payee. In the basic payee initiated flows, the payment request is routed by the initiating application through the NPCI switch to the payer for approval. However, in certain instances, where it is possible to connect with the payer immediately, it is preferred that the payee sends a payment request to the payer, who can then initiate the payment request with his credentials.

This leads to a significantly smoother payment experience. Some examples of these include in-app payments – where the merchant app, may send the request to the PSP app on the same device, instead of a collect request via the PSP network. Another example may be for proximity payments, where the payer and payee are using different devices, but are close enough for the information to be transmitted locally.

This document provides the technical specifications for developers to enable inter application payment requests.

  • Usage Examples

Example 1: Seamless in-app payment within the same mobile of the user.

  • Ashok is a student and uses a video application (MyStar) that allows buying on- demand movie on his Android phone.
  • He banks with DiBank (PSP in this case) and uses their mobile application for Android that has implemented UPI features.
  • In MyStar app, Ashok wants to watch a movie for Re.25.
  • MyStar application creates the UPI payment link as per this spec and launches the Android intent with all necessary parameters populated in the URL.
  • Since DiBank PSP app is registered to listen to UPI link/intent, it starts the app and takes Ashok straight to pay screen with all values pre-populated from the link/intent.
  • Ashok verifies the info on screen and click pay to complete the payment.

Example 2: Proximity payment at a merchant using QR code.

  • Mary uses her bank provided UPI application to make payments to nearby grocery store.
  • After the purchase, grocery store PoS application generates a dynamic QR code containing the UPI link (as per this spec) with the payment details.
  • Mary opens the UPI application on her mobile and scans the QR code on the PoS device or on the bill printed by the PoS.
  • UPI application takes her straight to pay screen with all values pre-populated from the link/intent.
  • She verifies the info on screen and click pay to complete the payment.
  • Both merchant and she gets confirmation instantly.

Note that a real small one person shop could simply print a static QR code containing the payee address and name without having software to generate dynamic QR code with other information such as bill number, amount, etc. In the case of static QR code, customer, after scanning, should enter the amount and then make the payment.

Example 3: DTH payment from home.

  • Nadeem subscribes to DTH in his house and wants to make a payment for on- demand subscription.
  • Nadeem selects the channel and clicks “buy now”.
  • DTH shows the details along with a QR code for UPI payment.
  • He verifies the info on screen and click pay to complete the payment.
  • UPI application takes him straight to pay screen with all values pre-populated from the QR code which contained the standard UPI link.
  • Nadeem opens his UPI application on his mobile and scans the QR code on the TV screen.
  • He gets a confirmation on his mobile and the TV channel is automatically turned on for him to view.
  • Link Specification and Parameters

UPI Deep linking URL spec must be as follows. All PSP applications must mandatorily implement listening to “UPI” links within their mobile applications.

upi://pay?parm-name=param-value&param-name=pram-value&…

Where param-name can be any of the valid parameters (based on mandatory vs optional) listed in below table.

Parameter name

Data type

Mandatory

Mapped to UPI API field

Description

pa

String

M

Payee–>addr

Payee VPA

pn

String

M

Payee–>name

Payee name

mc

String

O

Payee–>mcc

Payee merchant code

tid

String

O

Txn –>id

This must be PSP generated id when present. In the case of Merchant payments, merchant may acquire the txn id from his PSP.

tr

String

C

Txn-->refId

Transaction reference ID. This could be order number, subscription number, Bill ID, booking ID, insurance renewal reference, etc.

Conditional – This field is Mandatory for all Merchant transactions.

tn

String

O

Txn-->note

Transaction note providing a short description of the transaction.

am

String

O

Payee–> Amount–>value

Transaction amount in decimal format.

mam

String

O

Txn –>Rules –> MINAMOUNT

Minimum amount to be paid if different from transaction amount.

cu

String

O

Payee–> Amount–>curr

Currency code. Currently ONLY “INR” is the supported value.

url

String

O

TxnrefUrl

This should be a URL when clicked provides customer with further transaction details like complete bill details, bill copy, order copy, ticket details, etc. This can also be used to deliver digital goods such as mp3 files etc. after payment.

This URL, when used, MUST BE related to the particular transaction and MUST NOT be used to send unsolicited information that are not relevant to the transaction.

Developers who are developing merchant applications, mobile apps wanting to initiate UPI payment) should form the URL within their application and then do either of the following:

  • If the application and the PSP UPI application is within the same mobile, then do a deep linking using the URL.
  • Create a QR code within the application and allow customers to scan it and invoke their UPI application.
  • Use alternate transfer protocol (such as BT, WiFi Direct, NFC, Sound, etc.) to transfer the URL data to customer mobile on which is gets deep linked to their PSP application.
  • Create the URL and allow standard “share” allowing a UPI payment intent to be sent via chat or email. Receiver will click on the link to then invoke their PSP application.

Using a standard data format and URL scheme allows the actual protocol of data transfer to be separated out and thus allowing any transfer protocol to be used to transfer this from one device to another.

Implementation Samples

Hyperlink

The user goes to an ecommerce website (Rohit Stores) on his mobile phone, and places an order. The website generates a link, which the user can click on, to complete the payment.

As per the specification, the link contains the payee details, the transaction reference (order id), and the amount to be paid.

Example:

upi://pay?pa=zeeshan@npci&pn=Zeeshan%Khan&mc=0000&tid=cxnkjcnkjdfdvjndkjfvn&tr=4894398 cndhcd23&tn=Pay%to%rohit%stores&am=1010&cu=INR&refUrl=https://rohit.com/orderid=9298yw 89e8973e87389e78923ue892

When the user clicks on the link on his mobile browser, it invokes the local PSP application, where the user can confirm the details, and complete the payment.

Because of the design simplicity, user familiarity with hyperlinks, and the ease of sharing, such links can be generated and shared across multiple communication channels, such as email, chat, and social networks.

QR Code

QR code consists of black modules arranged in a square pattern on a white background. The information encoded can be made up of four standardized kinds (“modes”) of data (numeric, alphanumeric, byte/binary, Kanji), or by supported extensions virtually any kind of data.

QR codes can be used for proximity payments with UPI. Developers who are developing merchant applications must generate a URL fully compliant to specification in previous section and then create a QR code of that URL.

Example:

upi://pay?pa=zeeshan@npci&pn=Zeeshan%Khan&mc=0000&tid=cxnkjcnkjdfdvjndkjfvn&tr=4894398 cndhcd23&tn=Pay%to%rohit%stores&am=1010&cu=INR&refUrl=https://rohit.com/orderid=9298yw 89e8973e87389e78923ue892


Note to PSPs: Considering the simplicity, openness, and wide acceptance of QR codes and its ability to be printed, displayed on PoS devices, and various screens, etc., PSP applications are encouraged to include a QR code scan option within their UPI application so that customers can use a single app to scan and pay.

Others

UPI linking is protocol agnostic and hence allows innovative mechanisms between merchant/proximity devices to send a UPI intent to customer phone.

For example, a merchant PoS application could create the UPI link (as per spec in previous section) and then transmit using sound to the customer device. Customer PSP app or a utility app can listen to that sound, convert it back to the link, and then launch the UPI application on customer phone to make the payment.

Note that there can be 3rd party general purpose utility applications that allows users to scan these QR codes, launch the link, allow other innovative transfer protocols using sound, etc. Such apps can work as a proxy utility that sends/receives these links and then launch the appropriate apps that are listening to these intents.

SHARE
Previous articleSmart City Mission
Next articleUPI in simple Words – New Payment system of RBI
We are not passionate to get succeeded in Exambin, We are passionate about you getting succeeded in Life. If we are able to give some valuable information to our readers we merit that as our success.