Fintech Bengalathon Guidelines v1.1 · 3.2. Bengalathon has five problems pertaining to Fintech domain. Participant have to select “Financial Services” and/or “ideation” domain

Bengalathon – Instruction & Guidelines

P a g e 1 | 4

FINTECH BENGALATHON – INSTRUCTIONS & GUIDELINES

Participants are requested to read all the instructions carefully before applying for

registration.

1. Registration Process

1.1. Registration and application submission to be done online only.

1.2. Only tech individuals/students can apply for the competition.

1.3. Participant who have already registered, can update their profile information under

“Edit Profile” option.

1.4. Last date for registration and application submission (Please see “Important Dates”

section of this document).

1.5. For Registration, Click on “Create an Account” from the following page of

Bengalathon portal i.e. (https://bengalathon.wb.gov.in/). Points marked with “*” are

mandatory fields.

1.5.1. *Team: Provide your team name.

1.5.2. *Gender

1.5.3. LinkedIn Profile: Embed your LinkedIn profile

1.5.4. *Date of birth

1.5.5. *Phone number

1.5.6. *State and district: Please select your State and District from the Drop down

list. Participant to select “Others” option if the district name is not available.

1.5.7. *One of the identification proofs (Voter Id/ AADHAAR/ PAN Card/ Passport)

1.5.8. *Domain knowledge: Select your domain from the various options available in

the select dropdown list. Participants can only access problems coming under

the domain specified. You can select more than one/all domain. Participant

should select “Financial Services” option in order to access all the problem

statements in Fintech domain.

1.5.9. *Photo: Upload your team photo.

1.5.10. *CV: Create your CV having the following details only i.e. Name, Date of Birth,

Company / College, Company / College / Individual Address, Company /

College / Individual Phone number and email id, Qualification, Brief summary


P a g e 2 | 4

on experience (not more than 200 words), Photo, Email id, Phone Number and

ID proof. If you’re representing a team, then combine the CV’s of all team

members one after the other, in one document and upload. Accepted file

formats are doc, docx and pdf. A sample CV is provided in Annex – CV Format.

2. Team Formation Process

2.1. There is no restriction in number of teams from a particular college / organization /

institution.

2.2. Any number of team of individuals from a company/college can participate.

2.3. Clearly communicate the email-ids and mobile numbers of all team members (in CV

section).

2.4. No individual can be a part of more than one team.

2.5. Team can bring in their own mentors. Details of mentor should be mentioned in the

CV.

2.6. The team size is restricted to 5 members including mentors.

3. Participation in a problem

3.1. Once registered, teams/individuals will have access to the problem statements.

3.2. Bengalathon has five problems pertaining to Fintech domain. Participant have to

select “Financial Services” and/or “ideation” domain in order to access all the

problem Statements.

3.3. Each team can participate in one to all the available challenges.

3.4. Click on “Participate” against a given challenge.

3.4.1. Team will be able to view the details of challenge

3.4.2. Why you want to participate? Provide justification on how you have understood

the challenge and give a brief description of the solution you want to propose for

this challenge. The justification and brief description should not be more than

500 words.

3.4.3. You need to upload the concept note and the detailed solution to the problem

statement before the cut-off date. Submit your application and wait for the

results of the first round evaluation.

4. Evaluation criteria


P a g e 3 | 4

4.1. There would be two rounds of evaluation.

4.2. In each round, the evaluation criteria will include novelty of the idea, complexity,

clarity, feasibility, practicability and sustainability, scale of impact, user experience

and potential for future work progression. Your solution will be evaluated based on

the following parameters.

4.2.1. Usefulness — the solution shall have a positive impact.

4.2.2. Usability — the solution is intuitive and easy to use.

4.2.3. Originality — the solution provides an innovative or creative approach to an idea

and should not be copy of already existing app/game.

4.2.4. Financial implications – The solution should have revenue model

4.2.5. Risk, Issues and Mitigation plan

5. Shortlisting of entries

5.1. First round evaluation: Jury will verify the concept note and detailed solution (as

mentioned in 3.4.3 and evaluate your submission on basis of the parameters

mentioned in section 4.2. Selection of participants for final round will be done on

basis of the entries (concept note and detailed solution) submitted.

5.2. Final round evaluation: Shortlisted participants from first round will design and

develop the solution within the mentioned timeline (please see “Important Dates”

section of this document) and will present the same to the juries.

5.3. Selection of winner: Participants will showcase the solution to the jury and the best

3 solutions will be awarded (cash prize and trophy). Apart from overall merit list,

there will be district level winners. Best solution from districts will also be awarded

(trophy).

6. General information

6.1. Participant should reach out to [email protected] for any sort of

general/technical queries.

6.2. Shortlisted participant will receive email notification.

6.3. The final round is going to be held in Kolkata. Venue for the final round will be

communicated to the shortlisted participants over email.

6.4. No TA/DA will be provided to any teams of company during the process.


P a g e 4 | 4

7. Access to API’s

7.1. Participants will have access to API’s provided by National Payment Corporation of

India in order to integrate the payment module in their application.

7.2. A basic about product details is attached in Annexure A – NPCI product details.

7.3. Participant qualifying for second and final round will be provided with more details

about the product which would help them develop the actual solution.

8. Important Dates

8.1. 20th July 2018: Fintech Bengalathon launch

8.2. 20th July 2018 – 14th August 2018: Registration and Idea submission (First round).

8.3. 17th August 2018: Notification to shortlisted candidates

8.4. 17th August 2018 – 12th September 2018: Solution development period

8.5. 13th September: Presenting solution to Jury. (Final round.)

8.6. 14th September 2018: Announcement of winners

9. Support

Please drop us a mail at [email protected] for any queries.

10. Disclaimer

The decision of the juries will be final and no further communication on this will be

entertained. The conditions are subject to modification as per the decision of the

competent authorities.

BriefIntroduction

IMPS, UPI, BHIM & *99#on

2

Sr. No Features BANK's UPI APP BHIM *99# IMPS

1 Launch Year 25th August, 2016 30th December, 2016 28th August, 2014 22nd November, 2010

2 Availability 24*7*365 24*7*365 24*7*365 24*7*365

3 Languages Available EnglishCurrently 9 (3 morelanguages to come)

Currently 9(3 more languages tocome)

Varies across members

4 User Interface PSP ( Guidelines from NPCI) Standard Standard Varies across members

5 Channel Mobile (Data) Mobile (Data) Mobile (USSD)Branch, INET, Mobile, ATM, IVR,

SMS

6 Charges Channel Charges ( Data & SMS)Channel Charges ( Data &

SMS)Channel Charges 0.50/txn) Channel + Bank charges

7Transaction Limitper txn 1,00,000 10,000

5,000 Bank's - 2,00,000 , PPI's – 5,000

8Transaction Limitper day 1,00,000 20,000

Bank’s discretion Bank’s discretion

9Ecosystem (tilldate)

Bank – 27 Bank - 36 Bank - 27, Telco's - 10 Bank - 165, PPI - 25

10 MPINCreated on Bank's UPI APP, can

be used on *99# & BHIM

Created on BHIM, can beused on *99# & Bank's

UPI APP

Created on *99#, cannot be usedon BHIM & Bank's UPI APP

Works on existing channelauthentication

11 Send Money UsingAccount + IFSC, Mobile+MMID,

VPAAccount + IFSC, Mobile

No, VPAAccount + IFSC, Mobile+MMID,

VPA, Mobile NoAccount + IFSC, Mobile+MMID,

Aadhaar No.

12 Services Pay & Collect Pay & Collect Pay & Collect Pay

In Nutshell >>>>

Immediate Payment Service

Click to edit Master title style

An innovative“real-time” payment

service that is available“round-the-clock”

(even on holidays) andfacilitates interbank

(available with select PPIsalso), Account to Account(or to wallets* also) fund

transfer.

Public -

IMPS

IMPS Ecosystem as on March, 2017

Member Type TOTAL P2P P2AP2M &

M2PFIR ABRS Branch ATM INET

Public Sector Bank 27 27 27 17 15 8 13 5 25

Private Bank 20 17 20 11 13 4 4 4 19

Foreign Bank 6 5 6 5 2 0 0 1 4

Co-operative Bank 93 78 82 24 0 15 33 0 4

RRB 28 15 28 2 0 0 16 0 0

Payment Bank 4 0 3 0 0 0 0 0 2

BANK 178 143 167 59 30 27 66 10 55

PPI 25 7 25 3 0 3 0 0 20

Total 203 145 181 62 30 30 61 10 75

Public -

IMPS Eco SystemIMPS Eco System

Benefits of IMPSBenefits

Real-time domestic fundtransfer

24 X 7 X 365 availabilitySimple, fast and easy to

use

Fast, Inexpensive, Safeand secure

Channel IndependentAADHAAR No. basedtransaction enabled

Financial and non-financial service available

Alternate input optionsMultiple access

mechanism

Unified Payments Interface

Push and Pull Payments

Virtual Address(‘Username@PSPName’)

(No need to share Bankaccount details)

Transfer using Singleidentifier like Virtual

Address or Aadhaar No

Banks – (Payment ServiceProvider) will provide Appto customers of any bank

One App for all transactionneeds

Single Click 2 FactorAuthentication

Unified Payments InterfaceUnified Payment Interface

The Unified PaymentsInterface (UPI) offersarchitecture and a set ofstandard ApplicationProgramming Interface (API)specifications to facilitateonline payments. It aims tosimplify and provide a singleinterface across all NPCIsystems besides creatinginteroperability and superiorcustomer experience

9

National Unified USSD Platform

Simplicity – Userrequired to justdial a short code

Convenient –Single codeacross allOperators

Round the ClockAvailability –

Works 24*7*365

Real TimeTransaction –Immediate in

nature

LanguageFlexibility –

Available in 9languages

Easy Accessibility– No internetconnection

required

*99#

*99# (National UnifiedUSSD Platform), is aninteroperableinfrastructure, comprisingbanks & telecomoperators, using USSDtechnology to providebanking services through acommon platform. USSDtechnology, till now wasused primarily in the fieldof telecommunication , auser can access bankingservices by just pressing*99# from his/her mobilephones. This service worksacross all GSM mobilehandsets.

Financial Transactions

• Send Money (VPA)

• Send Money (Mobile No.)

• Send Money (IFSC & Account No.)

• Send Money (Aadhaar)

• Request Money

Non-Financial Transactions

• Check Balance

• Transactions

• UPI PIN (Generate & Change)

Value Added Service• Aadhaar Linking Status(*99*99#)

• PMJDY A/C Overdraft Status (*99*99#)

Services Offered

13

Bank live on *99#

Banks Name (Nuup 2.0) Banks Name (Nuup 1.0)Allahabad Bank Indusind Bank Abhyudaya Co-op Bank

Andhra Bank Karnataka Bank Apna Sahakari BankAxis Bank Kotak Mahindra Bank Federal Bank

Bank of Baroda Oriental Bank Of Commerce Gujarat State Co-op Bank

Bank of India Punjab National Bank Hasti Co-op BankBank of Maharashtra South Indian Bank Janata Sahakari Bank

Canara Bank State Bank Of Bikaner & Jaipur Kalupur Commercial Co-operative BankCentral Bank of India State Bank of Hyderabad Karur Vysya Bank

City Union Bank State Bank of India Mehsana Urban Co-op BankCorporation Bank State Bank of Mysore Nainital Bank

DCB Bank Ltd. State Bank of Patiala NKGSB Co-op Bank

Dena Bank State Bank of Travancore Punjab & Maharashtra Co-op BankHDFC Bank Syndicate Bank Punjab & Sind BankICICI Bank TJSB Bank RBL BankIDBI Bank UCO Bank Saraswat BankIDFC bank Union Bank Of India Tamilnad Mercantile Bank

Indian Bank United Bank Of India Yes BankIndian Overseas Bank Vijaya Bank

36 bankslive on

Nuup 2.0&

17 Bankslive on

Nuup 1.0

Bharat Interface for Money

Bharat Interface for Money(BHIM) is an app that lets youmake simple, easy and quickpayment transactions usingUnified Payments Interface

(UPI). User can make instantbank-to-bank payments andPay and collect money using

just Mobile number or VirtualPayment Address (VPA)

Single Unique Identifier (VPA, Aadhaar Pay , account number+IFSC and Mobile No based transfers)

Multiple Languages with Simple Interface

Link any UPI enabled bank account

Real-time debit and credit alerts in-App,through SMS and in TXN history

QR Code based Payments (Scan and Pay)

Report Spam - User declines the collect request, he can click onReport spam option in transaction detail page

BHIM

Available on

16

Few Stats on UPI, BHIM, USSD 2.0 & IMPS >>>>

Product 2016-17 UPI USSD 2.0 UPI + USSD 2.0 BHIM

UPI

Transaction Count ( In Mn ) 17.1 0.77 17.87 6.19

Value ( In Cr) ₹ 6,843.56 ₹ 108.58 ₹ 6,952.14 ₹ 1,804.60

Avg Transaction Size ₹ 4,003 ₹ 1,409 ₹ 2,891 ₹ 2,915

Product March - 17 UPI USSD 2.0 UPI + USSD 2.0 BHIM

UPI


Value ( In Cr) ₹ 2,391.38 ₹ 33.76 ₹ 2,425.14 ₹ 1,568.28


BHIMDownloads

20.20 Mn

IMPSFIR Total

Mar-17 2016-17 Mar-17 2016-17


Value ( In Cr) ₹ 1,892 ₹ 13,449 ₹ 56,468 ₹ 4,11,863


Internalchannels

Start-ups &Fintech

companies

Product Opportunity & Strategy:

The two BHIM schemes (merchant usage)

Promotion of digital payments using BHIM app through two promotionalschemes:

Referral Bonus Scheme for individuals

Cashback Scheme for merchants

Objective of the scheme

• Increase number of users downloading / installing and registering for BHIM.

• Increase in number of transactions via BHIM

It is aiming to bring 5 crore new users on BHIM with 15 crore transactions.

• Applicable on completion of minimum 3 unique successful.• Transactions totaling to Rs. 50 to any 3 unique users (P2P or P2M)

ComponentsAmount (in Rs.) spent to bring new BHIM user

on-board

New BHIM user (Referee) (per person) 25

Referrer (per person) 10

Total referral bonus amount per new BHIM user

to be on-board35

Total Cashback Payout for Projected new BHIM

users through referral scheme ( 5 crore users @

rate of Rs.35/-)

Rs. 175 crore

Referral Bonus Scheme for individuals

Transaction Criteria to qualify for cash back:

• Min 50 credit financial trans of which at least 20 trans is from valid UPI unique customers

including that of BHIM

• Min trans value for all above transactions should be Rs. 25

No. of credit transactions (per

month)

Cashback to the merchant

(at the end of the month)Conditions

50-100 Rs 100

From at least 20 unique customers;

Minimum transaction value of Rs. 25 each>10050 paise per transaction maximum

upto Rs. 200

Total Cashback Pay out

Rs. 270 crore (15 lakh merchants @

rate of Rs.1800/-)

Cashback will be in range of INR100 to INR

300 and with maximum cashback of 1800 for

6 month

Cash back Scheme for Merchants

BBPS API Sepcifications v11.0 Page 1

BBPS API Sepcifications

v11.0


Table of Contents

1 Bill Fetch Request ___________________________________________________________________ 4

Sample Bill Fetch Request API ______________________________________________________________ 4

Bill Fetch Request Tag Details ______________________________________________________________ 5

Bill Fetch Request XSD ____________________________________________________________________ 6

2 Bill Fetch Response __________________________________________________________________ 7

Bill Fetch Response Sample API _____________________________________________________________ 7

Bill Fetch Response Tag Details _____________________________________________________________ 7

Bill Fetch Response XSD ___________________________________________________________________ 8

3 Bill Payment Request _______________________________________________________________ 10

Bill Payment Request Sample API __________________________________________________________ 10

Payment Request Tag Details _____________________________________________________________ 11

Bill Payment Request XSD ________________________________________________________________ 12

4 Bill Payment Response ______________________________________________________________ 13

Bill Payment Response Sample API _________________________________________________________ 13

Bill Payment Response Tag Details _________________________________________________________ 13

Bill Payment Response XSD _______________________________________________________________ 14

5 Diagnostic Request _________________________________________________________________ 15

Diagnostic Request Sample API ____________________________________________________________ 15

Diagnostic Request Tag Details ____________________________________________________________ 15

Diagnostic Request XSD __________________________________________________________________ 15

6 Diagnostic Response ________________________________________________________________ 16

Diagnostic Response Sample API ___________________________________________________________ 16

Diagnostic Response Tag Details ___________________________________________________________ 16

Diagnostic Response XSD _________________________________________________________________ 16

7 Complaint and Transaction Status Request ______________________________________________ 17

CTSReq Sample API ______________________________________________________________________ 17

CTSReq Tag Details ______________________________________________________________________ 18

CTSReq XSD ____________________________________________________________________________ 18

8 Complaint and Transaction Status Response _____________________________________________ 20


CTSRes Sample API ______________________________________________________________________ 20

CTSRes Tag Details ______________________________________________________________________ 21

CTSRes XSD ____________________________________________________________________________ 22

9 Acknowledgment ___________________________________________________________________ 24

Acknowledgment Sample API _____________________________________________________________ 24

Acknowledgment Tag Details______________________________________________________________ 24

Acknowledgment XSD ___________________________________________________________________ 24

10 Biller MDM Fetch _________________________________________________________________ 25

Biller MDM Fetch Sample API ___________________________________________________________ 25

Biller MDM Fetch XSD __________________________________________________________________ 25

11 Biller MDM Response ______________________________________________________________ 26

Biller MDM Response Sample API ________________________________________________________ 26

Biller MDM Response XSD ______________________________________________________________ 37

12 BBPS Common ___________________________________________________________________ 40

BBPS Common XSD ____________________________________________________________________ 40

13 Key exchange / XML signing ________________________________________________________ 45

14 BBPS IDs ________________________________________________________________________ 46

ID Generation Stages __________________________________________________________________ 46

Generation Logic ______________________________________________________________________ 47

15 Payment Mode & Channel Details ___________________________________________________ 49

16 Elements description ______________________________________________________________ 50


1 Bill Fetch Request

Sample Bill Fetch Request API

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<bbps:BillFetchRequest xmlns:bbps= "http://bbps.org/schema">

<Head ver="1.0" ts="2015-02-16T22:02:35+05:30" origInst="OU01"

refId="HENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QM"/>

<Analytics>

<Tag name="FETCHREQUESTSTART" value="2015-02-16T22:02:00+05:30"/>

<Tag name="FETCHREQUESTEND" value="2015-02-16T22:02:35 +05:30"/>

</Analytics>

<Txn ts="2015-02-16T22:02:35+05:30’’ msgId="8ENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QX">

<RiskScores>

<Score provider="OU01" type="TXNRISK" value="030"/>

<Score provider="BBPS" type="TXNRISK" value="030"/>

</RiskScores>

</Txn>

<Customer mobile="9830098300">

<Tag name="EMAIL" value="[email protected]"/>

<Tag name="AADHAAR" value="123456789012"/>

<Tag name="PAN" value="BXXCG7754K"/>

</Customer>

<Agent id="OU01AI34000001123456">

<Device>

<Tag name="MOBILE" value="9830098300"/>

<Tag name="GEOCODE" value="12.9667,77.5667"/>

<Tag name="POSTAL_CODE" value="400063"/>

<Tag name="IP" value="124.170.23.22"/>

<Tag name="INITIATING_CHANNEL" value="INT/MOB/POS/MPOS/KIOSK/ATM/ BNKBRNCH"/>

<Tag name="TERMINAL_ID" value="1234556"/>

<Tag name="IMEI" value="123456789012345"/>

<Tag name="IFSC" value="ABCD0001234"/>

<Tag name="MAC" value="00-0D-60-07-2A-FO"/>

<Tag name="OS" value="iOS"/>

<Tag name="APP" value="AGENTAPP"/>

</Device>

</Agent>

<BillDetails>

<Biller id="VODA00000MUM03"/>

<CustomerParams>

<Tag name="RefFld1" value=""/>







</CustomerParams>

</BillDetails>

</bbps:BillFetchRequest>


Bill Fetch Request Tag Details

Index <XML Tag> Message Item Occurrence

1.1 <bbps:BillFetchRequest> API Name 1..1

1.1.1 xmlns API schema namespace 1..1

2.1 <Head> Header of the message 1..1

2.1.1 ver Version of the API 1..1

2.1.2 ts Creation date of the message 1..1

2.1.3 origInst Code assigned to the OU/CU which forwards the

transaction 1..1

2.1.4 refId

Unique identification assigned by the customer OU to

unambiguously identify the transaction. This

identification is passed on, unchanged, throughout

the entire end-to-end chain.

1..1

3.1 <Analytics> Meta data primarily for analytics 0..1

3.2 <Analytics.Tag> Meta data primarily for analytics 1..n

3.2.1 name Name of the tag which is defined 1..n

3.2.2 value Value of the tag 1..n

4.1 <Txn> Transaction information, passed throughout the

system, visible to all entities of the eco-system 1..1

4.1.1 ts Date and time of the transaction in GMT 1..1

4.1.2 msgId Unique identification for the transaction 1..1

4.2 <Txn.RiskScores> Risk Score related to the transaction and the

Entities – Parent tag 0..1

4.3 <Txn.RiskScores.Score> Risk Score related to the transaction and the

Entities – Child tag 1..n

4.3.1 provider Entity providing the risk score 1..n

4.3.2 type Type of risk 1..n

4.3.3 value Value of risk evaluation ranging from 0 (No Risk) to

100 (Maximum Risk) 1..n

5.1 <Customer> Details of the customer 1..1

5.1.1 mobile Customer mobile number 1..1

5.2 <Customer.Tag> Biller related data 0..n

5.2.1 name Name of the specific data requested from customer 1..n

5.2.2 value Value of the specific data 1..n

6.1 <Agent> Agent related data 1..1

6.1.1 id Unique identification code allocated to the agent 1..1

6.2 <Agent.Device> Details of Device from which the transaction was

initiated 1..1

6.3 <Agent.Device.Tag> Device Tag 1..n

6.3.1 name Name of the device which is used for transaction

initiation 1..n



6.3.2 value Unique code or value assigned to the device 1..n

7.1 <BillDetails> Customer bill related details 1..1

7.2 <BillDetails.Biller> Biller related details 1..1

7.2.1 id Biller ID is the unique number which identifies the

biller. 1..1

7.3 <BillDetails.CustomerParam

s> Customer bill related details 1..1

7.4 <BillDetails.CustomerParam

s.Tag> Customer bill related reference field tag 1..n

7.4.1 name Name of the reference field as configured 1..n

7.4.2 value Value of the reference field which is sent across 1..n

Bill Fetch Request XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillFetchRequest" type="bbps:BillFetchRequestType"> <xs:annotation> <xs:documentation>BBPS Bill Request</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BillFetchRequestType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:analyticsType" name="Analytics" minOccurs="0" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:customerDtlsType" name="Customer" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:agentType" name="Agent" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billDetailsType" name="BillDetails" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>


2 Bill Fetch Response

Bill Fetch Response Sample API


<bbps:BillFetchResponse xmlns:bbps= "http://bbps.org/schema">



<Reason approvalRefNum="AB123456" responseCode="000" responseReason="Succcesful"

complianceRespCd="022" complianceReason="Date and time incorrect"/>

<Txn ts="2015-02-16T22:02:35+05:30" msgId="8ENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QX "/>

<BillDetails>

<CustomerParams>








<CustomerParams>

</BillDetails>

<BillerResponse customerName="Arnab Moitra" amount="120000" dueDate="2015-09-24" custConvFee="1000"

custConvDesc="Customer service fee" billDate=”2015-01-22” billNumber=”1232332”

billPeriod=”January”>

<Tag name="Amount 1" value = "5000"/>




</BillerResponse>

<AdditionalInfo>

<Tag name="BlRspFld1" value=""/>






</AdditionalInfo>

</bbps:BillFetchResponse>

Bill Fetch Response Tag Details


1.1 <bbps:billFetchResponse> API Name 1..1






transaction 1..1



2.1.4 refId





1..1

8.1 <Reason> Response details of the transaction 1..1

8.1.1 approvalRefNum Code for the biller’s BBPOU to indicate acceptance

of the payment request message. 1..1

8.1.2 responseCode Carries the response code of the transaction 1..1

8.1.3 responseReason Response description to the response code 1..1

8.1.4 complianceRespCd Carries the response code for the compliance 0..1

8.1.5 complianceReason Response description to the compliance 0..1

9.1 <BillerResponse> Response which is sent by the biller 1..1

9.1.1 customerName Name of the customer 1..1

9.1.2 amount Amount of the bill 1..1

9.1.3 dueDate Due date of the bill 1..1

9.1.4 custConvFee Customer convenience fee which the customer has to

pay 0..1

9.1.5 custConvDesc Customer convenience fee description 0..1

9.1.6 billDate Bill date of the bill fetch requested 1..1

9.1.7 billNumber Bill number of the bill fetch requested 1..1

9.1.8 billPeriod Bill month of the bill fetch requested 1..1

9.2 <BillerResponse.Tag> Biller response related tag 0..n

9.2.1 name Name of the field assigned by the biller 1..n

9.2.2 value Value of the field 1..n

10.1 <AdditionalInfo> Additional information provided by the biller 0..1

10.2 <AdditionalInfo.Tag> Additional information sent by biller tag 1..n



Bill Fetch Response XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillFetchResponse" type="bbps:BillFetchResponseType"> <xs:annotation> <xs:documentation>BBPS Bill Fetch Response</xs:documentation> </xs:annotation> </xs:element>


<xs:complexType name="BillFetchResponseType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:reasonType" name="Reason" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billDetailsType" name="BillDetails" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billerResponseType" name="BillerResponse" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:additionalInfoType" name="AdditionalInfo" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>


3 Bill Payment Request

Bill Payment Request Sample API


<bbps:BillPaymentRequest xmlns:bbps= "http://bbps.org/schema">



<Analytics>

<Tag name="PAYREQUESTSTART" value="2015-02-16T22:02:00+05:30"/>

<Tag name="PAYREQUESTEND" value="2015-02-16T22:02:35+05:30"/>

</Analytics>

<Txn txnReferenceId="OU0156789123" ts="2015-02-16T22:02:35+05:30" type="FORWARD TYPE REQUEST |REVERSAL TYPE REQUEST" msgId="8ENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QY">

<RiskScores>

<Score provider="OU01" type="TXNRISK" value="030"/>

<Score provider="BBPS" type="TXNRISK" value="030"/>

</RiskScores>

</Txn>

<Customer mobile="9830098300">

<Tag name="EMAIL" value=" [email protected] "/>

<Tag name="AADHAAR" value="123456789012"/>

<Tag name="PAN" value="BXXCG7754K"/>

</Customer>

<Agent id="OU01AI34000001123456">

<Device>

<Tag name="MOBILE" value="9830098300"/>

<Tag name="GEOCODE" value="12.9667,77.5667"/>

<Tag name="POSTAL_CODE" value="400063"/>

<Tag name="IP" value="124.170.23.22"/>

<Tag name="INITIATING_CHANNEL" value="INT/MOB/POS/MPOS/KIOSK/ATM/ BNKBRNCH"/> <Tag name="TERMINAL_ID" value="1234556"/>

<Tag name="IMEI" value="123456789012345"/>

<Tag name="IFSC" value="ABCD0001234"/>

<Tag name="MAC" value="00-0D-60-07-2A-FO"/>

<Tag name="OS" value="iOS"/>

<Tag name="APP" value="AGENTAPP"/>

</Device>

</Agent>

<BillDetails>

<Biller id="VODA00000MUM03"/>

<CustomerParams>








</CustomerParams>

</BillDetails>


custConvDesc="Customer service fee" billDate=2015-01-22” billNumber=”1232332” billPeriod=”January”>






</BillerResponse>

<AdditionalInfo>







</AdditionalInfo>

<PaymentMethod quickPay="Yes|No" splitPay="Yes|No" paymentMode="Internet Banking|Debit Card|Credit

Card|IMPS| |Cash|UPI|Wallet|NEFT|Prepaid Card"/>

<Amount>

<Amt amount="120000" custConvFee="1000" currency="356"/>

<SplitPayAmount>10000</SplitPayAmount>





</Amount>

<PaymentInformation>

<Tag name="Remarks" value=”UNI000”/>

<Tag name="CardNum|AuthCode" value="4386280020697301|123456"/>

<Tag name="IFSC|AccountNo" value="SRAN0000341|0123456"/>

<Tag name="MMID|MobileNo" value="9240111|9004644121"/>

<Tag name="WalletName|MobileNo" value="WalletAAA|9004644121"/>

<Tag name="VPA" value="account@provider"/>

</PaymentInformation>

</bbps:BillPaymentRequest>

Payment Request Tag Details


1.1 <bbps:BillPaymentRequest> API Name 1..1






transaction 1..1

2.1.4 refId





1..1



4.1.1 ts Transmission date and time of the transaction 1..1

4.1.2 type Type of the message (bill fetch / payment request) 1..1



4.1.3 msgId Unique identification for the transaction 1..1

4.1.4 txnReferenceId Transaction reference number which is used by the

customer 1..1

11.1 <PaymentMethod> Payment method opted by the customer 1..1

11.1.1 quickPay Denote the payment initiated is quick pay in nature 1..1

11.1.2 splitPay Carries whether the bill payment is paid in two

different payment modes 1..1

11.1.3 paymentMode The payment mode which is accepted from the customer 1..1

12.1 <Amount> Details of the bill payment amount made by the

customer 1..1

12.2 <Amount.Amt> Details of the bill payment amount made by the

customer 1..1

12.2.1 amount Bill payment amount 1..1

12.2.2 custConvFee Customer convenience fee which the customer pays 0..1

12.2.3 currency Currency code of the transaction 1..1

12.3 <Amount.SplitPayAmount> Amount paid in other mode 0..1

12.4 <Amount.Tag> Amount paid by the customer related tag 0..n



13.1 <PaymentInformation> Payment information of the instrument which is used

for making the bill payment 1..1

13.2 <PaymentInformation.Tag> Payment instrument details which is used for the

bill payment transaction 1..n

13.2.1 name Name of the instrument used 1..n

13.2.2 value Details of the instrument used 1..n

Bill Payment Request XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillPaymentRequest" type="bbps:BillPaymentRequestType"> <xs:annotation> <xs:documentation>BBPS Bill Payment Request</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BillPaymentRequestType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:analyticsType" name="Analytics" minOccurs="0" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:customerDtlsType" name="Customer" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:agentType" name="Agent" minOccurs="1" maxOccurs="1" />


<xs:element type="bbps:billDetailsType" name="BillDetails" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billerResponseType" name="BillerResponse" minOccurs="0" maxOccurs="1" /> <xs:element type="bbps:additionalInfoType" name="AdditionalInfo" minOccurs="0" maxOccurs="1" /> <xs:element type="bbps:pmtMtdType" name="PaymentMethod" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:amountType" name="Amount" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:pymntInfType" name="PaymentInformation" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>

4 Bill Payment Response

Bill Payment Response Sample API


<bbps:BillPaymentResponse xmlns:bbps= "http://bbps.org/schema">



<Reason approvalRefNum="CD123456" responseCode="000" responseReason="Succcesful"

complianceRespCd="022" complianceReason="Date and time incorrect"/>

<Txn txnReferenceId="OU0156789123" ts="2015-02-16T22:02:35+05:30" type="FORWARD TYPE

RESPONSE|REVERSAL TYPE RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QY"/>

<BillDetails>

<CustomerParams>








<CustomerParams>

</BillDetails>


custConvDesc="Customer service fee" billDate=”2015-01-23” billNumber=”1232332”

billPeriod=”January”/>

</bbps:BillPaymentResponse>

Bill Payment Response Tag Details


1.1 <bbps:BillPaymentRespons

e> API Name 1..1







2.1.3 origInst Code assigned to the OU/CU which forwards the transaction

1..1

2.1.4 refId

Unique identification assigned by the customer OU to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.

1..1

Bill Payment Response XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillPaymentResponse" type="bbps:BillPaymentResponseType"> <xs:annotation> <xs:documentation>BBPS Bill Fetch Response</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BillPaymentResponseType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:reasonType" name="Reason" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billDetailsType" name="BillDetails" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:billerResponseType" name="BillerResponse" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>


5 Diagnostic Request

Diagnostic Request Sample API


<bbps:ReqDiagnostic xmlns:bbps="http://bbps.org/schema">

<Head ver="1.0" ts="2016-05-30T18:45:56+05:30" origInst="OU01" refId="LNMSQQR4RKT7X1UGPY7JGUV454PL9T2C689"

/>

</bbps:ReqDiagnostic>

Diagnostic Request Tag Details


1.1 <bbps:ReqDiagnostic> API Name 1..1





2.1.3 origInst Code assigned to the OU/CU which forwards the transaction

1..1

2.1.4 refId Unique identification for the transaction 1..1

Diagnostic Request XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="ReqDiagnostic" type="bbps:ReqDiagnosticType"> <xs:annotation> <xs:documentation>BBPS Diagnostic Request</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="ReqDiagnosticType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>


6 Diagnostic Response

Diagnostic Response Sample API


<bbps:ResDiagnostic xmlns:bbps= "http://bbps.org/schema" responseReason ="Successful|Failed">

<Head ver="1.0" ts="2015-02-16T22:02:35+05:30" origInst="BBCU"

refId="LNMSQQR4RKT7X1UGPY7JGUV454PL9T2C689"/>

<errorMessages>

<errorCd>T013</errorCd>

<errorDtl>Txn TimeStamp must be ISO_ZONE format</errorDtl>

</errorMessages>

</bbps:ResDiagnostic>

Diagnostic Response Tag Details


1.1 <bbps:ResDiagnostic > API Name 1..1





2.1.3 origInst Code assigned to the OU/CU which receives the transaction

1..1

2.1.4 refId Unique identification for the transaction 1..1

14.1 <errorMessages> Error messages in the API message 0..1

14.2 <errorMessages.errorCd> Error Code for API message 1..n

14.3 <errorMessages.errorDtl> Error Reason for the API message 1..n

Diagnostic Response XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="ResDiagnostic" type="bbps:ResDiagnosticType"> <xs:annotation> <xs:documentation>BBPS Diagnostic Response</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="ResDiagnosticType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element name="errorMessages" type="bbps:errorMessage" minOccurs="0" maxOccurs="unbounded"> </xs:element> </xs:sequence>

http://bbps.org/schema


<xs:attribute name="responseReason" type="xs:string" /> </xs:complexType> </xs:schema>

7 Complaint and Transaction Status Request

CTSReq Sample API


<bbps:TxnStatusComplainRequest xmlns:bbps= "http://bbps.org/schema">



<Txn ts="2015-02-16T22:02:35+05:30" xchangeId="501"/>

<TxnStatusComplainReq

msgId="HENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QX"

complaintId="AP1234098871211"

servReason="Agent not willing to print receipt"

participationType="AGENT|BILLER|SYSTEM"

agentId="TR34AI34000001123456"

billerId="VODA00000MUM03"

mobile="9839871171"

txnReferenceId="TR3456789123"

category="Electricity"

disposition="Transaction Successful, account not updated"

description="Complaint initiated through API"

complaintType="Transaction|Service"/>

</bbps:TxnStatusComplainRequest>


CTSReq Tag Details

CTSReq XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema"


1.1 <bbps:TxnStatusComplainR

equest> API Name 1..1






transaction 1..1

2.1.4 refId

Unique identification assigned by the customer OU to unambiguously identify the transaction. This

identification is passed on, unchanged, throughout the entire end-to-end chain.

1..1




4.1.2 xchangeId Identification of the type of the request

(transaction status (401), complaint status (506), complaint registration (501))

1..1

15.1 <TxnStatusComplainReq> Information pertaining to transaction status and

complaint request and complaint status 1..1

15.1.1 msgId

Unique identification assigned by the central unit to unambiguously identify the transaction. This


1..1

15.1.2 complaintId Complaint ID generated by BBPCU to check the status

of a complaint 0..1

15.1.3 servReason Reason for the service based complaints 0..1

15.1.4 participationType Entity type for the service based complaints 0..1

15.1.5 agentId Unique identification code allocated to the agent for

the service based complaints 0..1


15.1.6 billerId Unique identification code allocated to the biller for

the service based complaints 0..1

15.1.7 mobile Mobile number against which a transaction is to be searched for raising transaction based complaints

0..1

15.1.8 txnReferenceId Transaction reference number printed on the slip of the

customer. This field is entered by the customer who raises a transaction based complaint

0..1

15.1.9 category Category of complaint for transaction based complaints 0..1

15.1.10

disposition Disposition of complaint for transaction based complaints 0..1

15.1.11

description Description of the complaint 0..1

15.1.12

complaintType Type of complaint – Transaction or Service based

complaint 0..1


elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="TxnStatusComplainRequest" type="bbps:TxnStatusComplainRequest"> <xs:annotation> <xs:documentation>BBPS API request</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="TxnStatusComplainRequest"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:TxnStatusComplainReq" name="TxnStatusComplainReq" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="TxnStatusComplainReq"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute type="xs:string" name="msgId" use="required"/> <xs:attribute type="xs:string" name="complaintId" use="optional"/> <xs:attribute type="xs:string" name="servReason" use="optional"/> <xs:attribute type="xs:string" name="participationType" use="optional"/> <xs:attribute type="xs:string" name="agentId" use="optional"/> <xs:attribute type="xs:string" name="billerId" use="optional"/> <xs:attribute type="xs:string" name="mobile" use="optional"/> <xs:attribute type="xs:string" name="txnReferenceId" use="optional"/> <xs:attribute type="xs:string" name="category" use="optional"/> <xs:attribute type="xs:string" name="disposition" use="optional"/> <xs:attribute type="xs:string" name="description" use="optional"/> <xs:attribute type="xs:string" name="complaintType" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType>

</xs:schema>


8 Complaint and Transaction Status Response

CTSRes Sample API


<bbps:TxnStatusComplainResponse xmlns:bbps= "http://bbps.org/schema">



<Txn ts="2015-02-16T22:02:35+05:30" xchangeId="401"/>

<TxnStatusComplainResp

msgId="HENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QX"

complaintId="AP1234098871211"

openComplaint="Y|N"

complaintStatus="ASSIGNED"

assigned="MH02"

responseCode="000"

responseReason="SUCCESS">

<TxnList>

<TxnDetail txnReferenceId="TR3456789123" amount="800" txnDate="2015-02-

19T12:02:45+00:00" agentId="TR34AI34000001123456" billerId="VODA00000MUM03"

txnStatus="SUCCESS|REVERSAL" />

<TxnDetail txnReferenceId ="TR3456789124" amount="915" txnDate="2015-02-

16T22:02:35+00:00" agentId="TR34AI34000001123456" billerId="VODA00000MUM03"

txnStatus="SUCCESS|REVERSAL" />

</TxnList>

<CustomerDetails name="AK Sharma" email="[email protected]" mobile="9830976554"/>

</ TxnStatusComplainResp >

</bbps: TxnStatusComplainResponse>


CTSRes Tag Details


1.1 <bbps:TxnStatusComplainR

esponse> API Name 1..1






transaction 1..1

2.1.4 refId

Unique identification assigned by the customer OU to unambiguously identify the transaction. This


1..1




3.1.2 xchangeId Identification of the type of the request

(transaction status (401), complaint status (506), complaint registration (501))

1..1

16.1 <TxnStatusComplainRes> Information pertaining to transaction status and

complaint response and complaint status 1..1

16.1.1 msgId

Unique identification assigned by the central unit to unambiguously identify the transaction. This


1..1

16.1.2 complaintId Complaint ID generated by BBPCU to check the status

of a complaint 0..1

16.1.3 openComplaint Indicates if the complaint is open or closed 0..1

16.1.4 complaintStatus Complaint status of the transaction 0..1

16.1.5 assigned OU to which the complaint is assigned 0..1



16.1.6 responseCode Carries the response code of the transaction 1..1

16.1.7 responseReason Response description to the response code 1..1

16.2 <TxnStatusComplainResp.Tx

nList>

List of transactions containing the details of transactions linked to a mobile number

0..1

16.3 <TxnStatusComplainResp.T

xnList.TxnDetail> Record containing the details of a single transaction 1..n

16.3.1 txnReferenceId Transaction reference number which is used by the customer

1..n

16.3.2 amount Bill payment amount 1..n

16.3.3 txnDate Transaction date on which the payment was made 1..n

16.3.4 agentId Identification code of the agent associated with the particular transaction

1..n

16.3.5 billerId Identification code of the biller associated with the particular transaction

1..n

16.3.6 txnStatus Status of the transaction 1..n

16.4 <TxnStatusComplainResp.C

ustomerDetails> Details of the customer 0..1

16.4.1 name Name of the customer 0..1

16.4.2 email Email ID of the customer 0..1

16.4.3 mobile Customer mobile number 1..1

CTSRes XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="TxnStatusComplainResponse" type="bbps:TxnStatusComplainResponse"> <xs:annotation> <xs:documentation>BBPS API response</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="TxnStatusComplainResponse"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:txnType" name="Txn" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:TxnStatusComplainResp" name="TxnStatusComplainResp" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="TxnStatusComplainResp"> <xs:sequence> <xs:element name="TxnList" minOccurs="1" maxOccurs="1" type="bbps:TxnList" /> <xs:element name="CustomerDetails" minOccurs="0" maxOccurs="1" type="bbps:CustomerDetails" /> </xs:sequence> <xs:attribute type="xs:string" name="msgId" use="required"/> <xs:attribute type="xs:string" name="complaintId" use="optional"/> <xs:attribute type="xs:string" name="openComplaint" use="optional"/> <xs:attribute type="xs:string" name="complaintStatus" use="optional"/> <xs:attribute type="xs:string" name="assigned" use="optional"/> <xs:attribute type="xs:string" name="responseCode" use="optional"/> <xs:attribute type="xs:string" name="responseReason" use="optional"/> </xs:complexType>


<xs:complexType name="TxnList"> <xs:sequence> <xs:element name="TxnDetail" type="bbps:TxnDetail" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="TxnDetail"> <xs:attribute type="xs:string" name="txnReferenceId" use="required"/> <xs:attribute type="xs:string" name="amount" use="required"/> <xs:attribute type="xs:string" name="txnDate" use="required"/> <xs:attribute type="xs:string" name="agentId" use="required"/> <xs:attribute type="xs:string" name="billerId" use="required"/> <xs:attribute type="xs:string" name="txnStatus" use="required"/> </xs:complexType> <xs:complexType name="CustomerDetails"> <xs:attribute type="xs:string" name="name" use="required"/> <xs:attribute type="xs:string" name="email" use="required"/> <xs:attribute type="xs:string" name="mobile" use="required"/> </xs:complexType> </xs:schema>


9 Acknowledgment

Acknowledgment Sample API


<bbps:Ack xmlns:bbps= "http://bbps.org/schema" api="PAYMENT_REQUEST"

refId="LNMSQQR4RKT7X1UGPY7JGUV454PL9T2C689" msgId="MPPSQRS4ROT7X1MGPY7JGUV444PLTU2C689" rspCd

="Successful" ts="2016-05-16T15:25:50+05:30">

<errorMessages>

<errorCd>T013</errorCd>

<errorDtl>Txn TimeStamp must be ISO_ZONE format</errorDtl>

</errorMessages>

</bbps:Ack>

Acknowledgment Tag Details


1.1 <bbps:Ack> API Name 1..1


1.1.2 api Name of the API for which acknowledgement is given out

1..1

1.1.3 rspCd Denotes any error in receiving the original request message

1..1

Acknowledgment XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="Ack"> <xs:complexType> <xs:sequence> <xs:element name="errorMessages" type="bbps:errorMessage" minOccurs="0" maxOccurs="unbounded"> </xs:element> </xs:sequence> <xs:attribute name="api" type="xs:string" /> <xs:attribute name="refId" type="xs:string" /> <xs:attribute name="msgId" type="xs:string" /> <xs:attribute name="rspCd" type="xs:string" /> <xs:attribute name="ts" type="xs:string" /> </xs:complexType> </xs:element> </xs:schema>

http://bbps.org/schema


10 Biller MDM Fetch

Biller MDM Fetch Sample API


<bbps:BillerFetchRequest xmlns:ns2="http://bbps.org/schema">

<Head ver="1.0" ts="2016-06-29T18:14:36+05:30" origInst="MH01"

refId="lSmwR555fOBEbeAfgUoK95PFFPVY6Ny6pWc"/>

</bbps:BillerFetchRequest>

Biller MDM Fetch XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillerFetchRequest" type="bbps:BillerFetchRequestType"> <xs:annotation> <xs:documentation>BBPS Biller Fetch Request</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BillerFetchRequestType"> <xs:sequence> <xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> </xs:schema>


11 Biller MDM Response

Biller MDM Response Sample API


<bbps:BillerFetchResponse xmlns:bbps="http://bbps.org/schema">

<Head ts="2016-07-01T20:31:49+05:30" origInst="BBCU" refId="N2WJjfRBHw7FCXOWkHYJtHQB67Gq4Gw3cqZ"/>

<biller>

<billerId>VODAACBI010079</billerId>

<billerName>ACBI</billerName>

<billerCategoryName>Telephone</billerCategoryName>

<billerMode>ONLINE</billerMode>

<billerAcceptsAdhoc>true</billerAcceptsAdhoc>

<parentBiller>false</parentBiller>

<parentBillerId>VODA10000KOL73</parentBillerId>

<billerOwnerShp>Private</billerOwnerShp>

<billerCoverage>National</billerCoverage>

<billerEffctvFrom>2016-01-01</billerEffctvFrom>

<billerEffctvTo>2020-01-01</billerEffctvTo>

<billerPaymentModes>

<paymentMode>Internet Banking</paymentMode>

</billerPaymentModes>


<paymentMode>Debit Card</paymentMode>



<paymentMode>Credit Card</paymentMode>



<paymentMode>Prepaid Card</paymentMode>



<paymentMode>IMPS</paymentMode>



<paymentMode>Cash</paymentMode>



<paymentMode>UPI</paymentMode>



<paymentMode>Wallet</paymentMode>



<paymentMode>NEFT</paymentMode>


<billerPaymentChannels>

<paymentChannel>INT</paymentChannel>

<maxLimit>0</maxLimit>

</billerPaymentChannels>


<paymentChannel>MOB</paymentChannel>





<paymentChannel>POS</paymentChannel>




<paymentChannel>MPOS</paymentChannel>




<paymentChannel>ATM</paymentChannel>




<paymentChannel>BNKBRNCH</paymentChannel>




<paymentChannel>KIOSK</paymentChannel>



<billerCustomerParams>

<paramName>Customer Reference Number</paramName>

<dataType>ALPHANUMERIC</dataType>

<optional>true</optional>

</billerCustomerParams>


<paramName>Customer Mobile Number</paramName>

<dataType>NUMERIC</dataType>



<billerResponseParams>

<amountOptions>

<amountBreakupSet>Additional Charges</amountBreakupSet>

</amountOptions>

</billerResponseParams>

<billerAdditionalInfo>

<paramName>Service Provider Name</paramName>


<optional>false</optional>

</billerAdditionalInfo>


<paramName>Location/Circle</paramName>




<interchangeFeeConf>

<mti>DISPUTE</mti>



<responseCode>000</responseCode>

<fees>BPF1</fees>

<fees>CCF1</fees>

<fees>BPF2</fees>

<fees>CCF2</fees>

<defaultFee>false</defaultFee>

</interchangeFeeConf>



<mti>GOOD_FAITH</mti>




<fees>BPF1</fees>

<fees>CCF1</fees>

<fees>BPF2</fees>

<fees>CCF2</fees>




<mti>PAYMENT</mti>




<fees>BPF1</fees>

<fees>CCF1</fees>

<fees>BPF2</fees>

<fees>CCF2</fees>



<interchangeFee>

<feeCode>CCF2</feeCode>

<feeDesc>Customer Convenience Fee 2</feeDesc>

<feeDirection>B2C</feeDirection>

<interchangeFeeDetails>

<tranAmtRangeMax>1000000</tranAmtRangeMax>

<tranAmtRangeMin>100</tranAmtRangeMin>

<percentFee>5.69</percentFee>

<flatFee>20</flatFee>

<effctvFrom>2016-06-03</effctvFrom>

<effctvTo>2016-06-03</effctvTo>

</interchangeFeeDetails>

</interchangeFee>

<interchangeFee>


<feeDesc>Customer Convenience Fee 1</feeDesc>










</interchangeFee>

<interchangeFee>

<feeCode>BPF2</feeCode>

<feeDesc>Bill payment 2</feeDesc>











</interchangeFee>

<interchangeFee>


<feeDesc>Bill payment 1</feeDesc>










</interchangeFee>

</biller>

<biller>

<billerId>VODAAIRTE26999</billerId>

<billerName>AIRTEL Kolkata</billerName>

<billerCategoryName>Bill Payment</billerCategoryName>




<parentBillerId>VODA10000KOL73</parentBillerId>














































<paramName>Account</paramName>




<billerResponseParams>

<amountOptions>

<amountBreakupSet>BillerResponse1</amountBreakupSet>

<amountBreakupSet>BASE_BILL_AMOUNT</amountBreakupSet>

<amountBreakupSet>Biller Response Params1</amountBreakupSet>

</amountOptions>

<amountOptions>

<amountBreakupSet>BillerResponse1</amountBreakupSet>

<amountBreakupSet>Biller Response</amountBreakupSet>

<amountBreakupSet>BASE_BILL_AMOUNT</amountBreakupSet>


</amountOptions>

<amountOptions>

<amountBreakupSet>Biller Response</amountBreakupSet>


</amountOptions>

</billerResponseParams>


<paramName>Energy Charges</paramName>





<mti>DEBIT ADJUSTMENT</mti>



<fees>pp11kol23</fees>

<defaultFee>true</defaultFee>




<interchangeFee>

<feeCode>XY22V2612w</feeCode>

<feeDesc>XY22V26999_dESC_update</feeDesc>



























</interchangeFee>

</biller>

<biller>

<billerId>VODA00000KOL77</billerId>

<billerName>VODA00000KOL77</billerName>

<billerCategoryName>Mobile</billerCategoryName>












<paymentMode>Wallet</paymentMode>












<paymentMode>Prepaid Card</paymentMode>






































<paramName>Account</paramName>




<billerResponseParams/>


<mti>PAYMENT</mti>




<fees>BPF1</fees>




<mti>PAYMENT</mti>




<fees>TSC1</fees>




<mti>PAYMENT</mti>



<fees>CCF1</fees>

<fees>BPF1</fees>

<defaultFee>true</defaultFee>



<mti>PAYMENT</mti>




<fees>TSB1</fees>




<mti>PAYMENT</mti>




<fees>CCF1</fees>



<interchangeFee>


<feeDesc>Customer Convenience Fee1 for CCF3</feeDesc>

<feeDirection>C2B</feeDirection>







</interchangeFee>

<interchangeFee>










</interchangeFee>

<interchangeFee>










</interchangeFee>

<interchangeFee>


<feeDesc>Biller Payment Fee1 for BPF3</feeDesc>









</interchangeFee>

<interchangeFee>










</interchangeFee>

<interchangeFee>










</interchangeFee>

<interchangeFee>

<feeCode>TSB3</feeCode>

<feeDesc>Biller Tkt Size Fee2 for TSB3</feeDesc>




















</interchangeFee>

<interchangeFee>

<feeCode>TSC3</feeCode>

<feeDesc>Customer Tkt Size Fee1 for TSC3</feeDesc>





















</interchangeFee>

<interchangeFee>






















</interchangeFee>

<interchangeFee>























</interchangeFee>

<interchangeFee>






















</interchangeFee>

<interchangeFee>






















</interchangeFee>


</biller>

</bbps:BillerFetchResponse>

Biller MDM Response XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="BBPS-Common.xsd" /> <xs:element name="BillerFetchResponse" type="bbps:BillerFetchResponseType"> <xs:annotation> <xs:documentation>BBPS Biller Fetch Response</xs:documentation> </xs:annotation> </xs:element> <xs:complexType name="BillerFetchResponseType"> <xs:sequence> <xs:element type="bbps:headType" name="head" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:Biller" name="biller" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Biller"> <xs:sequence> <xs:element type="xs:string" name="billerId" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:string" name="billerName" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:string" name="billerCategoryName" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:string" name="billerMode" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:boolean" name="billerAcceptsAdhoc" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:boolean" name="parentBiller" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:string" name="parentBillerId" minOccurs="1" maxOccurs="1" /> <xs:element name="billerOwnerShp" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="billerCoverage" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="billerEffctvFrom" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="billerEffctvTo" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element type="bbps:PaymentModeLimit" name="billerPaymentModes" minOccurs="1" maxOccurs="unbounded" /> <xs:element type="bbps:PaymentChannelLimit" name="billerPaymentChannels" minOccurs="1" maxOccurs="unbounded"></xs:element> <xs:element type="bbps:ParamConfig" name="billerCustomerParams" minOccurs="1" maxOccurs="unbounded"></xs:element> <xs:element type="bbps:BillerResponseParams" name="billerResponseParams" minOccurs="1" maxOccurs="1"></xs:element> <xs:element type="bbps:ParamConfig" name="billerAdditionalInfo" minOccurs="1" maxOccurs="unbounded"></xs:element> <xs:element type="bbps:InterchangeFeeConf" name="interchangeFeeConf" minOccurs="1" maxOccurs="unbounded"></xs:element> <xs:element type="bbps:InterchangeFee" name="interchangeFee" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="PaymentModeLimit"> <xs:sequence> <xs:element type="xs:string" name="paymentMode" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:long" name="maxLimit" minOccurs="0" maxOccurs="1" /> </xs:sequence>


</xs:complexType> <xs:complexType name="PaymentChannelLimit"> <xs:sequence> <xs:element type="xs:string" name="paymentChannel" minOccurs="1" maxOccurs="1" /> <xs:element type="xs:long" name="maxLimit" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="ParamConfig"> <xs:sequence> <xs:element type="xs:string" name="paramName" /> <xs:element type="bbps:DataType" name="dataType" /> <xs:element type="xs:boolean" name="optional" /> </xs:sequence> </xs:complexType> <xs:simpleType name="DataType"> <xs:restriction base="xs:string"> <xs:enumeration value="NUMERIC" /> <xs:enumeration value="ALPHANUMERIC" /> </xs:restriction> </xs:simpleType> <xs:complexType name="BillerResponseParams"> <xs:sequence> <xs:element type="bbps:ParamConfig" name="params" minOccurs="1" maxOccurs="unbounded" /> <xs:element type="bbps:AmountOption" name="amountOptions" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="AmountOption"> <xs:sequence> <xs:element type="xs:string" name="amountBreakupSet" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="InterchangeFeeConf"> <xs:sequence> <xs:element name="mti" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="paymentMode" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="paymentChannel" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="responseCode" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="fees" type="xs:string" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="defaultFee" type="xs:boolean" /> <xs:element name="effctvFrom" type="xs:string" minOccurs="0" /> <xs:element name="effctvTo" type="xs:string" minOccurs="0" /> </xs:sequence> </xs:complexType> <xs:complexType name="InterchangeFee"> <xs:sequence> <xs:element name="feeCode" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="feeDesc" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="feeDirection" type="bbps:InterchangeFeeDirection" minOccurs="1" maxOccurs="1"/> <xs:element name="interchangeFeeDetails" type="bbps:InterchangeFeeDetailsType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>


<xs:complexType name="InterchangeFeeDetailsType"> <xs:sequence> <xs:element name="tranAmtRangeMax" type="xs:long" /> <xs:element name="tranAmtRangeMin" type="xs:long" /> <xs:element name="percentFee" type="xs:decimal" minOccurs="1" maxOccurs="1"/> <xs:element name="flatFee" type="xs:decimal" minOccurs="1" maxOccurs="1"/> <xs:element name="effctvFrom" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="effctvTo" type="xs:string" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:simpleType name="InterchangeFeeDirection"> <xs:restriction base="xs:string"> <xs:enumeration value="B2C" /> <xs:enumeration value="C2B" /> </xs:restriction> </xs:simpleType> </xs:schema>


12 BBPS Common

BBPS Common XSD

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:bbps="http://bbps.org/schema" targetNamespace="http://bbps.org/schema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <xs:simpleType name="custIdentityConstant"> <xs:restriction base="xs:string"> <xs:enumeration value="EMAIL" /> <xs:enumeration value="PAN" /> <xs:enumeration value="AADHAAR" /> </xs:restriction> </xs:simpleType>  <xs:simpleType name="transactionType"> <xs:restriction base="xs:string"> <xs:enumeration value="FORWARD TYPE REQUEST" /> <xs:enumeration value="REVERSAL TYPE REQUEST" /> <xs:enumeration value="FORWARD TYPE RESPONSE" /> <xs:enumeration value="REVERSAL TYPE RESPONSE" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="deviceTagNameType"> <xs:restriction base="xs:string"> <xs:enumeration value="MOBILE" /> <xs:enumeration value="GEOCODE" /> <xs:enumeration value="POSTAL_CODE" /> <xs:enumeration value="IP" /> <xs:enumeration value="INITIATING_CHANNEL" /> <xs:enumeration value="TERMINAL_ID" /> <xs:enumeration value="IMEI" /> <xs:enumeration value="IFSC" /> <xs:enumeration value="MAC" /> <xs:enumeration value="OS" /> <xs:enumeration value="APP" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="initiatingChannelType"> <xs:restriction base="xs:string"> <xs:enumeration value="INT" /> <xs:enumeration value="MOB" /> <xs:enumeration value="POS" /> <xs:enumeration value="KIOSK" /> <xs:enumeration value="MPOS" /> <xs:enumeration value="ATM" /> <xs:enumeration value="BNKBRNCH" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="qckPayType"> <xs:restriction base="xs:string"> <xs:enumeration value="Yes" /> <xs:enumeration value="No" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="spltPayType"> <xs:restriction base="xs:string">


<xs:enumeration value="Yes" /> <xs:enumeration value="No" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="analyticsFetchTypeInstance"> <xs:restriction base="xs:string"> <xs:enumeration value="FETCHREQUESTSTART" /> <xs:enumeration value="FETCHREQUESTEND" /> </xs:restriction> </xs:simpleType> <xs:simpleType name="analyticsPaymentTypeInstance"> <xs:restriction base="xs:string"> <xs:enumeration value="PAYREQUESTSTART" /> <xs:enumeration value="PAYREQUESTEND" /> </xs:restriction> </xs:simpleType> <xs:complexType name="headType"> <xs:attribute type="xs:string" name="ver" use="required" /> <xs:attribute type="xs:string" name="ts" use="required" /> <xs:attribute type="xs:string" name="origInst" use="required" /> <xs:attribute type="xs:string" name="refId" use="required" /> </xs:complexType> <xs:complexType name="analyticsType"> <xs:sequence> <xs:element name="Tag" maxOccurs="2" minOccurs="2"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="riskScoresType"> <xs:sequence> <xs:element name="Score" maxOccurs="unbounded" minOccurs="0"> <xs:complexType> <xs:attribute type="xs:string" name="provider" use="required" /> <xs:attribute type="xs:string" name="type" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="txnType"> <xs:sequence> <xs:element type="bbps:riskScoresType" name="RiskScores" minOccurs="0" maxOccurs="1" /> </xs:sequence> <xs:attribute type="xs:string" name="ts" use="required"/>  <xs:attribute type="xs:string" name="type" use="optional"/>  <xs:attribute type="xs:string" name="msgId" use="optional"/>  <xs:attribute type="xs:string" name="txnReferenceId" use="optional"/>  <xs:attribute type="xs:string" name="xchangeId" use="optional"/> </xs:complexType>


<xs:complexType name="customerDtlsType"> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="0"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute type="xs:string" name="mobile" use="required" /> </xs:complexType> <xs:complexType name="deviceType"> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="1"> <xs:complexType> <xs:attribute type="bbps:deviceTagNameType" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="agentType"> <xs:sequence> <xs:element type="bbps:deviceType" name="Device" /> </xs:sequence> <xs:attribute type="xs:string" name="id" use="required" /> </xs:complexType> <xs:complexType name="billerType"> <xs:attribute type="xs:string" name="id" use="required" /> </xs:complexType> <xs:complexType name="customerParamsType"> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="1"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="billDetailsType"> <xs:sequence> <xs:element type="bbps:billerType" name="Biller" minOccurs="1" maxOccurs="1" /> <xs:element type="bbps:customerParamsType" name="CustomerParams" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="billerResponseType"> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="0"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence>


<xs:attribute type="xs:string" name="customerName" use="required" /> <xs:attribute type="xs:string" name="amount" use="required" /> <xs:attribute type="xs:string" name="dueDate" use="required" /> <xs:attribute type="xs:string" name="custConvFee" use="optional" /> <xs:attribute type="xs:string" name="custConvDesc" use="optional" /> <xs:attribute type="xs:string" name="billDate" use="required" /> <xs:attribute type="xs:string" name="billNumber" use="required" /> <xs:attribute type="xs:string" name="billPeriod" use="required" /> </xs:complexType> <xs:complexType name="reasonType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute type="xs:string" name="approvalRefNum" use="required" /> <xs:attribute type="xs:string" name="responseCode" use="required" /> <xs:attribute type="xs:string" name="responseReason" use="required" /> <xs:attribute type="xs:string" name="complianceRespCd" use="optional" /> <xs:attribute type="xs:string" name="complianceReason" use="optional" /> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="additionalInfoType"> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="0"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>  <xs:complexType name="pmtMtdType"> <xs:attribute type="bbps:qckPayType" name="quickPay" /> <xs:attribute type="bbps:spltPayType" name="splitPay" /> <xs:attribute type="xs:string" name="paymentMode" /> </xs:complexType> <xs:complexType name="amtType"> <xs:attribute type="xs:string" name="amount" /> <xs:attribute type="xs:string" name="custConvFee" /> <xs:attribute type="xs:string" name="currency" /> </xs:complexType> <xs:complexType name="amountType"> <xs:sequence> <xs:element type="bbps:amtType" name="Amt" /> <xs:element type="xs:string" name="SplitPayAmount" /> <xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="0"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:sequence> </xs:complexType> <xs:complexType name="pymntInfType">


<xs:sequence> <xs:element name="Tag" maxOccurs="unbounded" minOccurs="1"> <xs:complexType> <xs:attribute type="xs:string" name="name" use="required" /> <xs:attribute type="xs:string" name="value" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="errorMessage"> <xs:sequence> <xs:element type="xs:string" name="errorCd" /> <xs:element type="xs:string" name="errorDtl" /> </xs:sequence> </xs:complexType>  </xs:schema>


13 Key exchange / XML signing

All messages exchanged in the BBPS eco-system should use XML signing for all message exchange except

acknowledgement.

A sample has been mentioned below:-

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod

Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha2"/><Reference URI=""><Transforms><Transform

Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>grHLUDgU28tCprzTU6ElNQV/WXAWgucnqoIP9ufq

MLo=</DigestValue></Reference></SignedInfo><SignatureValue>oslM90F8uBiuEvBnvXl0g/qnGCIicoZiUKvA6n13SS/ANhB

KDP2Exg==</SignatureValue><KeyInfo><KeyValue><DSAKeyValue><P>tBNonyuaxVmpLTHemluxLFdAoOhVxvOWfJrOKnsLhvOFt

eUSUPdgjoxhNITbPRSN/f+myCNffrHh1T6e2+mmx9rem2OAQxCeP0xm2SEl/g3T0FuC2r2H8UXhDoec6Uv+ObZG5v/b5NZ2wMi/cELQZvV

ZNh+q8AZ4LK5GVEuR+bk=</P><Q>vLWLi0BIeZTmt7HREDnfSKFfgeM=</Q><G>oulc1jsfIxveigDtogOeXrbdPf3ODECmgJDxU8FCoTH

BlsDEt6JvvxoK/eGRcsundFeK8N4XqT8u0ttEu1z7WaxM0pM7E7XJELO3NGX21N6EmKNJzsPKUW8w81MTB94pcSBwkSibvPUreiXZCv2uo

/OwFejNh25/c9aMIIEjkQ==</G><Y>QrceC5IbEVgAPEtFbDPmPafY5ZhpOoqgTzLxtKycer/kjO4b4c4Z7prJ+16GwsXJMZ9u3+yIgI9L

cGp9dZ9uVwBF+1Q4MGC9PW4bIJqOsf3ncjuN/un7+9I7BWbkJaSVNlK9KHeiLtU7uEwfIwrtq7mwWtDtnViV3+1dG8FdAt0=</Y></DSAK

eyValue></KeyValue></KeyInfo></Signature>

http://www.w3.org/2000/09/xmldsig

http://www.w3.org/TR/2001/REC-xml-c14n-20010315

http://www.w3.org/2000/09/xmldsig#enveloped-signature

http://www.w3.org/2001/04/xmlenc#sha256


14 BBPS IDs

ID Generation Stages

Online & Offline (A) Online & Offline (A) Offline (B)

Identification

Generation Bill Fetch Request

Bill Fetch Response

Payment Request

Payment Response

Payment Request

Payment Response

msgID Generated by Customer OU

Populated by Customer OU

Carried from Bill Fetch Request


Carried from Bill Payment Request



refId Generated by Customer OU







txnRefId Generated by Customer OU

NA NA Populated by Customer OU




OUID Generated by BBPCU


Populated by Biller OU





AIID Generated by BBPCU


NA Carried from Bill Fetch Request

NA Populated by Customer OU

NA

AgentID Generated by Customer OU




NA

BillerID Generated by BBPCU -




NA

CustID (Only Customer registration)

Generated by BBPCU

NA NA NA NA NA NA

System User ID (OU/CU)

Generated by BBPCU

NA NA NA NA NA NA


Generation Logic

IDs Messages Length Type Logic Example Applicable to

Operating Units

msgId

Unique identification for the transaction.

35 Alphanumeric

Code generated by the OU that acquires the customer for every transaction initiated. UUID logic defined by ISO to be used for generation of the reference number and is used for matching with every request and response message.

8ENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QX

Y

refId

Unique identification assigned by the customer OU to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain.

35 Alphanumeric

Code generated by the OU that acquires the customer for every bill fetch transaction initiated and used across all messages. UUID logic defined by ISO to be used for generation of the reference number.

HENSVVR4QOS7X1UGPY7JGUV444PL9T2C3QM

Y

txnReferenceId

This data element will contain a unique ID for all BBPS payment transactions.

12 Alphanumeric OU 1 code (customer acquiring) – 04 ; Random alphanumeric character – 08

OU0156789123 Y

OU ID

It is a unique code allocated by BBPCU for identifying the institution forwarding a request to BBPCU.

4 Alphanumeric

Alpha 2 Numeric 2

OU01 Y

AI ID

Unique Id associated with Agent Institution

4 Alphanumeric Alpha 2 Numeric 2

OX34 Y

Agent ID

Agent ID is the unique number which identifies the agent.

20 Alphanumeric

OU 1 code: 4; Agent Institution name: 4; random number: 12

OU01OX34000001123456

Y (if not initiated by an agent institution 4 characters should be filled with zero)


Biller ID

Biller ID is the unique number which identifies the biller.

14 Alphanumeric

4 characters from the name of the biller (may be augmented with leading zeroes if the name itself is less than 4 characters) – 04 Sub-biller - 05 (this may be 00000 if there are no sub-billers) Region -03 Random number - 02

VODA00000MUM03

Y

Customer ID

Customer ID is the unique number which identifies the customer who registers in BBPS

14 Alphanumeric

The customer registration number will be a 14 digit numeric string and will be linked to the mobile number provided by the customer at the time of registration. The string will be a combination of the 4-digit OU code and a 10-digit sequential number generated by the system.

SBO18108108682

NA

System User ID-CU

Uniquely identifies the BBPCU user

16 Alphanumeric

BBPCU ID (4-character) + '_'+user ID provided by BBPOU (11-character alphanumeric)

BBCU_User1 NA

System User ID-OU

Uniquely identifies the BBPOU user

16 Alphanumeric

BBPOU ID (4-character) + '_'+user ID provided by BBPOU (12-character alphanumeric)

OU12_User2 Y

ComplaintId

Complaint ID generated by BBPCU

15 Alphanumeric Random 15 digit alphanumeric value

AN1466576405897

NA


15 Payment Mode & Channel Details

S.

No. Payment Channel Capture Info

1 INT IP|MAC

2 MOB IP|IMEI|OS|APP

3 POS MOBILE, GEOCODE, POSTAL_CODE, TERMINAL_ID

4 MPOS MOBILE, GEOCODE, POSTAL_CODE, TERMINAL_ID

5 KIOSK TERMINAL_ID

6 ATM TERMINAL_ID

7 BNKBRNCH MOBILE, GEOCODE, POSTAL_CODE, IFSC

S.

No. Payment Mode Capture Info

1 Cash Remarks

2 Credit Card CardNum|AuthCode

3 Debit Card CardNum|AuthCode

4 IMPS MMID|MobileNo

5 Internet Banking IFSC|AccountNo

6 NEFT IFSC|AccountNo

7 Prepaid Card CardNum|AuthCode

8 Wallet WalletName|MobileNo

9 UPI VPA

Acceptance of Payment Mode at various Channels

Sr.No Payment Mode INT MOB POS MPOS KIOSK ATM BNKBRNCH 1 Cash N n n n y n Y

2 Credit Card Y y y y y y Y

3 Debit Card Y y y y y y Y

4 IMPS Y y n n n n Y

5 Internet Banking

Y y n n n y N

6 NEFT Y y n n n y Y

7 Prepaid Card Y y y y y y Y

8 Wallet Y y y y y n N

9 UPI Y y n n n n N


16 Elements description

Element: Root

Presence: Mandatory

Definition: XML root element representing each API (Bill request / bill response /

diagnostic request / diagnostic response

Data Type: CodeSet

Format: Min Length: 1

Max Length: 35 Compliance: Message id should be sent per the below mentioned table Code Definition

BillFetchRequest Defines the message is a request message

BillFetchResponse Defines the message is a response message

BillPaymentRequest Defines the message is a payment request

BillPaymentResponse Defines the message is a payment response

ReqDiagnostic Defines the message is a diagnostic request

ResDiagnostic Defines the message is a diagnostic response

TxnStatusComplainRequest Defines the message is transaction status and complaint

request

TxnStatusComplainRespons

e

Defines the message is a transaction status and

complaint response

Biller MDM Request Defines the message is a Biller MDM Request

Biller MDM Response Defines the message is a Biller MDM Response

Attribute: xmlns

Presence: Mandatory

Definition: API Schema Namespace.

Data Type: Alphanumeric


Max Length: 255

Element: <Head>

Presence: Mandatory

Definition: Header of the message.

Attribute: ver

Presence: Mandatory

Definition: Version of the API

This is the API version. NPCI may host multiple versions for supporting

gradual migration. As of this specification, default production version is

"1.0".



Max Length: 6


Attribute: ts

Presence:Mandatory

Definition: Time of request from the creator of the message.

API request time stamp. Since time stamp plays a critical role, it is highly

recommended that devices are time synchronized with a time server

Data Type: ISODateTime

Format: Max Length: 25

YYYY-MM-DDThh:mm:ss+hh:mm

(eg 1997-07-16T19:20:30Z+05:30)

where;

YYYY = four-digit year

MM = two-digit month (01=January, etc.)

DD = two-digit day of month (01 through 31)

T = separator used between date and time

hh = two digits of hour (00 through 23) (am/pm NOT allowed)

mm = two digits of minute (00 through 59)

ss = two digits of second (00 through 59)

+hh:mm = time zone difference from GMT in hours and minutes.

The default value of this attribute is assumed to be IST (+5.30).

Compliance: Transactions are allowed up to - 1 hour of the current date.

Attribute: origInst

Presence: Mandatory

Definition: It is a unique code allocated by BBPCU for identifying the institution

forwarding a request to BBPCU.


Format: Fixed 4 (Alpha – 02, Numeric – 02, e.g. OU12)

Compliance: The value should present in the table maintained by BBPCU.

Attribute: refId

Presence: Mandatory

Definition: Code generated by the OU that acquires the customer for every bill fetch

transaction initiated and used across all messages. UUID logic defined by ISO

to be used for generation of the reference number


Format: Fixed 35

Compliance: Data format and type. The ID should be same for fetch and payment request as

well as in response for all transactions including reversals.

Element: <Analytics>

Presence: Optional

Definition: The data provided in the Meta element will be used for MIS and analytics

purpose

Element: <Analytics.Tag>

Presence: Optional


Definition: The tag is defined in name value pairs to accommodate the MIS related

parameters. The tag itself is optional and if the tag is present it is

mandatory to have the two attributes with two codes mentioned below

Attribute: name

Presence: Optional

Definition: The name attribute will have the values as defined in the code table

Data Type: CodeSet


Max Length: 20

Code Definition FETCHREQUESTSTART The time at which the fetch request

transaction was initiated in the device FETCHREQUESTEND The time at which the fetch transaction was

sent out from the device PAYREQUESTSTART The time at which the payment request

transaction was initiated in the device PAYREQUESTEND The time at which the payment transaction was

sent out from the device

Attribute: value

Presence: Optional

Definition: The data provided will have the details of transaction initiated time and end

time in the device/medium


Format: Min Length 1

Max Length 255

Compliance: Data format and type

Code Example FETCHREQUESTSTART 2015-02-16T22:02:00+05:30 FETCHREQUESTEND 2015-02-16T22:02:35 +05:30 PAYREQUESTSTART 2015-02-16T22:02:00+05:30 PAYREQUESTEND 2015-02-16T22:02:35 +05:30

Element: <Txn>

Presence: Mandatory

Definition: This element contains the transaction details and is passed to all parties

involved in the transaction processing. This element is populated by the

originator of the transaction and the same must be passed across all the

entities.

Attribute: txnReferenceId

Presence: Conditional

Definition: This data element will contain a unique ID for all BBPS payment transactions


Format: Fixed 12

OU 1 code (customer acquiring) – 04 ; Random alphanumeric character – 08


Compliance: This field should be present for all payment transaction.

Attribute: ts

Presence: Mandatory

Definition: Time of request from the creator of the message. It is represented in

GMT/UTC.

API requests time stamp. Since time stamp plays a critical role, it is

highly recommended that devices are time synchronized with a time server



YYYY-MM-DDThh:mm:ss+hh:mm

(eg 1997-07-16T19:20:30+00:00)

where;








+hh:mm = time zone difference from GMT in hours and minutes.

If not provided, it is assumed to be GMT / UTC (+0.00).

Compliance: Transactions are allowed up to - 1 hour of the current date.

Attribute: type


Definition: This attribute describes the type of the transaction for bill fetch and payment

Data Type: CodeSet


Max Length 35


Code Definition FORWARD TYPE REQUEST When an initiated transaction is in forward

nature REVERSAL TYPE REQUEST When an initiated transaction is in reversal

nature FORWARD TYPE RESPONSE When a response is sent to the forward type

request REVERSAL TYPE RESPONSE When a response is sent to the reversal type

response

Attribute: msgId

Presence: Mandatory

Definition: Code generated by the OU that acquires the customer for every transaction

initiated. UUID logic defined by ISO to be used for generation of the reference

number and is used for matching with every request and response message



Format: Fixed 35

Compliance: Data format and type. The ID should be same for request as well as in response for all transactions.

Attribute: xchangeId


Definition: Identification of the type of the request (transaction status, complaint

status, complaint registration)

Data Type: CodeSet

Format: Fixed 3

Compliance: Data should be sent as mentioned in the below table

Code Definition

401 Transaction status

501 Off-us complaint registration

502 Complaint re-assignment

504 Off-us complaint re-open

506 Complaint status

507 Complaint closure

Element: <Txn.RiskScores>

Presence: Mandatory

Definition: This element defines the risk evaluation associated with the transaction and

the interested parties in the transaction.

Element: <Txn.RiskScores.Score>

Presence: Mandatory

Definition: Risk Score related to the transaction and the entities.

Attribute: provider

Presence: Mandatory

Definition: Entity providing the risk score. This is the entity which evaluates the risk

associated with the transaction.

Data Type: CodeSet

Format: Fixed 4

Compliance: Codes allocated to the provider by BBPCU at the time of on-boarding

Attribute: type

Presence: Mandatory

Definition: This attribute describes the type of risk

Data Type: CodeSet


Max Length 20


Compliance: Pre-defined values

Attribute: value

Presence: Mandatory

Definition: Value of risk score ranging from 000(No Risk) to 100 (Maximum Risk)

Data Type: Numeric

Format: Fixed 3

Element: <Customer>

Presence: Mandatory

Definition: Customer related details who initiates the transaction.

Attribute: mobile

Presence: Mandatory

Definition: Mobile number of customer who initiates the bill payment

Data Type: Numeric

Format: Fixed 10


Attribute: name



Data Type: CodeSet


Max Length: 255

Code Definition EMAIL Email ID of the customer AADHAAR Aadhaar number of the customer PAN PAN of the customer

Attribute: value


Definition: Specified value as defined

Data Type: AlphanumericSpecial


Max Length 255


Code Value EMAIL [email protected] AADHAAR 123123123200 PAN BXXPC4454Q

Element: <Agent>

mailto:[email protected]


Presence: Mandatory

Definition: Agent related details who initiates the transaction.

Attribute: id

Presence: Mandatory

Definition: Agent ID is the unique number which identifies the agent.


Format: Fixed 20


(if not initiated by an agent institution 4 characters should be filled with

zero), e.g. OU01OX34000001123456


Element: <Agent.Tag>


Definition: This tag captures the device details in name value pair

Attribute: name



Data Type: CodeSet


Max Length: 255

Code Definition Presence MOBILE Mobile number of the agent Conditional GEOCODE Latitude and longitude of the

device – Represented in degrees, minimum 4 digits (after decimal)

Conditional

POSTAL_CODE Postal code of the agent Conditional IP IP address of the device Conditional INITIATING_CHANNEL Initiating channel of the

transaction INT – Internet MOB – Mobile POS – Point of sale devices MPOS – Mobile point of sale devices KIOSK – Kiosk device ATM – Automated teller machine BNKBRNCH- Bank branch

Mandatory

TERMINAL_ID Terminal ID of the device Conditional IMEI IMEI number of the mobile Conditional IFSC IFSC of the branch from which

the transaction is initiated Conditional

MAC MAC ID of the terminal Conditional OS Operating system used on the

device Conditional

APP Application name Conditional


Attribute: value





Max Length 255


Code Format Example MOBILE nnnnnnnnnn

Max Length – 10 9820098200

GEOCODE nn.nnnn,nn.nnnn Max Length - 20

12.9667,77.5667

IP Valid IP address format(v4,v6) Fixed 15

123.456.121.121

INITIATING_CHANNEL Initiating channel of the transaction CodeSet Min Length – 1 Max Length – 20

INT – Internet MOB – Mobile POS – Point of sale devices MPOS – Mobile point of sale devices ATM – Automated teller machine BNKBRNCH- Bank branch

TERMINAL_ID Terminal ID of the initiating transaction Min Length – 1 Max Length – 10

123456

IMEI IMEI address of the device Fixed Length - 15

123456789012345

IFSC IFSC of the branch Fixed Length – 11

ABCD0001152

MAC MAC Id of the device Fixed Length – 17

00-0D-60-07-2A-FO

OS Operating system used in the device Min Length – 1 Max Length – 20

iOS 8.1

APP Application used in the device Min Length – 1 Max Length – 20

SB 1.0

Element: <BillDetails>

Presence: Mandatory

Definition: This tag captures the bill and biller id related details

Element: < Biller>

Presence: Mandatory

Definition: Biller related details who initiates the transaction.


Attribute: id

Presence: Mandatory

Definition: Biller ID is the unique number which identifies the agent.


Format: Fixed 14

4 characters from the name of the biller (may be augmented with leading

zeroes if the name itself is less than 4 characters) – 04 Sub-biller - 05

(this may be 00000 if there are no sub-billers)

Region -03 Random number - 02


Element: <CustomerParams>

Presence: Mandatory

Definition: This tag captures the customer parameters

Attribute: < CustomerParams.Tag>


Definition: This tag captures the biller’s reference field in name value pair

Attribute: name



Data Type: CodeSet



Max Length: 255

Code Definition

RefFld1

Reference fields that may be customised according to the requirements of specific billers at the time of on-boarding. Sample data that may be entered in these fields include Customer account number (for electricity suppliers), Cycle number (for landline operators) etc. These data elements would be conditional, i.e. they would be mandatory for specific billers only

RefFld2

RefFld3

RefFld4

RefFld5

RefFld6

RefFld7

Attribute: value






Max Length 255


Code Format Example

RefFld1

As defined at the time of on-boarding by the biller

BBPOU

23434FF11

RefFld2 NE321

RefFld3 NO

RefFld4 1223333

RefFld5 YES

RefFld6 32323DD

RefFld7 DD3331

Element: <Reason>

Presence: Mandatory

Definition: This tag captures the response reason of the transaction

Attribute: approvalRefNum

Presence: Mandatory

Definition: Approval reference number is a code for the biller’s BBPOU to indicate

acceptance of the request message.


Format: Fixed 8

Compliance: This field should be present if transaction is successful.

Attribute: responseCode

Presence: Mandatory

Definition: The response code of the transaction.

Data Type: Numeric

Format: Fixed 3

Compliance: Data should be sent per the response code list.

Attribute: responseReason

Presence: Mandatory

Definition: The response reason of the response code sent by the biller OU.

Data Type: Alpha


Max Length: 35

Compliance: This field should be present if transaction is successful.


Attribute: complianceRespCd


Definition: The compliance response code for the compliance violation of the specific

rule-set by BBPCU


Format: Fixed 3

Compliance: --

Attribute: complianceReason


Definition: The compliance response description for the compliance violation of the

specific rule-set by BBPCU

Data Type: Alpha


Max Length: 35

Compliance: --

Element: <BillerResponse>

Presence: Mandatory

Definition: This tag captures the bill responses provided by the biller

Attribute: customerName

Presence: Mandatory

Definition: Customer name as registered with the biller



Max Length: 35


Attribute: amount

Presence: Mandatory

Definition: This data element will carry the actual bill amount inclusive of all charges

if applicable

Data Type: Numeric


Max Length: 18

Compliance: Data format and type. In reversal transaction amount should be same as

original request.

Attribute: dueDate

Presence: Mandatory

Definition: This field denotes the due date of the bill


Data Type: ISO date format

Format: Fixed Length: 10


Attribute: CustConvFee


Definition: The exact convenience fee applicable for specific payments mode which the

biller wants to levy (e.g. Rs 10 for Cash, Rs 20 for Debit Card etc.). If

the biller doesn't levy a surcharge the value of the field should be ZERO

Data Type: Numeric


Max Length: 18

Attribute: CustConvDesc


Definition: The convenience fee description



Max Length: 35

Attribute: billDate

Presence: Mandatory

Definition: This field denotes the generation date of the bill

Data Type: ISO date format



Attribute: billPeriod

Presence: Mandatory

Definition: The bill period of the bill fetch / payment requested



Max Length: 35

Attribute: billNumber

Presence: Mandatory

Definition: This field denotes the bill number of the bill fetch / payment message

requested



Max Length: 35


Element: < BillerResponse.Tag>


Definition: This tag captures the biller’s amount fields in name value pair


Attribute: name



Data Type: CodeSet


Max Length: 255

Code Definition

Amount 1 Amount fields that may be customised according to the requirements of specific billers at the time of on-boarding. Sample data that may be entered in these fields include total amount due and minimum amount due etc. These data elements would be conditional, i.e. they would be mandatory for specific billers only

Amount 2

Amount 3

Amount 4

Attribute: value



Data Type: Numeric


Max Length 18


Code Format Example

Amount 1

As defined at the time of on-boarding

120011

Amount 2 10011

Amount 3 1111

Amount 4 11113

Element: < AdditionalInfo.Tag>


Definition: This tag captures the biller’s response fields in name value pair

Attribute: name



Data Type: CodeSet


Max Length: 255

Attribute: value






Max Length 255


Code Format Example

BlRspFld1

As defined at the time of on-boarding

YES

BlRspFld2 NE321

BlRspFld3 NO

BlRspFld4 1223333

Element: <PaymentMethod>

Presence: Mandatory

Definition: This tag captures the payment method used for the transaction

Attribute: quickPay

Presence: Mandatory

Definition: Defines the payment is initiated is quick pay in nature

Data Type: CodeSet


Max Length: 3

(Yes | No)


Attribute: splitPay

Presence: Mandatory

Definition: Defines the payment is initiated is split pay in nature

Data Type: CodeSet


Max Length: 3

(Yes | No)


Attribute: paymentMode

Presence: Mandatory

Definition: Defines the payment mode which is used for the bill payment

transaction

Data Type: CodeSet


Max Length: 35


Code Definition


Internet Banking Transaction initiated by internet banking channel

Debit Card Transaction initiated by debit card

Credit Card Transaction initiated by credit card

Prepaid Card Transaction initiated by prepaid card

IMPS Transaction initiated by IMPS

ATM Transaction initiated by ATM

Cash Transaction initiated by cash

UPI Transaction initiated by UPI

Wallet Transaction initiated by wallet

Element: <Amount>

Presence: Mandatory

Definition: Block containing different amount related details for the transaction

Element: <Amt>

Presence: Mandatory

Definition: Details of the amount which is paid for the transaction

Attribute: amount

Presence: Mandatory

Definition: This data element will carry the actual bill payment amount inclusive of all

charges if applicable

Data Type: Numeric


Max Length: 18

Compliance: Data format and type. In reversal transaction amount should be same as

original request.

Attribute: currency

Presence: Mandatory

Definition: Defines the currency in which the payment is initiated

Data Type: Code set (ISO 4217)

Format: Fixed 3


Element: <SplitPayAmount>


Definition: This data element will carry the bill payment amount which is paid in the

mode other than the primary mode of payment

Data Type: Numeric


Max Length: 18

Compliance: Data format and type.

Attribute: <PaymentInformation>



Definition: Details of the payment instrument used for the payment. This tag will

flow from customer OU to CU and it won’t be passed to the biller OU.

Attribute: <PaymentInformation.Tag>


Definition: Details of the payment instrument used for the payment

Attribute: name



Data Type: CodeSet


Max Length: 255

Code Description

Remarks Remarks when the mode of payment is cash

CardNum|AuthCode Card number and authorization code used for the payment

IFSC|AccountNo IFSC and account number used for the payment

MMID|MobileNo MMID and mobile number used for the payment

WalletName|MobileNo Wallet name and mobile number used for the payment

VPA Virtual Provider Address used for the payment

Attribute: value





Max Length 255


Code Format Example Remarks Alphanumeric

Fixed Length – 6 UNI000

CardNum|AuthCode Numeric Min Length – 23 Max Length –27

1234567890123456|123456

IFSC|AccountNo Alphanumeric Min Length – 15 Max Length –30

SRAN0000341|0123456


MMID|MobileNo Alphanumeric Fixed Length 18

9240111|9004644121

WalletName|MobileNo Alphanumeric Min Length – 19 Max Length – 25

123456789011|652150

VPA

Attribute: <TxnStatusComplainReq>


Definition: Information pertaining to transaction status and complaint request

and complaint status

Attribute: complaintId


Definition: Complaint ID generated by BBPCU to check the status of a complaint




Attribute: servReason


Definition: Reason for the service based complaints

Data Type: CodeSet


Max Length: 255


Attribute: participationType


Definition: Entity type for the service based complaints

Data Type: CodeSet


Max Length: 255


Attribute: agentId


Definition: Unique identification code allocated to the agent for the service

based complaints


Format: Fixed 20


(if not initiated by an agent institution 4 characters should be filled with

zero), e.g. OU01OX34000001123456



Attribute: billerId


Definition: Unique identification code allocated to the biller for the service

based complaints


Format: Fixed 14

4 characters from the name of the biller (may be augmented with leading

zeroes if the name itself is less than 4 characters) – 04 Sub-biller - 05

(this may be 00000 if there are no sub-billers)

Region -03 Random number - 02


Attribute: category


Definition: Category of complaint for transaction based complaints

Data Type: CodeSet


Max Length: 255


Attribute: disposition


Definition: Disposition of complaint for transaction based complaints

Data Type: CodeSet


Max Length: 255


Attribute: description


Definition: Description of the complaint

Data Type: CodeSet


Max Length: 255


Attribute: complaintType


Definition: Type of complaint – Transaction or Service based complaint

Data Type: CodeSet


Max Length: 255



Attribute: <TxnStatusComplainResp>


Definition: Information pertaining to transaction status and complaint response

and complaint status

Attribute: openComplaint


Definition: Indicates if the complaint is open or closed

Data Type: CodeSet

Format: Fixed 1 (Y|N)


Attribute: complaintStatus


Definition: Response code for the diagnostic request

Data Type: CodeSet


Max Length: 35

Compliance: Complaint status should be sent per the below mentioned table

Code Definition

Assigned A customer has raised a complaint at an agent outlet or on

the BBPS website, and a ticket ID has been assigned to it.

At this stage, the customer OU has assigned the complaint to

the biller OU depending on the details of the complaint.

Pending with BBPOU The complaint is still to be addressed by the BBPOU or its

biller or agent

Resolved Once the biller / BBPOU resolves the customer related

complaint, the BBPOU updates the system

Additional

information required

The biller / BBPOU requires further information for the

complaint, and updates the system accordingly

Rejected Once the biller / BBPOU rejects the complaints, the BBPOU

updates the system

Escalated If the biller / BBPOU doesn’t respond to the complaint by

the specified TAT, the complaint gets escalated (except

service-based complaints)


Attribute: assigned


Definition: Complaint assigned to the OU


Format: Fixed 4 (Alpha – 02, Numeric – 02, e.g. OU12)

Compliance: The value should present in the table maintained by BBPCU.

Attribute: <TxnStatusComplainResp.TxnList>


Definition: List of transactions containing the details of transactions linked to

a mobile number

Attribute: <TxnStatusComplainResp.TxnList.TxnDetail>

Presence: Mandatory

Definition: Record containing the details of a single transaction

Attribute: txnDate


Definition: Original transaction date of the bill payment

Data Type: ISODate


YYYY-MM-DDThh:mm:ssZ+05:30 (eg 1997-07-16T19:20:30+00:00)

where;








Z +/- hh:mm = time zone designator (Z) followed by time zone difference from

GMT in hours and minutes.

If not provided, it is assumed to be GMT / UTC (+0.00).


Attribute: txnStatus

Presence: Mandatory

Definition: Status of the transaction

Data Type: CodeSet


Max Length: 255


Attribute: <TxnStatusComplainResp.CustomerDetails>



Definition: Details of the customer

Attribute: name


Definition: Name of the customer



Max Length: 255


ANYTIME, ANYWHERE BILL PAYMENT

Agenda

> About BBPS

> Key participants

> System design

For more information, contact us on [email protected]


Bharat Bill Payment System

Bharat Bill Payment System (BBPS) is a Reserve Bank of India (RBI) conceptualised system which

offers integrated, accessible and interoperable bill payment services to consumers across

geographies with certainty, reliability and safety of transactions.

It offers bill payment services to consumers through network of agents/retail shops/bank-branches and digital channels like

Internet banking of banks, Mobile app of banks etc. allowing multiple payment modes like Card, UPI, AePS, Wallet, Cash and

provides instant confirmation. It will facilitate a less cash society through migration of bill payments from cash to electronic

channel

Consumer

Website/Internet Banking of Non-banks/Banks

Bank/Non-bank entity facing

Customer

Bank/Non- bank entity connected with Utility Cos.

Utilities e.g. Electricity, Water,

Gas, telecom

1.Consumer (Payer) uses a channel for payment

2. Bank/Non-bank debits the account, collates information

and transmits to BBPCU

3. BBPCU undertakes settlement between BBPOUs and passes the bill information and payment message

4. Utility connected Bank/Non-bank entity sends information to

Utilities and credits accounts

Mobile App of Banks/Non-banks

Agents/Retail shops/ BCs of Banks/Non-banks

BBPS -Salient Features

BBPS will be an integrated platform connecting banks and non-banks in bills aggregation business, Billers , payment service providers and retail bill outletsInteroperable

Facilitate seamless payment of bills through any channel : Digital and physicalAccessible

Most cost-effective for entire ecosystem – Flat fee charge vs current ad valoremCost-effective

BBPOUs will have to connect only to BBPCU to get access to all the billers. Utility companies just need to connect to maximum two BBPOUs to enable all customers to pay bills. Integration

Standardised system to handle customer grievances for both ON-US and OFF-US transactionsComplaint Management

Facilitate BBPOU’s to raise and resolve disputes relating to transactions that have passed through the BBPS systemDispute Management

Multiple Clearing & Guaranteed Settlements between different parties, standardised TAT Clearing & Settlement

Standardisation of processes for entire BBPS ecosystemStandardisation

Single and trusted brand connect and BBPS Assurance Brand Connect

Payment Options


Internet | Internet Banking| Mobile | Mobile Banking |POS | MPOS | KIOSK | ATM | Bank Branch | Business Correspondents | Agents

Payment Channels

Cash | Credit Card | Debit Card | IMPS | Internet Banking | Account transfer | Prepaid Card | Wallet| UPI |AEPSPayment Mode

Full | Minimum | Excess | Part | Penalty | MultiplePayment Options


Agenda

> About BBPS

> Key participants

> System design



System Participants

Customer

Agent Institutions/Agents

Banks

BBPCU

Aggregator / Service Providers

Billers

Sponsor Banks BBPOU

BBPOU



Bharat Bill Payment Central Unit (BBPCU) will be the single authorizedentity operating the BBPS

BBPCU

(NPCI)

Bharat Bill Payment Operating Units (BBPOUs) will be the authorisedoperational units. Below are the type of BBPOUs:

BBPOUs

(Banks and Non-Bank Entities)

BBPS – Two-tiered Structure



Following services along with core utilities may be incorporated in BBPS

Biller Categories in BBPS

RBI approved

Electricity

Water/ Municipality

Gas Supply

Telecom

DTH

Institution Fees*

School Fees

College Fees

Subscription Fees

Others*

Insurance

Mutual Funds

Credit Card Bill Payments

Govt. payments

Future*

One time payments

EMI’s (NBFC)

Housing Society

Others

Later

* Later category expansions are subject to RBI approval

Types of Billers

- Biller is connected online to respective BBPOU

- All the communications is happening on real-time basis

- BBPOU will confirm the bill payment only after getting confirmation fromrespective biller.

Online Mode

- Biller is not connected to the BBPOU on real time basis

- Provides a file of expected bills on regular basis to respective OU

- BBPOU will confirm the bill payment basis the bill information dumpprovided by the respective biller

Offline Mode (A)

- The biller does not require a Bill Fetch or is not connected to the BBPOU on a real time basis.

- In this scenario, the BBPOU receives all the bill payment requests for thatparticular biller without any validation.

Offline Mode (B)

*Settlement for all the above type of transactions takes place as per the “Settlement Cycle”For more information, contact us on [email protected]


Benefits to Participants

Benefits to BBPOU

• Single integration and recon to have access with multiple billers

• Expand reach to customers through OFF-US business

• Potential to offer value added services like online presentment

• Standard interface, Interchange

• Timely and Guaranteed Settlement

• Dispute Management

Benefits to Biller

• Cost-effective platform

• Improved liquidity position due to faster settlements

• Low entry barriers for small billers or ones confined to small geographies

• Billers will have plug and play connection options with flexibility (only 2 standard APIs)

• Lower CAPEX and OPEX due to reduced and efficient connections

Benefits to Customer

• Control: Payment of bills via one-platform

• Accessibility: Facility of paying bills digitally (Internet, Mobile etc.) as well as physical outlets.

• Convenience, Time saving, Uniform experience and flexibility of payment channels

• Reliable service with high degree of trust and security

• Transparent pricing with instant payment confirmation

• Unified Grievance Handling



> About BBPS

> Key participants

> System design


Agenda


ON-US & OFF-US Transaction


CONSUMER AGENT/RETAIL SHOP AGENT-INSTITUTION Customer BBPOU (Bank/Non-bank)

Digital Channels like Mobile ,

Internet, POS

Biller BBPOU (Bank/Non-bank)

Billers/Utility Comapnies

ON-US Transaction

OFF-US Transaction


Transactional Flow – Bill Fetch



Transactional Flow – Payment Confirmation

* Illustrative Cash Mode



Key Parameters of Bill Fetch API

Bill Fetch Request (Initiated by the Customer-BBPOU)

This API will enable the user to input certain parameters as required by the biller to fetch bill information.

Customer identification parameters at the biller can be more than one and the system is capable of supporting the same.

Key Parameters include : <Initiating Channel>, <Agent Details>, <Biller Information>, <Bill Details>, <Customer details>

Bill Fetch Response(Initiated by Biller-BBPOU)

This request will enable the biller to provide output parameters as a response to bill fetch request.

Biller can respond with multiple amount field, additional fields regarding bill and any other information as desired by the biller

Key Parameters include: <Customer Information>, <Bill Information>, <Charges & Fees>.

* All input and output parameters will be configured at biller level at the time of Biller Onboarding

Key Parameters of Payment Message API

Payment Request(Initiated by the Customer-BBPOU)

This request will enable the user to provide parameters defining the payment request details as per biller configuration.

Key Parameters include: <Channel>, <Payment Mode>, <Biller & Bill Information>, <Customer Information>

Payment Response(Initiated by Biller-BBPOU)

This request will enable the biller to confirm the payment parameters.

Key Parameters include: <Bill Information>, <Transaction Status>

* All input and output parameters will be configured at biller level at the time of Biller Onboarding* Bill Payment Request API includes all details of the previous Bill Fetch Response

Key Parameters of Online Specs

Diagnostic Diagnostic message is a confirmation from the BBPOU to BBPCU that the respective BBPOU is in active status and available for receiving and processing bill payment transaction

BBPOU will be triggering the diagnostic API at a desired time-frame, continuous failing of these ping requests will mark the BBPOU inactive and transaction will not be processed at BBPCU end.

Acknowledgment An acknowledgement message is a confirmation sent in synchronous mode from the recipient to the sender of a message and will be a part of each leg of the payment transaction message.

Reversal Failure to receive an acknowledgement from any participant in BBPS for a bill payment transaction will result in a reversal where the entire transaction will be reversed and an intimation will be sent to the origination point to return the amount to the customer through the same payment mode.

The initiating party is the entity which has initiated a leg of the bill payment transaction but has not received its acknowledgement.



BBPOU(Non Bank)BBPOU(Bank)BBPOU

BBPCURBI

RTGS account

Sponsor Bank

Succ

ess

ful p

aym

en

t co

llect

ion

in

form

atio

nNet RTGS settlement

Settlement Flow



Other Features

• Clearing & Settlement

• Bill Presentment and Deferred Payments

• Complaint Management System

• Dispute Management System

• Velocity monitoring and Net Debit Cap

• Settlement Guarantee Fund (SGF) Mechanism

• Fraud & Risk Management (FRM)

• Refund Mechanism

• Admin Section – BBPOU CANVAS

• Reporting & MIS

• Bulk Upload Feature

• Management of Master Data Management (MDM)



Complaint Management System (CMS)

• BBPCU shall put in place a centralized end to end complaint management system for all ON-US andOFF-US transactions.

• Customer can register complaints at:• Any BBPOU portal or agent outlet/branch• Centralized BBPCU website

• Two kinds of complaints are envisaged for BBPS:• Transaction-based complaint• Service-based complaint



Dispute Management System (DMS)

• Dispute Management System will facilitate BBPOU’s to raise and resolve a dispute on a transaction

that has previously been cleared by the BBPCU or BBPOU

• DMS will have a process of arbitration where the BBPCU’s arbitration committee will deliver a final

verdict

• Complaints not resolved through the CMS can be manually uploaded to the DMS

• BBPOUs will also be able to raise disputes in DMS against any other BBPOUs

• Various levels of DMS:

• Dispute Initiation: Credit Adjustment / Refund

• Pre-arbitration

• Arbitration

• Good faith



Thank you !

Documents

Fintech Bengalathon Guidelines v1.1 · 3.2. Bengalathon has five problems pertaining to Fintech domain. Participant have to select “Financial Services” and/or “ideation” domain