OC 101

Identification of Ultimate
Beneficiary for P2M transactions
Clarification document
AGENDA
• Background
• Tag clarification
• Role of onboarding entity
• Role of Payee PSP
• Role of Aggregator
• Role of Payer App
• Special cases – pool account
• FAQs
Background
• To improve the customer experience and strengthen the beneficiary
verification function, UPI, vide OC 101 dated 25th February 2021
mandated the showcasing of identity of Ultimate Beneficiary in UPI
P2M transactions
• This will be displayed on the Payer App as well as during display of
transactions statements / history
• The Ultimate Beneficiary is defined as the entity who is receiving
funds (credit) in lieu of goods/services rendered directly by them.
• The deadline for the said compliance was 15th April 2021
 Name of Ultimate-Beneficiary
TITLE Type of TAG NAME DATA DATA SIZE VALUE TO PASS
transaction TYPE
Name of PAY <maskName> String 99 Characters • Verified Merchants: Mandated to convey
Ultimate field in the the Brand name of the merchant only.
Beneficiary <Resp> Tag • Non-Verified Merchant: Mandated to
convey either Validated Brand name or CBS
Collect <name> field in name of the merchant. The Payee PSP is
the <Payee> responsible for authenticity of the validated
tag brand name.

• Name of ultimate beneficiary is the accurate name of the individual/business whose account will be credited with this
payment
• Name of end beneficiary has to be passed by the acquiring entity accurately
• Aggregators/Payer apps who have on-boarded multiple billers are mandated to send the name of end beneficiary
• Banks should perform the ValAdd (Validate Address) for every transaction
• Verified merchants are merchants which are verified with NPCI using Request Manage VAE (ReqManageVae). Please refer
OC 76 for more details.
 Merchant Genre
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Merchant Genre <merchantGenre> String ONLINE/ OFFLINE “Online” or “Offline” basis the genre of the on-
boarded merchant & transaction type.

• Merchant Genre is the Genre (Online/Offline) based on the merchant and the transaction type
• If the user is booking/buying the goods/services from a website/an application, then the merchant genre will be “Online”
• If the user is booking/buying the goods/services from a physical store location, then the merchant genre will be “Offline”
• The same merchant can have both Online & Offline presence in which case this tag is to be filled using the type of
transaction by the merchant.
• Example: If a restaurant has an offline location presence as well as an online website to order food from, and has the
same UPI ID. It is the responsibility of the acquirer to populate the correct value in this tag as per below table.

Merchant Name Scenario Value to pass

Seaside restaurant Mr. A goes to the physical location of Seaside restaurant
Offline
and orders food to eat-in or take-away.
Seaside restaurant Ms. B goes to seasideresto.com (The website of Seaside
Restaurant) and orders food online to be delivered to her Online
home
 Onboarding Type
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Onboarding Type <onBoardingType> String BANK / “Bank” or “Aggregator” based on which entity has
AGGREGATOR on-boarded the merchant on UPI.

• Onboarding type is basically the identification of the type of acquiring entity of the merchant.
• The two possible entities which can onboard a merchant are 1. Bank & 2. Aggregator
• Please find the detailed table below for various scenarios and the respective value to be passed for the same

Merchant settlement bank Merchant Acquiring entity Value to input

(Where merchant A/c is held)
Example: Merchants who hold ABC Bank XYZ Aggregator Aggregator
their A/c in PayTm Payments Bank ABC Bank ABC Bank Bank
and are onboarded by Paytm
aggregator team. Bank MNO Aggregator MNO Aggregator
 Sub Code
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Sub Code <subCode> Numeric 4 digits MCC based on actual goods/services rendered by
the merchant.
• MCC is the Merchant Category Code. Merchant category codes (MCC) are four-digit numbers used by to categorize the
purchases that customers complete using a particular card.
• The value to be populated in the SubCode tag is the MCC based on actual goods/services rendered by the merchant.
• As more and more service aggregation happens, there are merchants who have a parent MCC(Merchant Category Code)
but provide goods/services pertaining to different MCC. In this case, the MCC of actual goods/services rendered should
be populated in the SubCode tag.
• In case there is no difference between the Merchant’s Parent MCC and the goods/services rendered, the value to be
populated in SubCode should be the same as that of Parent MCC.
Parent Merchant Parent Merchant MCC according to Actual Goods/Services Subcode to be
Name Goods/Services Parent Merchant rendered by the customer populated
Services
Online food ordering Food restaurants 5814 : Restaurants Ordering food from App 5814 : Restaurants
Online food ordering Food restaurants 5814 : Restaurants Ordering Grocery from App 5411 : Grocery
 Merchant ID (MID)
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Merchant ID <mid> String 20 Characters • Merchant ID
• Unique Merchant ID to be mapped to every
beneficiary

• A MID (Merchant ID) is a unique ID associated with the particular acquired merchant.
• It is mandated that all acquirers to assign and populate a unique value for every merchant (Basis UPI ID) for all merchants.
• In case where an acquiring entity is using the same UPI ID for different merchants, it is the acquirer’s responsibility to
provide unique MID to each end-beneficiary.
 Store ID (SID)
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Store ID <sid> String 20 Characters • Store ID.
• In case a merchant does not have multiple
stores, the SID is to be populated as “0000/NA”

• Store ID (SID) is a unique ID assigned to respective store location of the merchant.

• For example, Big Bazaar as a merchant will have a unique Merchant ID as said in the preceding slide. Big Bazaar in
Andheri, Mumbai location will have a unique Store ID. Similarly, Big Bazaar in Sector 24, New Delhi location will have a
different unique Store ID.
• The Store ID is beneficial to identify and reconcile the exact location of transaction basis the MID, SID & TID combination
and helps us in issue resolution if any.
• In case a particular merchant does not have multiple stores, the Store ID (sid) tag should be populated as “0000”.
Merchant Name Has multiple Stores? Store Location Sample MID Sample SID
Merchant ABC Yes Juhu, Mumbai ABC123 ABC7765
Kothrud, Pune ABC123 ABC8796
Merchant XYZ No Indiranagar, Banglore XYZ123 0000
 Terminal ID (TID)
TITLE TAG NAME DATA TYPE DATA SIZE VALUE TO PASS
Terminal ID <tid> String 20 Characters • Terminal ID.
• In case a merchant does not have multiple
terminals, the SID is to be populated as
“0000/NA”
• Terminal ID (TID) is a unique ID assigned to respective terminal of the merchant.
• Here, terminal means the terminal where UPI Payments are accepted. This could be via POS machines using dynamic QR
codes or via different Static QR codes at various terminals at the merchant location.
• The Terminal ID is beneficial to identify and reconcile the exact location of transaction basis the MID, SID & TID
combination and helps us in issue resolution if any.
• In case a particular merchant does not have multiple stores, the Store ID (sid) tag should be populated as “0000”
Merchant Has multiple Store Location Sample Sample Has multiple Sample TID
Name Stores? MID SID Terminals?
Merchant ABC Yes Juhu, Mumbai ABC123 ABC7765 Yes ABC8765
Juhu, Mumbai ABC123 ABC7765 ABC8775
Merchant XYZ No Indiranagar, Banglore XYZ123 0000 No 0000
Role of Onboarding Entity
• All onboarding entities (Banks/Aggregators) must do the proper KYC
of the merchant and record all the requisite details of the merchant
• These values should be populated accurately in the respective tags as
mentioned only
• On a regular basis, these values should be checked and updated if
necessary for the respective acquired merchants
• All the respective values have to be passed in every leg of
transaction as applicable
Role of Payee PSP
• Payee PSP is mandated to populate all the above mentioned tag
values accurately in the respective tags only.
• Payee PSP is mandated to follow the constraints/specifications
mentioned while populating the tag values appropriately.
• All the respective values have to be passed in every leg of
transaction as applicable
Role of Aggregator
• Aggregators must do the proper KYC of the merchant and record all
the requisite details of the merchant while onboarding
• Aggregators should provide unique UPI IDs for unique merchants.
• In case of pool-account based system, aggregators must supply
MID/TID/SID for accurate sub-merchant identification.
• All the respective values have to be passed in every leg of
transaction as applicable
Role of Payer Apps
• Payer Apps should read the respective tag values from the above
mentioned tags only
• Payer apps should not modify/delete the values in the above
mentioned tags and should only pass the value present
• All the respective values have to be passed in every leg of
transaction as applicable
Special cases – Pool A/C
• In case of pool accounts, like billers etc., it has been observed that there is a
single UPI ID against which different billers are marked.
• This creates a lot of confusion for customers, especially in case of UPI
Autopay recurring mandates, where the customer has multiple mandates
but is unable to figure out which mandate is for which merchant
• It is mandated that the acquiring entity, in such cases, must display the
name of end beneficiary using some mechanism to the end user, so that the
end user has visibility on the merchant to which payment is done or will be
done.
• In case where the App used for setting up UPI Autopay is different from the
acquiring app/entity, the entity should pass the accurate name of end
beneficiary biller to the UPI app
Special cases – Pool A/C
EXAMPLE: INCORRECT IMPLEMENTATION EXAMPLE: CORRECT IMPLEMENTATION

Autopay AIRTEL BILL PAYMENT

8888999999

Autopay AIRTEL BILL PAYMENT 8888999999

Autopay AIRTEL BILL PAYMENT 8888999999

FAQs
Q1) What is a verified merchant?
Ans: Merchants which are verified with NPCI using Request Manage
VAE (ReqManageVae). Please refer OC 76 for more details.
Q2) If there are different UPI IDs provided to the same merchant for
different services, what to populate in subCode?
Ans: It is advised that there should be a single UPI ID given to a
merchant and further bifurcation should be basis identifiers like MID,
SID, TID & Subcode. In case there are different UPI IDs provided to the
same merchant for different services, and now the parent MCC of that
UPI ID is same as the goods/services rendered, the Subcode should be
populated as “0000”
FAQs
Q3) What if the merchant acquired does not have multiple stores?
If the merchant acquired does not have multiple stores, then both SID
& TID values is to be populated as “0000”.
Q4) What if the merchant acquired has multiple stores, but does not
have multiple terminals of payment acceptance?
Ans: In case the merchant acquired has multiple stores but has only a
single terminal per store, the TID value should be populated as “0000”
Q5) What will be the SID & TID for online merchants?
And: For merchants with merchant genre as online, SID & TID will not
be applicable and hence should be populated as “0000”