0% found this document useful (0 votes)

60 views155 pages

BBPS API Specifications v14!0!1

The BBPS API Specifications document outlines various APIs used within the BBPS framework, detailing request and response structures for bill fetching, payments, transaction status checks, and validations. It includes sample API calls, tag details, and XML schema definitions (XSD) for each API type. The document also provides historical changes and updates across different versions, with the latest version being 14.0, released on February 20, 2021.

Uploaded by

namrata.singh

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

60 views155 pages

BBPS API Specifications v14!0!1

Uploaded by

namrata.singh

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 155

BBPS API SPECIFICATIONS

Version 14.0
Date: 20.02.2021

Abstract
This document contains information pertaining to different APIs used in BBPS and
some considerations which will be beneficial while designing the same.
1

Table of Contents
Document History ............................................................................................................................................................. 6
1 Bill Fetch Request & Response .................................................................................................................................. 8
Sample Fetch Request API: Customer BBPOU to BBPCU .................................................................................. 8
Sample Fetch Request API: BBPCU to Biller BBPOU.......................................................................................... 9
Sample Fetch Response API: Biller BBPOU to BBPCU ....................................................................................... 9
Sample Fetch Response API: BBPCU to Customer BBPOU .............................................................................. 10
Bill Fetch Request Tag Details ......................................................................................................................... 11
Bill Fetch Request XSD..................................................................................................................................... 12
Bill Fetch Response Tag Details ....................................................................................................................... 12
Bill Fetch Response XSD .................................................................................................................................. 13
2 Bill Payment Request & Response .......................................................................................................................... 14
Sample Payment Request API: Customer BBPOU to BBPCU........................................................................... 14
Sample Payment Request API: BBPCU to Biller BBPOU .................................................................................. 15
Sample Payment Response API: Biller BBPOU to BBPCU ................................................................................ 17
Sample Payment Response API: BBPCU to Customer BBPOU ........................................................................ 17
Sample Reversal Request API: BBPCU to Biller BBPOU ................................................................................... 18
Sample Reversal Response API: Biller BBPOU to BBPCU ................................................................................ 18
Sample Reversal Response API: BBPCU to Customer BBPOU ......................................................................... 18
Bill Payment Request Tag Details .................................................................................................................... 18
Bill Payment Request XSD ............................................................................................................................... 21
Bill Payment Response Tag Details.................................................................................................................. 21
Bill Payment Response XSD ............................................................................................................................. 22
3 Transaction Status Check (402) API Request & Response (for Pending Transactions) ........................................... 23
402 API Request: BBPCU to Biller BBPOU ....................................................................................................... 23
402 API Response: Biller BBPOU to BBPCU ..................................................................................................... 23
402 API Request Tag Details ............................................................................................................................ 23
402 API Request XSD ....................................................................................................................................... 24
402 API Response Tag Details ......................................................................................................................... 24
402 API Response XSD ..................................................................................................................................... 25
4 Bill Validation Request & Response ........................................................................................................................ 26
Sample Validation Request API: Customer BBPOU to BBPCU......................................................................... 26
Sample Validation Request API: BBPCU to Biller BBPOU ................................................................................ 26
Sample Validation Response API: Biller BBPOU to BBPCU .............................................................................. 27
Sample Validation Response API: BBPCU to Customer BBPOU ...................................................................... 27

BBPS API SPECIFICATIONS | Version 14.0

Bill Validation Request Tag Details .................................................................................................................. 27

Bill Validation Request XSD ............................................................................................................................. 28
Bill Validation Response Tag Details ............................................................................................................... 28
Bill Validation Response XSD ........................................................................................................................... 29
5 Diagnostic Request & Response .............................................................................................................................. 29
Sample Request API: BBPOU to BBPCU........................................................................................................... 29
Sample Response API: BBPCU to BBPOU ........................................................................................................ 29
Diagnostic Request Tag Details ....................................................................................................................... 30
Diagnostic Request XSD................................................................................................................................... 30
Diagnostic Response Tag Details ..................................................................................................................... 30
Diagnostic Response XSD ................................................................................................................................ 31
6 Transaction Status and Complaint Related API Request & Response..................................................................... 31
Sample Transaction Status (401) Request API – Using Mobile Number & Date Range: BBPOU to BBPCU .... 31
Sample Transaction Status (401) Response API (new URL) – Using Mobile Number & Date Range: BBPCU to
BBPOU 32
Sample Transaction Status (401) Response API (old URL) – Using Mobile Number & Date Range: BBPCU to
BBPOU 32
Sample Transaction Status (401) Request API – Using Transaction Ref ID: BBPOU to BBPCU ....................... 33
Sample Transaction Status (401) Response API (new URL) – Using Transaction Ref ID: BBPCU to BBPOU ... 33
Sample Transaction Status (401) Response API (old URL) – Using Transaction Ref ID: BBPCU to BBPOU ..... 33
Sample Complaint Raise (501) Request API – Transaction Based: BBPOU to BBPCU ..................................... 34
Sample Complaint Raise (501) Response API – Transaction Based: BBPCU to BBPOU................................... 34
Sample Transaction Based Complaint Re-assignment (502) Request API: Customer BBPOU to BBPCU ........ 34
Sample Transaction Based Complaint Re-assignment (502) Response API: BBPCU to Customer BBPOU ..... 35
Sample Complaint Status (506) Request API: BBPOU to BBPCU ..................................................................... 35
Sample Complaint Status (506) Response API: BBPCU to BBPOU .................................................................. 35
Sample Complaint Closure (507) Request API: BBPOU to BBPCU................................................................... 35
Sample Complaint Closure (507) Response API: BBPCU to BBPOU ................................................................ 36
Sample Complaint Re-Open (503) Request API: BBPOU to BBPCU................................................................. 36
Sample Complaint Re-Open (503) Response API: BBPCU to BBPOU .............................................................. 36
Sample Complaint Status Change (508) Alert API: BBPCU to BBPOU ............................................................. 37
Transaction Status and Complaint Related API Request Tag Details .............................................................. 37
Transaction Status and Complaint Related API Request XSD ......................................................................... 38
Transaction Status and Complaint Related API Response Tag Details ............................................................ 39
Transaction Status and Complaint Related API Response XSD ....................................................................... 40
7 Biller Fetch MDM Request & Response .................................................................................................................. 42

BBPS API SPECIFICATIONS | Version 14.0

Sample Request API: BBPOU to BBPCU........................................................................................................... 42

Sample Response API: BBPCU to BBPOU ........................................................................................................ 42
Biller Fetch MDM Request Tag Details ............................................................................................................ 48
Biller Fetch MDM Request XSD ....................................................................................................................... 48
Biller Fetch MDM Response Tag Details ......................................................................................................... 49
Biller Fetch MDM Response XSD ..................................................................................................................... 53
8 Agent MDM Fetch Request & Response ................................................................................................................. 56
Sample Request API: BBPOU to BBPCU........................................................................................................... 56
Sample Response API: BBPCU to BBPOU ........................................................................................................ 56
Agent MDM Fetch Request Tag Details .......................................................................................................... 58
Agent MDM Fetch Request XSD ...................................................................................................................... 58
Agent MDM Fetch Response Tag Details ........................................................................................................ 59
Agent MDM Fetch Response XSD ................................................................................................................... 60
9 Plan MDM APIs ........................................................................................................................................................ 62
Considerations for BOUs ................................................................................................................................. 62
Considerations for COUs/Participating AIs ..................................................................................................... 62
Sample Plan MDM Push Request API: Biller BBPOU to BBPCU....................................................................... 63
Sample Plan MDM Pull Request API: BBPCU to Biller BBPOU ........................................................................ 67
9.4.1 Scheduled Pull: ........................................................................................................................................ 67
9.4.2 Ad-hoc Pull: ............................................................................................................................................. 67
Sample Plan MDM Push Request API: BBPCU to Customer BBPOU / Participating AI ................................... 67
Sample Plan MDM Pull Request API: Customer BBPOU / Participating AI to BBPCU ..................................... 70
Plan MDM Push Request API Tag Details ........................................................................................................ 71
Plan MDM Push Request XSD ......................................................................................................................... 72
Plan MDM Pull Request API Tag Details .......................................................................................................... 73
Plan MDM Pull Request XSD ........................................................................................................................... 73
10 Biller Status Check/Update APIs.......................................................................................................................... 74
Sample Biller Status Update API: Biller BBPOU to BBPCU .............................................................................. 74
Sample Biller Status Update API: BBPCU to Customer BBPOUs/Participating AIs .......................................... 74
Biller Status Update API Tag Details ................................................................................................................ 74
Biller Status Update XSD ................................................................................................................................. 75
Sample Biller Activation Check Request API: BBPCU to Biller BBPOU ............................................................ 75
Sample Biller Activation Check Response API: Biller BBPOU to BBPCU .......................................................... 76
Biller Activation Check Request API Tag Details.............................................................................................. 76
Biller Activation Check Request XSD ............................................................................................................... 76
Biller Activation Check Response API Tag Details ........................................................................................... 76

BBPS API SPECIFICATIONS | Version 14.0

Biller Activation Check Response XSD ............................................................................................................. 77

Sample Biller Status Check Request API: BBPOU/Participating AI to BBPCU (Search by Biller Id) ................. 77
Sample Biller Status Check Response API: BBPCU to BBPOU/Participating AI ............................................... 78
Sample Biller Status Check Request API: BBPOU/Participating AI to BBPCU (without Search Parameter) .... 78
Biller Status Check Request API Tag Details .................................................................................................... 78
Biller Status Check Request XSD...................................................................................................................... 78
Biller Status Check Response API Tag Details.................................................................................................. 79
Biller Activation Check Response XSD ............................................................................................................. 79
11 Acknowledgment ................................................................................................................................................ 80
Sample ACK for Fetch & Payment APIs ........................................................................................................... 80
Sample ACK for Other APIs.............................................................................................................................. 80
Acknowledgment Tag Details .......................................................................................................................... 80
Acknowledgment XSD ..................................................................................................................................... 81
12 BBPS Common ..................................................................................................................................................... 81
BBPS Common XSD.......................................................................................................................................... 81
13 Key Exchange / XML signing ................................................................................................................................ 86
14 URLs for Different API Messages ......................................................................................................................... 87
Request URL format (Customer BBPOU / Participating AI to BBPCU): ........................................................... 87
Request URL format (BBPCU to Biller BBPOU): ............................................................................................... 87
Response URL format (Biller BBPOU to BBPCU): ............................................................................................ 87
Response URL format (BBPCU to Customer BBPOU / Participating AI): ......................................................... 87
Request URL format (BBPOU / Participating AI to BBPCU): ............................................................................ 88
Response URL format (BBPCU to BBPOU/Participating AI): ........................................................................... 88
15 Error Codes and Declines .................................................................................................................................... 89
BBPCU Declines ............................................................................................................................................... 89
Biller BBPOU Declines ..................................................................................................................................... 94
Customer BBPOU Declines .............................................................................................................................. 96
Forced Closure of Transactions by CU............................................................................................................. 96
16 Re-utilization of Fetch / Validation for Registered Customers ........................................................................... 98
Considerations for Customer OUs................................................................................................................... 98
Considerations for Biller OUs .......................................................................................................................... 99
17 Biller Types in BBPS ........................................................................................................................................... 100
18 Amount Block Configuration in Bill Fetch & Bill Payment Messages ................................................................ 101
19 Fee Configuration .............................................................................................................................................. 105
Interchange Fee............................................................................................................................................. 105
Interchange Fee Config ................................................................................................................................. 106

BBPS API SPECIFICATIONS | Version 14.0

20 BBPS IDs............................................................................................................................................................. 108

ID Generation Stages..................................................................................................................................... 108
Generation Logic ........................................................................................................................................... 109
21 Payment Mode & Channel Details .................................................................................................................... 110
Initiating Channel Vs Device Block Parameters............................................................................................. 110
Payment Mode Vs Payment Info Parameters ............................................................................................... 110
Initiating Channel Vs Payment Mode Combinations .................................................................................... 111
22 Settlement File Transfer Mechanism ................................................................................................................ 112
23 Elements Description ........................................................................................................................................ 113
24 Appendix ........................................................................................................................................................... 154
List of Error Messages ................................................................................................................................... 154
File Naming Convention for Settlement Files ............................................................................................... 154

BBPS API SPECIFICATIONS | Version 14.0

Document History
Date Version Prepared Reviewed Description
By By
29.12.2016 11.0 Arnab Arulananda Base version of API Specifications
Moitra Selvakumar
08.02.2018 12.0 Manoj Arulananda  Merging of API Request and Response pairs
Chekuri Selvakumar  Split of Bill Fetch and Bill Payment Request messages from Customer BBPOU to
BBPCU to Biller BBPOU
 Split of Bill Fetch and Bill Payment Response messages from Biller BBPOU to
BBPCU to Customer BBPOU
 Separate Reversal Request and Reversal Response sample messages
 Addition of Bill Validation API
 Addition of Complaint Re-assignment (502) and Complaint Closure (507) APIs
 Split of CMS API into Transaction Status (401), Compliant Raise (501), Complaint
Re-assignment (502), Complaint Status (506) and Complaint Closure (507) APIs
 Modification of Biller MDM Fetch API
 Addition of Agent MDM Fetch API
 Addition of Error Codes and Declines section
 Addition of CMS Response Scenarios section
 Addition of Biller Types in BBPS section
 Addition of Amount Block Configuration in Bill Fetch & Bill Payment Messages
section
 Addition of Fee Configuration section
 Addition of Settlement File Transfer Mechanism section
 Modification of Payment Mode & Channel Details section
- Splitting of Mobile and Internet payment channels: Mobile (Pre-login),
Mobile Banking (Post-login), Internet (Pre-login), Internet Banking (Post-
login)
- Addition of 2 payment channels: Agent and Business Correspondent
- Addition of 2 payment mode: AEPS and Account Transfer
 Modification of parameter definitions in Elements Description section
 Addition of Appendix section
05.11.2019 13.0 Manoj Arulananda  Addition of Transaction Status Check (402) API between BBPCU and Biller
Chekuri Selvakumar BBPOU to check the status of Pending Transactions
 Introduction of Fetch / Validation Re-utilization for Registered Customers
- Introduction of siTxn and origRefId attributes in Payment Request API
- Considerations for Customer and Biller BBPOUs
 Modification of Biller MDM Fetch API
- Introduction of Either/OR configuration of Customer Parameters
- Passing default(possible) values against a Customer Parameter
 Modification of BillerResponse block attributes presence in Fetch, Payment and
402 API Responses.
 Change in Transaction Reference Id length and generation logic
 Change in Customer Mobile Number length
 Addition of URLs for Different APIs section
 Modification of BBPS Error Codes and Declines
- Introduction of Deemed Success and Pending Status
- Modification of Forced Closure of Transactions by CU
 Modification of Biller Types in BBPS section
 Modification of Fee Configuration section
 Modification of Payment Mode & Channel Details section
- Addition of 2 payment modes: Bharat QR and USSD
 Modification of parameter definitions in Elements Description section

BBPS API SPECIFICATIONS | Version 14.0

20.02.2021 14.0 Manoj Arulananda  Change in BBPS IDs Generation Logic – Introduction of Julian Date in Ref ID &
Chekuri Selvakumar Msg ID
 Introduction of QR & Paylink in BBPS.
 Introduction of Biller Status APIs
 Introduction of Plan MDM APIs
 Introduction of new attribute paymentRefId in Payment Request.
 Introduction of AdditionalInfo block in Payment & 402 API Responses.
 Modification of Biller MDM Fetch Response API
- Introduction of billerAdditionalInfoPayment block to capture AdditionalInfo
configuration of Payment/402 API Response.
- Introduction of new attribute visibility under CustomerParams block against
each parameter.
- Introduction of Plan MDM Related parameters (planMdmRequirement tag &
planAdditionalInfo block).
 Inclusion of additional details in 401 API Response – New URL has been created
for 401 API, which will provide additional information of the transaction.
 Introduction of Call-back APIs for CMS module.
 Modification/Addition of parameter definitions in Elements Description section.
 Updated the documents in Appendinx section.

BBPS API SPECIFICATIONS | Version 14.0

1 Bill Fetch Request & Response

Sample Fetch Request API: Customer BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillFetchRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:35+05:30" origInst="OU01"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Analytics>
<Tag name="FETCHREQUESTSTART" value="2021-01-10T22:02:00+05:30" />
<Tag name="FETCHREQUESTEND" value="2021-01-10T22:02:35+05:30" />
</Analytics>
<Txn ts="2021-01-10T22:02:35+05:30" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"
directBillChannel="L1QR/L1PL/L2QR/L2PL" >
<RiskScores>
<Score provider="OU01" type="TXNRISK" value="030" />
<Score provider="BBPS" type="TXNRISK" value="030" />
</RiskScores>
</Txn>
<Customer mobile="9505987798">
<Tag name="EMAIL" value="manoj.chekuri@npci.org.in" />
<Tag name="AADHAAR" value="123456789012" />
<Tag name="PAN" value="BXXCG7754K" />
</Customer>
<Agent id="OU01AI34INT001123456">
<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/INTB/MOB/MOBB/KIOSK/ATM/BNKBRNCH/AGT/BSC" />
<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="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
</bbps:BillFetchRequest>

BBPS API SPECIFICATIONS | Version 14.0

Sample Fetch Request API: BBPCU to Biller BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillFetchRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:36+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Analytics>
<Tag name="FETCHREQUESTSTART" value="2021-01-10T22:02:00+05:30" />
<Tag name="FETCHREQUESTEND" value="2021-01-10T22:02:35+05:30" />
</Analytics>
<Txn ts="2021-01-10T22:02:35+05:30" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"
directBillChannel="L1QR/L1PL/L2QR/L2PL" >
<RiskScores>
<Score provider="OU01" type="TXNRISK" value="030" />
<Score provider="BBPS" type="TXNRISK" value="030" />
</RiskScores>
</Txn>
<Customer mobile="9505XXXX98">
<Tag name="EMAIL" value="manoj.chekuri@npci.org.in" />
<Tag name="AADHAAR" value="123456789012" />
<Tag name="PAN" value="BXXCG7754K" />
</Customer>
<Agent id="OU01XXXXINT001123456">
<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/INTB/MOB/MOBB/KIOSK/ATM/BNKBRNCH/AGT/BSC" />
<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="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
</bbps:BillFetchRequest>

Sample Fetch Response API: Biller BBPOU to BBPCU

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

BBPS API SPECIFICATIONS | Version 14.0

<bbps:BillFetchResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:40+05:30" origInst="OU02"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Succcesful/Failure"
complianceRespCd="BFR001" complianceReason="Incorrect / invalid customer account" />
<Txn ts="2021-01-10T22:02:35+05:30" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<BillDetails>
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2021-09-24" billDate="2021-01-02"
billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED">
<Tag name="Amount 1" value="5000" />
<Tag name="Amount 2" value="4000" />
<Tag name="Amount 3" value="3000" />
</BillerResponse>
<AdditionalInfo>
<Tag name="BlRspFld1" value="" />
<Tag name="BlRspFld2" value="" />
<Tag name="BlRspFld3" value="" />
</AdditionalInfo>
</bbps:BillFetchResponse>

Sample Fetch Response API: BBPCU to Customer BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillFetchResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:41+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Succcesful/Failure"
complianceRespCd="BFR001" complianceReason="Incorrect / invalid customer account" />
<Txn ts="2021-01-10T22:02:35+05:30" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<BillDetails>
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2021-09-24" billDate="2021-01-02"
billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED">
<Tag name="Amount 1" value="5000" />
<Tag name="Amount 2" value="4000" />
<Tag name="Amount 3" value="3000" />
</BillerResponse>
<AdditionalInfo>

BBPS API SPECIFICATIONS | Version 14.0

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

Bill Fetch Request Tag Details

Index XML Element Description 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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
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 1..1
all entities of the eco-system
4.1.1 ts Transaction initiation timestamp which will remain constant 1..1
throughout all legs of the transaction
4.1.2 msgId Unique identification assigned by the initiating BBPOU for chaining 1..1
a request and response message
4.1.3 directBillChannel Type of the transaction in case of QR/PL, i.e. L{1/2}{QR/PL} 0..1
4.2 <Txn.RiskScores> Risk evaluation associated with the transaction and the related 1..1
parties in the transaction
4.3 <Txn.RiskScores.Score> Risk score related to the transaction and the entities 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 "000" (No Risk) to "100" 1..n
(Maximum Risk) with default score being "030"
5.1 <Customer> Details of the Customer viewing / paying the bill 1..1
5.1.1 mobile Customer mobile number 1..1
5.2 <Customer.Tag> Customer related details 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 requested from Customer 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> Biller ID and bill related details to identify a Customer 1..1
7.2 <BillDetails.Biller> Biller related details 1..1
7.2.1 Id Unique identification code allocated to the Biller 1..1

BBPS API SPECIFICATIONS | Version 14.0

7.3 <BillDetails.CustomerPar Customer bill fetch related details 1..1

ams>
7.4 <BillDetails.CustomerPar Customer bill fetch related reference field tag 1..n
ams.Tag>
7.4.1 name Name of the reference field as configured for the Biller 1..n
7.4.2 value Value of the reference field which uniquely identifies the customer 1..n
for the Biller

Bill Fetch Request XSD

Bill Fetch Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:billFetchResponse> 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 timestamp of the message which will be updated at 1..1
each leg
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
3.1 <Reason> Response details of the transaction 1..1
3.1.1 approvalRefNum Internal reference number which may be used by the Biller 1..1
BBPOU for a transaction – default value "AB123456"
3.1.2 responseCode Carries the response code indicating success or failure of the 1..1
transaction
3.1.3 responseReason Description of the response code – possible values are 1..1
"Successful" or "Failure"
3.1.4 complianceRespCd Carries the compliance code indicating the reason for a failed 0..1

BBPS API SPECIFICATIONS | Version 14.0

transaction – not required for a successful transaction

3.1.5 complianceReason Description of the compliance code – not required for a 0..1
successful transaction
4.1 <Txn> Transaction information, passed throughout the system, visible 1..1
to all entities of the eco-system
4.1.1 Ts Transaction initiation timestamp which will remain constant 1..1
throughout all legs of the request and response message
4.1.2 msgId Unique identification assigned by the initiating BBPOU for 1..1
chaining a request and response message
5.1 <BillDetails> Bill related details to identify a Customer 0..1
5.2 <BillDetails.CustomerPara Customer bill fetch related details 1..1
ms>
5.3 <BillDetails.CustomerPara Customer bill fetch related reference field tag 1..n
ms.Tag>
5.3.1 name Name of the reference field as configured for the Biller 1..n
5.3.2 value Value of the reference field which uniquely identifies the 1..n
Customer for the Biller
6.1 <BillerResponse> Response which is sent by the Biller for a successful transaction, 0..1
i.e., response code is ‘000’
6.1.1 customerName Name of the Customer 0..1*
6.1.2 amount Amount of the bill 1..1
6.1.3 dueDate Due date of the bill 0..1*
6.1.4 billDate Generation date of the bill 0..1*
6.1.5 billNumber Unique identifier of the bill 0..1*
6.1.6 billPeriod Billing period of the bill 0..1*
6.2 <BillerResponse.Tag> Biller response related tag indicating the various amount options 0..n
provided by the Biller
6.2.1 name Name of the amount field assigned by the Biller 1..n
6.2.2 value Value of the amount field 1..n
7.1 <AdditionalInfo> Additional information parameters provided by the Biller for a 0..1
successful transaction, i.e., response code is ‘000’
7.2 <AdditionalInfo.Tag> Tag indicating any additional information provided by the Biller 1..n
7.2.1 name Name of the field assigned by the Biller 1..n
7.2.2 value Value of the field 1..n
*For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid and Electricity all the attributes are MANDATORY, for
others only "amount" is MANDATORY.

Bill Fetch Response XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:element type="bbps:additionalInfoType" name="AdditionalInfo" minOccurs="0" maxOccurs="1" />

</xs:sequence>
</xs:complexType>
</xs:schema>

2 Bill Payment Request & Response

Sample Payment Request API: Customer BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU01" siTxn="Yes/No"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" origRefId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Analytics>
<Tag name="PAYREQUESTSTART" value="2021-01-10T22:02:00+05:30" />
<Tag name="PAYREQUESTEND" value="2021-01-10T22:02:45+05:30" />
</Analytics>
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="FORWARD TYPE
REQUEST" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"
directBillChannel="L1QR/L1PL/L2QR/L2PL/L3QR/L3PL" directBillContentId="21010ABCDXXXX0001"
paymentRefId="ABCD1234abcd" >
<RiskScores>
<Score provider="OU01" type="TXNRISK" value="030" />
<Score provider="BBPS" type="TXNRISK" value="030" />
</RiskScores>
</Txn>
<Customer mobile="9505987798">
<Tag name="EMAIL" value="manoj.chekuri@npci.org.in" />
<Tag name="AADHAAR" value="123456789012" />
<Tag name="PAN" value="BXXCG7754K" />
</Customer>
<Agent id="OU01AI34INT001123456">
<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/INTB/MOB/MOBB/KIOSK/ATM/BNKBRNCH/AGT/BSC" />
<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="XX1234ABCD" />

BBPS API SPECIFICATIONS | Version 14.0

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

Sample Payment Request API: BBPCU to Biller BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:46+05:30" origInst="BBCU" siTxn="Yes/No"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" origRefId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Analytics>
<Tag name="PAYREQUESTSTART" value="2021-01-10T22:02:00+05:30" />
<Tag name="PAYREQUESTEND" value="2021-01-10T22:02:45+05:30" />
</Analytics>
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="FORWARD TYPE
REQUEST" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"

BBPS API SPECIFICATIONS | Version 14.0

directBillChannel="L1QR/L1PL/L2QR/L2PL/L3QR/L3PL" directBillContentId="21010ABCDXXXX0001"
paymentRefId="ABCD1234abcd" >
<RiskScores>
<Score provider="OU01" type="TXNRISK" value="030" />
<Score provider="BBPS" type="TXNRISK" value="030" />
</RiskScores>
</Txn>
<Customer mobile="9505XXXX98">
<Tag name="EMAIL" value="manoj.chekuri@npci.org.in" />
<Tag name="AADHAAR" value="123456789012" />
<Tag name="PAN" value="BXXCG7754K" />
</Customer>
<Agent id="OU01XXXXINT001123456">
<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/INTB/MOB/MOBB/KIOSK/ATM/BNKBRNCH/AGT/BSC" />
<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="MK1234ABCD" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2021-09-24" billDate="2021-01-02"
billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED">
<Tag name="Amount 1" value="5000" />
<Tag name="Amount 2" value="4000" />
<Tag name="Amount 3" value="3000" />
</BillerResponse>
<AdditionalInfo>
<Tag name="BlRspFld1" value="" />
<Tag name="BlRspFld2" value="" />
<Tag name="BlRspFld3" value="" />
</AdditionalInfo>
<PaymentMethod quickPay="Yes/No" splitPay="Yes/No" OFFUSPay="Yes/No" paymentMode="Internet
Banking/Debit Card/Credit Card/IMPS/Cash/UPI/Wallet/NEFT/Prepaid Card/AEPS/Account Transfer/Bharat
QR/USSD" />
<Amount>

BBPS API SPECIFICATIONS | Version 14.0

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

Sample Payment Response API: Biller BBPOU to BBPCU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:50+05:30" origInst="OU02"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Succcesful/Failure"
complianceRespCd="BPR001" complianceReason="Incorrect / invalid customer account" />
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="FORWARD TYPE
RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<BillDetails>
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2021-09-24" custConvFee="1000"
billDate="2021-01-02" billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED" />
<AdditionalInfo>
<Tag name="PaymentBlRspFld1" value="" />
<Tag name="PaymentBlRspFld2" value="" />
<Tag name="PaymentBlRspFld3" value="" />
</AdditionalInfo>
</bbps:BillPaymentResponse>

Sample Payment Response API: BBPCU to Customer BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:51+05:30" origInst="BBCU" siTxn="Yes/No"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" origRefId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Succcesful/Failure"
complianceRespCd="BPR001" complianceReason="Incorrect / invalid customer account" />
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="FORWARD TYPE
RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<BillDetails>
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />

BBPS API SPECIFICATIONS | Version 14.0

</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2021-09-24" custConvFee="1000"
billDate="2021-01-02" billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED" />
<AdditionalInfo>
<Tag name="PaymentBlRspFld1" value="" />
<Tag name="PaymentBlRspFld2" value="" />
<Tag name="PaymentBlRspFld3" value="" />
</AdditionalInfo>
</bbps:BillPaymentResponse>

Sample Reversal Request API: BBPCU to Biller BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:55+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202"/>
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="REVERSAL TYPE
REQUEST" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
</bbps:BillPaymentRequest>

Sample Reversal Response API: Biller BBPOU to BBPCU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:58+05:30" origInst="OU02"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="103" responseReason="Failure" complianceRespCd=""
complianceReason="" />
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="REVERSAL TYPE
RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
</bbps:BillPaymentResponse>

Sample Reversal Response API: BBPCU to Customer BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillPaymentResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:58+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="103" responseReason="Failure"
complianceRespCd="COU001" complianceReason="Send Failed to COU" />
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="REVERSAL TYPE
RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" />
</bbps:BillPaymentResponse>

Bill Payment Request Tag Details

Index XML Element Description Occurrence

BBPS API SPECIFICATIONS | Version 14.0

1.1 <bbps:BillPaymentReque API Name 1..1

st>
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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
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 1..1
all entities of the eco-system
4.1.1 ts Transaction initiation timestamp which will remain constant 1..1
throughout all legs of the transaction
4.1.2 msgId Unique identification assigned by the initiating BBPOU for chaining 1..1
a request and response message
4.1.3 type Type of the message (Forward or Reversal Type) 1..1
4.1.4 txnReferenceId Transaction reference number used by the Customer for referring 1..1
to a Payment transaction
4.1.5 directBillChannel Type of the transaction in case of QR/PL, i.e. L{1/2}{QR/PL} 0..1
4.1.6 directBillContentId Unique ID pertaining to the QR/PL 0..1
4.1.7 paymentRefId Unique ID generated at the time of Payment Confirmaton, such as 0..1
PG Reference Number, RRN, etc..
4.2 <Txn.RiskScores> Risk evaluation associated with the transaction and the related 1..1
parties in the transaction
4.3 <Txn.RiskScores.Score> Risk score related to the transaction and the entities 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 "000" (No Risk) to "100" 1..n
(Maximum Risk) with default score being "030"
5.1 <Customer> Details of the Customer viewing / paying the bill 1..1
5.1.1 mobile Customer mobile number 1..1
5.2 <Customer.Tag> Customer related details 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 requested from Customer 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> Biller ID and bill related details to identify a Customer 1..1
7.2 <BillDetails.Biller> Biller related details 1..1
7.2.1 id Unique identification code allocated to the Biller 1..1
7.3 <BillDetails.CustomerPar Customer bill fetch related details 1..1
ams>
7.4 <BillDetails.CustomerPar Customer bill fetch related reference field tag 1..n
ams.Tag>

BBPS API SPECIFICATIONS | Version 14.0

7.4.1 name Name of the reference field as configured for the Biller 1..n
7.4.2 value Value of the reference field which uniquely identifies the customer 1..n
for the Biller
7.4.3 enc_RefFld1 Tag which captures encrypted values of the masked tag, in case of 0..1
L3{QR/PL}.
8.1 <BillerResponse> Biller response parameters sent by the Biller supporting fetch is 0..1
copied in the payment request "as-is" – not applicable for payment
only Billers
8.1.1 customerName Name of the customer 0..1*
8.1.2 amount Amount of the bill 1..1
8.1.3 dueDate Due date of the bill 0..1*
8.1.4 billDate Generation date of the bill 0..1*
8.1.5 billNumber Unique identifier of the bill 0..1*
8.1.6 billPeriod Billing period of the bill 0..1*
8.2 <BillerResponse.Tag> Biller response related tag indicating the various amount options 0..n
provided by the Biller
8.2.1 name Name of the amount field assigned by the Biller 1..n
8.2.2 value Value of the amount field 1..n
9.1 <AdditionalInfo> Additional information parameters sent by the Biller supporting 0..1
fetch is copied in the payment request "as-is" – not applicable for
payment only Billers
9.2 <AdditionalInfo.Tag> Tag indicating any additional information provided by the Biller 1..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 <PaymentMethod> Payment method opted by the Customer 1..1
10.1.1 quickPay Flag indicating if the payment is initiated without a fetch or not 1..1
10.1.2 splitPay Flag indicating if the bill is paid using two different payment modes 1..1
10.1.3 OFFUSPay Flag indicating if it is an electronic ON-US or OFF-US transaction 1..1
10.1.4 paymentMode The payment mode which is accepted from the Customer 1..1
11.1 <Amount> Amount related details for the payment 1..1
11.2 <Amount.Amt> Details of the bill payment amount made by the Customer 1..1
11.2.1 amount Actual amount paid by the Customer for the transaction 1..1
11.2.2 custConvFee Customer convenience fee (CCF1) paid by the Customer BBPOU to 1..1
Biller BBPOU
11.2.3 COUcustConvFee Customer convenience fee (CCF2) paid by the Customer to 1..1
Customer BBPOU
11.2.4 currency Currency code of the transaction 1..1
11.3 <Amount.SplitPayAmoun Amount paid through the second payment mode 0..1
t>
11.4 <Amount.Tag> Amount paid by the customer indicating different amount option 0..n
combinations
11.4.1 name Name of the amount field assigned by the Biller 1..n
11.4.2 value Value of the amount field 1..n
12.1 <PaymentInformation> Payment information of the instrument which is used for making 1..1
the bill payment (this block is not passed by BBPCU to Biller
BBPOU)
12.2 <PaymentInformation.Ta Payment instrument details which is used for the bill payment 1..n
g> transaction
12.2.1 name Name of the parameter for the chosen payment instrument 1..n
12.2.2 value Value of the parameter for the chosen payment instrument 1..n
*For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid and Electricity all the attributes are MANDATORY, for
others only "amount" is MANDATORY.

BBPS API SPECIFICATIONS | Version 14.0

Bill Payment Request XSD

Bill Payment Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillPaymentRespo API Name 1..1
nse>
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 timestamp of the message which will be updated at each leg 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
3.1 <Reason> Response details of the transaction 1..1
3.1.1 approvalRefNum Internal reference number which may be used by the Biller BBPOU for 1..1
a transaction – default value "AB123456"
3.1.2 responseCode Carries the response code indicating success or failure of the 1..1
transaction
3.1.3 responseReason Description of the response code – possible values are "Successful" or 1..1
"Failure"
3.1.4 complianceRespCd Carries the compliance code indicating the reason for a failed 0..1
transaction – not required for a successful transaction
3.1.5 complianceReason Description of the compliance code – not required for a successful 0..1
transaction
4.1 <Txn> Transaction information, passed throughout the system, visible to all 1..1

BBPS API SPECIFICATIONS | Version 14.0

entities of the eco-system

4.1.1 ts Transaction initiation timestamp which will remain constant 1..1
throughout all legs of the request and response message
4.1.2 msgId Unique identification assigned by the initiating BBPOU for chaining a 1..1
request and response message
5.1 <BillDetails> Bill related details to identify a Customer 0..1
5.2 <BillDetails.CustomerPar Customer bill payment related details 1..1
ams>
5.3 <BillDetails.CustomerPar Customer bill payment related reference field tag 1..n
ams.Tag>
5.3.1 name Name of the reference field as configured for the Biller 1..n
5.3.2 value Value of the reference field which uniquely identifies the Customer 1..n
for the Biller
6.1 <BillerResponse> Response which is sent by the Biller for a successful transaction, i.e., 0..1
response code is ‘000’
6.1.1 customerName Name of the Customer 0..1*
6.1.2 amount Amount of the bill – should match with the "amount" attribute value 1..1
passed in the Payment request
6.1.3 dueDate Due date of the bill 0..1*
6.1.4 billDate Generation date of the bill 0..1*
6.1.5 billNumber Unique identifier of the bill 0..1*
6.1.6 billPeriod Billing period of the bill 0..1*
6.1.7 custConvFee Customer convenience fee paid by the Customer BBPOU to Biller 0..1*
BBPOU – should match with the CCF1 value in the Payment request
7.1 <AdditionalInfo> Additional information parameters provided by the Biller for a 0..1
successful transaction, i.e., response code is ‘000’
7.2 <AdditionalInfo.Tag> Tag indicating any additional information provided by the Biller 1..n
7.2.1 name Name of the field assigned by the Biller 1..n
7.2.2 value Value of the field 1..n
*For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid and Electricity all the attributes are MANDATORY, for
others only "amount" is MANDATORY.

Bill Payment Response XSD

BBPS API SPECIFICATIONS | Version 14.0

3 Transaction Status Check (402) API Request

& Response (for Pending Transactions)
402 API Request: BBPCU to Biller BBPOU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:58+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Txn ts="2021-01-10T22:02:45+05:30" xchangeId="402" />
<TxnStatusReq msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"
txnReferenceId="OU011010ABCD12345678" />
</bbps:TxnStatusRequest>

402 API Response: Biller BBPOU to BBPCU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:58+05:30" origInst="OU02"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Succcesful/Failure"
complianceRespCd="BPR001" complianceReason="Incorrect / invalid customer account" />
<Txn txnReferenceId="OU011010ABCD12345678" ts="2021-01-10T22:02:45+05:30" type="FORWARD TYPE
RESPONSE" msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" xchangeId="402" />
<BillDetails>
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
</CustomerParams>
</BillDetails>
<BillerResponse customerName="Manoj Chekuri" amount="120000" dueDate="2019-09-24" custConvFee="1000"
billDate="2019-01-22" billNumber="1232332"
billPeriod="ONETIME|DAILY|WEEKLY|BIMONTHLY|MONTHLY|QUARTERLY|HALFYEARLY|YEARLY|ASPRESENTED" />
<AdditionalInfo>
<Tag name="PaymentBlRspFld1" value="" />
<Tag name="PaymentBlRspFld2" value="" />
<Tag name="PaymentBlRspFld3" value="" />
</AdditionalInfo>
</bbps:TxnStatusResponse>

402 API Request Tag Details

Index XML Element Description Occurrence
1.1 <bbps:TxnStatusRequest API Name 1..1
>
1.1.1 Xmlns API schema namespace 1..1
2.1 <Head> Header of the message 1..1

BBPS API SPECIFICATIONS | Version 14.0

2.1.1 Ver Version of the API 1..1

2.1.2 ts Creation timestamp of the message which will be updated at each 1..1
leg
2.1.3 origInst Code assigned to the BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Validation and Payment messages
3.1 <Txn> Transaction information, passed throughout the system, visible to 1..1
all entities of the eco-system
3.1.1 ts Transmission date and time of the transaction 1..1
3.1.2 xchangeId Identification of the type of the request – transaction status (402) 1..1
4.1 <TxnStatusReq> Information pertaining to transaction status request 1..1
4.1.1 msgId Unique identification assigned by the initiating BBPOU for chaining 1..1
a request and response message
4.1.4 txnReferenceId Transaction reference number used by the Customer for referring 0..1
to a Payment transaction

402 API Request XSD

402 API Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:TxnStatusResponse> 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 timestamp of the message which will be updated at each leg 1..1

BBPS API SPECIFICATIONS | Version 14.0

2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to unambiguously 1..1
identify the transaction which is passed on, unchanged, throughout the
entire end-to-end chain, binding the Fetch and Payment messages
3.1 <Reason> Response details of the transaction 1..1
3.1.1 approvalRefNum Internal reference number which may be used by the Biller BBPOU for a 1..1
transaction – default value "AB123456"
3.1.2 responseCode Carries the response code indicating success or failure of the transaction 1..1
3.1.3 responseReason Description of the response code – possible values are "Successful" or 1..1
"Failure"
3.1.4 complianceRespCd Carries the compliance code indicating the reason for a failed 0..1
transaction – not required for a successful transaction
3.1.5 complianceReason Description of the compliance code – not required for a successful 0..1
transaction
4.1 <Txn> Transaction information, passed throughout the system, visible to all 1..1
entities of the eco-system
4.1.1 ts Transaction initiation timestamp which will remain constant throughout 1..1
all legs of the request and response message
4.1.2 msgId Unique identification assigned by the initiating BBPOU for chaining a 1..1
request and response message
4.1.3 xchangeId Identification of the type of the response – transaction status (402) 0..1
5.1 <BillDetails> Bill related details to identify a Customer 0..1
5.2 <BillDetails.CustomerParam Customer bill payment related details 1..1
s>
5.3 <BillDetails.CustomerParam Customer bill payment related reference field tag 1..n
s.Tag>
5.3.1 Name Name of the reference field as configured for the Biller 1..n
5.3.2 Value Value of the reference field which uniquely identifies the Customer for 1..n
the Biller
6.1 <BillerResponse> Response which is sent by the Biller for a successful transaction, i.e., 0..1
response code is ‘000’
6.1.1 customerName Name of the Customer 0..1*
6.1.2 amount Amount of the bill – should match with the "amount" attribute value 1..1
passed in the Payment request
6.1.3 dueDate Due date of the bill 0..1*
6.1.4 billDate Generation date of the bill 0..1*
6.1.5 billNumber Unique identifier of the bill 0..1*
6.1.6 billPeriod Billing period of the bill 0..1*
6.1.7 custConvFee Customer convenience fee paid by the Customer BBPOU to Biller BBPOU 0..1*
– should match with the CCF1 value in the Payment request
7.1 <AdditionalInfo> Additional information parameters provided by the Biller for a successful 0..1
transaction, i.e., response code is ‘000’
7.2 <AdditionalInfo.Tag> Tag indicating any additional information provided by the Biller 1..n
7.2.1 name Name of the field assigned by the Biller 1..n
7.2.2 value Value of the field 1..n
*For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid and Electricity all the attributes are MANDATORY, for others
only "amount" is MANDATORY.

402 API Response XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:annotation>
<xs:documentation>402 API Response</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="TxnStatusResponse">
<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>

4 Bill Validation Request & Response

Sample Validation Request API: Customer BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:BillValidationRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU01"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Agent id="OU01AI34INT001123456" />
<BillDetails>
<Biller id="VODAGSM00MUM03" />
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>
</bbps:BillValidationRequest>

Sample Validation Request API: BBPCU to Biller BBPOU

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:BillValidationRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Agent id="OU01XXXXINT001123456" />
<BillDetails>
<Biller id="VODAGSM00MUM03" />
<CustomerParams>
<Tag name="RefFld1" value="" />
<Tag name="RefFld2" value="" />
<Tag name="RefFld3" value="" />
</CustomerParams>
</BillDetails>

BBPS API SPECIFICATIONS | Version 14.0

</bbps:BillValidationRequest>

Sample Validation Response API: Biller BBPOU to BBPCU

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:BillValidationResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU02"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Successful/Failure"
complianceRespCd="BVR001" complianceReason=" Incorrect / invalid customer account" />
<AdditionalInfo>
<Tag name="BlRspFld1" value="" />
<Tag name="BlRspFld2" value="" />
<Tag name="BlRspFld3" value="" />
</AdditionalInfo>
</bbps:BillValidationResponse>

Sample Validation Response API: BBPCU to Customer

BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:BillValidationResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Reason approvalRefNum="AB123456" responseCode="000/200" responseReason="Successful/Failure"
complianceRespCd="BVR001" complianceReason=" Incorrect / invalid customer account" />
<AdditionalInfo>
<Tag name="BlRspFld1" value="" />
<Tag name="BlRspFld2" value="" />
<Tag name="BlRspFld3" value="" />
</AdditionalInfo>
</bbps:BillValidationResponse>

Bill Validation Request Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillValidationRequ API Name 1..1
est>
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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Validation and Payment messages
3.1 <Agent> Agent related data 1..1

BBPS API SPECIFICATIONS | Version 14.0

3.1.1 Id Unique identification code allocated to the Agent 1..1

4.1 <BillDetails> Biller ID and bill related details to identify a Customer 1..1
4.2 <BillDetails.Biller> Biller related details 1..1
4.2.1 Id Unique identification code allocated to the Biller 1..1
4.3 <BillDetails.CustomerPar Customer bill validation related details 1..1
ams>
4.4 <BillDetails.CustomerPar Customer bill validation related reference field tag 1..n
ams.Tag>
4.4.1 name Name of the reference field as configured for the Biller 1..n
4.4.2 value Value of the reference field which uniquely identifies the customer 1..n
for the Biller

Bill Validation Request XSD

Bill Validation Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillValidationResp API Name 1..1
onse>
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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
3.1 <Reason> Response details of the transaction 1..1
3.1.1 approvalRefNum Internal reference number which may be used by the Biller BBPOU 1..1
for a transaction – default value "AB123456"
3.1.2 responseCode Carries the response code indicating success or failure of the 1..1
transaction

BBPS API SPECIFICATIONS | Version 14.0

3.1.3 responseReason Description of the response code – possible values are "Successful" 1..1
or "Failure"
3.1.4 complianceRespCd Carries the compliance code indicating the reason for a failed 0..1
transaction – not required for a successful transaction
5.1.5 complianceReason Description of the compliance code – not required for a successful 0..1
transaction
6.1 <AdditionalInfo> Validation response parameters sent by the Biller for a successful 0..1
transaction, i.e., response code is ‘000’
6.2 <AdditionalInfo.Tag> Additional Information related tag indicating the validation 1..n
identifier provided by the Biller
6.2.1 name Name of the field assigned by the Biller 1..n
6.2.2 value Value of the field 1..n

Bill Validation Response XSD

5 Diagnostic Request & Response

Sample Request API: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:ReqDiagnostic xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU01"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
</bbps:ReqDiagnostic>

Sample Response API: BBPCU to BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:ResDiagnostic xmlns:bbps="http://bbps.org/schema" responseReason="Successful/Failure">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<errorMessages>
<errorCd>HED030</errorCd>

BBPS API SPECIFICATIONS | Version 14.0

<errorDtl>Head Timestamp gap between BBPCU and OU is more than acceptable tolerance.</errorDtl>
</errorMessages>
</bbps:ResDiagnostic>

Diagnostic Request Tag Details

Index XML Element Description Occurrence
1.1 <bbps:ReqDiagnostic> 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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain

Diagnostic Request XSD

Diagnostic Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:ResDiagnostic> 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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <errorMessages> Error messages in the API message 0..1
3.2 <errorMessages.errorCd Error Code for API message 1..n
>

BBPS API SPECIFICATIONS | Version 14.0

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

Diagnostic Response XSD

6 Transaction Status and Complaint Related

API Request & Response
In the existing system, whenever BBPOU register/reassigns the complaint, BBPCU system provides the confirmation
to the respective initiator BBPOU only, the opponent BBPOU is required to check the CANVAS for the complaints
allocated to him. It is required to modify the APIs so that the opponent BBPOU gets the message of the reassignment
along with the initiated BBPOU. This will enable the OUs to know of status of the complaint and address the same on
any interface used by it (other than the CANVAS). Similarly, any reassigned complaints closed by opponent OU must
be intimated to initiated OU in real-time basis through the APIs. Any complaints reassigned to either Customer
BBPOU / Biller BBPOU by NPCI on account of TAT missed must be intimated to the COU/ BOU through the APIs.

The basic idea here is to proactively intimate the OUs about any status change arising out to assignment,
reassignment, closure without having them to depend on the CANVAS access.

Sample Transaction Status (401) Request API – Using

Mobile Number & Date Range: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU01"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Txn ts="2021-01-10T22:02:45+05:30" xchangeId="401" />
<TxnStatusComplainReq msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" mobile="9123456001"
complaintType="Transaction" />
<TxnSearchDateCriteria fromDate="2021-01-09" toDate="2021-01-10" />
</bbps:TxnStatusComplainRequest>

BBPS API SPECIFICATIONS | Version 14.0

Sample Transaction Status (401) Response API (new URL) –

Using Mobile Number & Date Range: BBPCU to BBPOU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Txn ts="2021-01-10T22:02:45+05:30" xchangeId="401" />
<TxnStatusComplainResp msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" responseCode="000"
responseReason="SUCCESS">
<TxnList>
<TxnDetail agentId="OU01XXXXINT001123456" billerId="ONNSTNS00NAT01" approvalRefNum="AB12345001"
txnReferenceId="OU011010XTZVU2DAW9SO" mti="PAYMENT" txnDate="2021-01-10T17:19:53+05:30"
amount="100000" txnStatus="SUCCESS" complianceRespCd="" complianceReason=""
disputeId="OU012021021027717238" disputeDate="2021-02-10 14:36:44.436" disputeType="REFUND"
disputeStatus="ACCEPTED" disputeAmount="-100000" caId="" caDate="" caStatus="" caAmount="" caPenalty=""
paymentRefId="OU011010PUDQS23GR8MM70T7Z9E71L14JH3XBTVJ0RO"/>
<TxnDetail agentId="OU01XXXXINT001123456" billerId="ONNSTNS00NAT01" approvalRefNum="AB12345002"
txnReferenceId="OU011010XTZVU2DAW9SP" mti="PAYMENT" txnDate="2021-01-10T17:19:54+05:30"
amount="100000" txnStatus="SUCCESS" complianceRespCd="" complianceReason="" disputeId="" disputeDate=""
disputeType="" disputeStatus="" disputeAmount="" caId="OU012021021027717239" caDate="2021-02-10
14:36:44.436" caStatus="ACCEPTED " caAmount="100000" caPenalty=""
paymentRefId="OU011010PUDQS23GR8MM70T7Z9E71L14JH3XBTVJ0RO"/>
</TxnList>
<CustomerDetails mobile="9123456001" />
</TxnStatusComplainResp>
</bbps:TxnStatusComplainResponse>

Sample Transaction Status (401) Response API (old URL) –

BBPS API SPECIFICATIONS | Version 14.0

Sample Transaction Status (401) Request API – Using

Transaction Ref ID: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="OU01"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Txn ts="2021-01-10T22:02:45+05:30" xchangeId="401" />
<TxnStatusComplainReq msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202"
txnReferenceId="OU011010ABCD12345601" complaintType="Transaction" />
</bbps:TxnStatusComplainRequest>

Sample Transaction Status (401) Response API (new URL) –

Using Transaction Ref ID: BBPCU to BBPOU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-01-10T22:02:45+05:30" origInst="BBCU"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10102202" />
<Txn ts="2021-01-10T22:02:45+05:30" xchangeId="401" />
<TxnStatusComplainResp msgId="8ENSVVR4QOS7X1UGPY7JGUV444P10102202" responseCode="000"
responseReason="SUCCESS">
<TxnList>
<TxnDetail agentId="OU01XXXXINT001123456" billerId="ONNSTNS00NAT01" approvalRefNum="AB12345001"
txnReferenceId="OU011010XTZVU2DAW9SO" mti="PAYMENT" txnDate="2021-01-10T17:19:53+05:30"
amount="100000" txnStatus="SUCCESS" complianceRespCd="" complianceReason=""
disputeId="OU012021021027717238" disputeDate="2021-02-10 14:36:44.436" disputeType="REFUND"
disputeStatus="ACCEPTED" disputeAmount="-100000" caId="" caDate="" caStatus="" caAmount="" caPenalty=""
paymentRefId="OU011010PUDQS23GR8MM70T7Z9E71L14JH3XBTVJ0RO"/>
<CustomerDetails mobile="9123456079" />
</TxnStatusComplainResp>
</bbps:TxnStatusComplainResponse>

Sample Transaction Status (401) Response API (old URL) –

BBPS API SPECIFICATIONS | Version 14.0

<CustomerDetails mobile="9123456079" />

</TxnStatusComplainResp>
</bbps:TxnStatusComplainResponse>

Sample Complaint Raise (501) Request API – Transaction

Based: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T16:42:33+05:30" origInst="OP01"
refId="JPMRPBOGGDTP1EFRZVXVESQVQIS10461642" />
<Txn ts="2021-02-15T16:42:33+05:30" xchangeId="501"/>
<TxnStatusComplainReq msgId="IFLYRHTMDU1PSRQPGWBKLEGISDD10461642"
txnReferenceId="OP011034EYE7A8Z1T7FU"
disposition="Transaction Successful, account not updated"
description="Test Transaction Based Complaint" complaintType="Transaction"></TxnStatusComplainReq>
</bbps:TxnStatusComplainRequest>

Sample Complaint Raise (501) Response API – Transaction

Based: BBPCU to BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T16:42:33+05:30" origInst="BBCU"
refId="JPMRPBOGGDTP1EFRZVXVESQVQIS10461642" />
<Txn ts="2021-02-15T16:42:33+05:30" xchangeId="501"/>
<TxnStatusComplainResp msgId="IFLYRHTMDU1PSRQPGWBKLEGISDD10461642"
complaintId="OP0121046567755" openComplaint="N"
assigned="OP Zero One" responseCode="000" responseReason="SUCCESS"/>
</bbps:TxnStatusComplainResponse>

Sample Transaction Based Complaint Re-assignment (502)

Request API: Customer BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T16:54:14+05:30" origInst="OP01"
refId="EAVXXUJXYL1SXDGRCAVSRFALKGC10461654" />
<Txn ts="2021-02-15T16:54:14+05:30" xchangeId="502"/>
<TxnStatusComplainReq msgId="RRZOLTDAVXTNVKJOLVCFQ1KHAZU10461654" complaintId="OP0121046567755"
description="Test Transaction Based Complaint" complaintType="Transaction"></TxnStatusComplainReq>
</bbps:TxnStatusComplainRequest>

BBPS API SPECIFICATIONS | Version 14.0

Sample Transaction Based Complaint Re-assignment (502)

Response API: BBPCU to Customer BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T16:54:36+05:30" origInst="BBCU"
refId="EAVXXUJXYL1SXDGRCAVSRFALKGC10461654"/>
<Txn ts="2021-02-15T16:54:36+05:30" xchangeId="502"/>
<TxnStatusComplainResp complaintId="OP0121046567755" complaintStatus="RE_ASSIGNED"
responseCode="000" responseReason="SUCCESS"/>
</bbps:TxnStatusComplainResponse>

Sample Complaint Status (506) Request API: BBPOU to

BBPCU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:00:19+05:30" origInst="OP01"
refId="LAGVWJESBJET1GQCTMXPDARZGYD10461700" />
<Txn ts="2021-02-15T17:00:19+05:30" xchangeId="506"/>
<TxnStatusComplainReq msgId="YMHLIELQKQCKFZLJTXQHMD1NGMV10461700" complaintId="OP0121046567755"
complaintType="Transaction"></TxnStatusComplainReq>
</bbps:TxnStatusComplainRequest>

Sample Complaint Status (506) Response API: BBPCU to

BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:00:19+05:30" origInst="BBCU"
refId="LAGVWJESBJET1GQCTMXPDARZGYD10461700" />
<Txn ts="2021-02-15T17:00:19+05:30" xchangeId="506"/>
<TxnStatusComplainResp msgId="YMHLIELQKQCKFZLJTXQHMD1NGMV10461700" complaintId="OP0121046567755"
complaintStatus="RE_ASSIGNED" assigned="OP Two Two" responseCode="000" responseReason="SUCCESS"
remarks="Test Transaction Based Complaint"/>
</bbps:TxnStatusComplainResponse>

Sample Complaint Closure (507) Request API: BBPOU to

BBPS API SPECIFICATIONS | Version 14.0

description="Test Transaction Based Complaint" complaintType="Transaction"></TxnStatusComplainReq>

</bbps:TxnStatusComplainRequest>

Sample Complaint Closure (507) Response API: BBPCU to

BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:07:45+05:30" origInst="BBCU"
refId="KDANXPKLRCG1VBCWUJTKVNKGFSH10461707"/>
<Txn ts="2021-02-15T17:07:45+05:30" xchangeId="507"/>
<TxnStatusComplainResp complaintId="OP0121046567755" complaintStatus="RESOLVED" responseCode="000"
responseReason="SUCCESS"/>
</bbps:TxnStatusComplainResponse>

Sample Complaint Re-Open (503) Request API: BBPOU to

BBPCU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:13:46+05:30" origInst="OP01"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713"/>
<Txn ts="2021-02-15T17:13:46+05:30" xchangeId="503"/>
<TxnStatusComplainReq msgId="ZULMRLMMVKHEZMZBRURLHRSJQSC10461713"
txnReferenceId="OP011034EYE7A8Z1T7FU" disposition="Others, provide details in description" description="The
customer has done successful transaction one time, but the amount has deducted multiple times from customer's
account" complaintType="Transaction"></TxnStatusComplainReq>
</bbps:TxnStatusComplainRequest>

Sample Complaint Re-Open (503) Response API: BBPCU to

BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:14:06+05:30" origInst="BBCU"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713"/>
<Txn ts="2021-02-15T17:14:06+05:30" xchangeId="503"/>
<TxnStatusComplainResp msgId="ZULMRLMMVKHEZMZBRURLHRSJQSC10461713"
complaintId="OP0121046567755" reopenComplaint="N" complaintStatus="REOPEN" assigned="OP Two Two"
responseCode="000" responseReason="SUCCESS"/>
</bbps:TxnStatusComplainResponse>

BBPS API SPECIFICATIONS | Version 14.0

Sample Complaint Status Change (508) Alert API: BBPCU to

BBPOU
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<bbps:TxnStatusComplainRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-07T23:51:00+05:30" origInst="BBCU"
refId="BRTDGQ4KDPGQAS2AIUCXUTDQGVHA3ZVTBFB"/>
<Txn ts="2021-02-07T23:51:00+05:30" xchangeId="508"/>
<TxnStatusComplainReq msgId="BBPB80F6EF022B14EF5879245C7013CC744" complaintId="OU3321038827095"
complaintType="Transaction" complaintStatus="ESCALATED" assigned="OU Four Four" superLevelEsc="False"
estimatedTAT="2021-02-08T01:48:07.095+05:30" reopenComplaint="N"/>
</bbps:TxnStatusComplainRequest>

Transaction Status and Complaint Related API Request Tag

Details
Index XML Element Description Occurrence
1.1 <bbps:TxnStatusComplai API Name 1..1
nRequest>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Txn> Transaction information, passed throughout the system, visible to 1..1
all entities of the eco-system
3.1.1 ts Transmission date and time of the transaction 1..1
3.1.2 xchangeId Identification of the type of the request – transaction status (401), 1..1
complaint registration (501), complaint re-assignment (502),
complaint status (506) or complaint closure (507)
4.1 <TxnStatusComplainReq Information pertaining to transaction status and complaint related 1..1
> requests
4.1.1 msgId Unique identification assigned by the initiating BBPOU for chaining 1..1
a request and response message
4.1.2 complaintType Type of request – Transaction or Service based 1..1
4.1.3 mobile Mobile number against which the transaction status is to be 0..1
searched
4.1.4 txnReferenceId Transaction reference number used by the Customer for referring 0..1
to a Payment transaction
4.1.5 complaintId Complaint ID generated by BBPCU to check the complaint status, 0..1
re-assign or close a complaint subsequently
4.1.6 disposition Pre-defined list of dispositions for transaction based complaints 0..1
4.1.7 servReason Pre-defined list of dispositions for service based complaints 0..1
4.1.8 description Free text to provide additional information pertaining to the 0..1
complaint
4.1.9 participationType Entity type for the service based complaints (AGENT / BILLER) 0..1
4.1.10 agentId Unique identifier (Agent ID in BBPS) allocated to the Agent for 0..1

BBPS API SPECIFICATIONS | Version 14.0

service based complaints

4.1.11 billerId Unique identifier (Biller ID in BBPS) allocated to the Biller for 0..1
service based complaints
4.1.12 complaintStatus Status of the Complaint 0..1
4.1.13 assigned BBPOU Name to which the complaint is assigned 0..1
4.1.14 superLevelEsc Flag to identify whether complaint was in Super Escalation 0..1
4.1.15 estimatedTAT Estimiated time of complaint closure 0..1
4.1.16 reopenComplaint Flag to identify whether the complaint was Re-Opened 0..1
5.1 <TxnSearchDateCriteria> Searching the transaction details on the basis of mobile number 0..1
and date range – optional tag which helps in filtering the search
process
5.1.1 fromDate Start date for transaction search 1..1
5.1.2 toDate End date for transaction search 1..1

Transaction Status and Complaint Related API 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="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:element type="bbps:TxnSearchDateCriteria" name="TxnSearchDateCriteria" minOccurs="0" 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:attribute type="xs:string" name="complaintStatus" use="optional" />
<xs:attribute type="xs:string" name="assigned" use="optional" />
<xs:attribute type="xs:string" name="superLevelEsc" use="optional" />
<xs:attribute type="xs:string" name="estimatedTAT" use="optional" />
<xs:attribute type="xs:string" name="reopenComplaint" use="optional" />

BBPS API SPECIFICATIONS | Version 14.0

</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="TxnSearchDateCriteria">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:string" name="fromDate" use="required" />
<xs:attribute type="xs:string" name="toDate" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>

Transaction Status and Complaint Related API Response

Tag Details
Index XML Element Description Occurrence
1.1 <bbps:TxnStatusComplai API Name 1..1
nResponse>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Txn> Transaction information, passed throughout the system, visible to 1..1
all entities of the eco-system
3.1.1 ts Transmission date and time of the transaction 1..1
3.1.2 xchangeId Identification of the type of the request – transaction status (401), 1..1
complaint registration (501), complaint re-assignment (502),
complaint status (506) or complaint closure (507)
4.1 <TxnStatusComplainRes Information pertaining to transaction status and complaint related 1..1
p> responses
4.1.1 msgId Unique identification assigned by the initiating BBPOU for chaining 1..1
a request and response message
4.1.2 responseCode Carries the response code indicating success or failure of the 1..1
transaction
4.1.3 responseReason Description of the response code 1..1
4.1.4 complaintId Complaint ID generated by BBPCU to check the complaint status, 0..1
re-assign or close a complaint subsequently
4.1.5 assigned BBPOU to which the complaint is assigned 0..1
4.1.6 openComplaint Flag indicating if the transaction based complaint being raised is 0..1
currently open in the system or not – "Y" will show the details for
the complaint raised earlier
4.1.7 complaintStatus Complaint status of the transaction 0..1
4.1.8 remarks Last updated additional information provided by the BBPOU 0..1
pertaining to the complaint and fetched in the complaint status
check (506) response
4.1.9 reopenComplaint Flag to identify whether the complaint was Re-Opened 0..1

BBPS API SPECIFICATIONS | Version 14.0

4.2 <TxnStatusComplainRes List of transactions against a particular search criteria 0..1

p.TxnList>
4.3 <TxnStatusComplainRes Record containing the details of a single transaction 1..n
p.TxnList.TxnDetail>
4.3.1 txnReferenceId Transaction reference number used by the Customer for referring 1..1
to a Payment transaction
4.3.2 amount Bill payment amount 1..1
4.3.3 txnDate Date of the transaction 1..1
4.3.4 agentId Agent ID of the Agent involved in the transaction 1..1
4.3.5 billerId Biller ID of the Biller involved in the transaction 1..1
4.3.6 txnStatus Status of the transaction – successful or failure 1..1
4.3.7 approvalRefNum
4.3.8 mti Type of the transaction 1..1
4.3.9 complianceRespCd Carries the compliance code indicating the reason for a failed 1..1
transaction – not required for a successful transaction
4.3.10 complianceReason Description of the compliance code – not required for a successful 1..1
transaction
4.3.11 disputeId Dispute ID against the transaction 1..1
4.3.12 disputeDate Dispute Creation Date 1..1
4.3.13 disputeType Type of the Dispute 1..1
4.3.14 disputeStatus Status of the Dispute 1..1
4.3.15 disputeAmount Dispute Amount 1..1
4.3.16 caId Credit Adjustment Id against the transaction 1..1
4.3.17 caDate Credit Adjustment creation date 1..1
4.3.18 caStatus Status of Credit Adjustment 1..1
4.3.19 caAmount Credit Adjustment Amount 1..1
4.3.20 caPenalty Penalty Amount against Credit Adjustment 1..1
4.3.21 paymentRefId Unique ID generated at the time of Payment Confirmaton, such as 1..1
PG Reference Number, RRN, etc..
4.4 <TxnStatusComplainRes Details of the customer for a successful transaction search (401) 0..1
p.CustomerDetails> response
4.4.1 mobile Mobile number linked to the transaction(s) 1..1

Transaction Status and Complaint Related API Response

BBPS API SPECIFICATIONS | Version 14.0

<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="description" use="optional" />
<xs:attribute type="xs:string" name="openComplaint" use="optional" />
<xs:attribute type="xs:string" name="reopenComplaint" 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:attribute type="xs:string" name="remarks" use="optional" />
<xs:attribute type="xs:string" name="txnReferenceId" use="optional" />
<xs:attribute type="xs:string" name="disposition" 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="agentId" use="optional" />
<xs:attribute type="xs:string" name="billerId" use="optional" />
<xs:attribute type="xs:string" name="refId" use="optional" />
<xs:attribute type="xs:string" name="approvalRefNum" use="optional" />
<xs:attribute type="xs:string" name="txnReferenceId" use="required" />
<xs:attribute type="xs:string" name="mti" use="optional" />
<xs:attribute type="xs:string" name="txnDate" use="required" />
<xs:attribute type="xs:string" name="amount" use="required" />
<xs:attribute type="xs:string" name="txnStatus" use="required" />
<xs:attribute type="xs:string" name="complianceRespCd" use="optional" />
<xs:attribute type="xs:string" name="complianceReason" use="optional" />
<xs:attribute type="xs:string" name="disputeId" use="optional" />
<xs:attribute type="xs:string" name="disputeDate" use="optional" />
<xs:attribute type="xs:string" name="disputeType" use="optional" />
<xs:attribute type="xs:string" name="disputeStatus" use="optional" />
<xs:attribute type="xs:string" name="disputeAmount" use="optional" />
<xs:attribute type="xs:string" name="caId" use="optional" />
<xs:attribute type="xs:string" name="caDate" use="optional" />
<xs:attribute type="xs:string" name="caStatus" use="optional" />
<xs:attribute type="xs:string" name="caAmount" use="optional" />
<xs:attribute type="xs:string" name="caPenalty" use="optional" />
<xs:attribute type="xs:string" name="paymentRefId" use="optional" />
</xs:complexType>
<xs:complexType name="CustomerDetails">
<xs:attribute type="xs:string" name="mobile" use="required" />
</xs:complexType>
</xs:schema>

BBPS API SPECIFICATIONS | Version 14.0

7 Biller Fetch MDM Request & Response

Sample Request API: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerFetchRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:13:46+05:30" origInst="OP01"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713"/>
<SearchMyBiller mybiller="Yes/No" />
<Search>
<billerId>OBNSTNS00NAT01</billerId>
<billerCategoryName>DTH</billerCategoryName>
</Search>
<SearchByTime>
<time>2021-01-14T09:41:31+05:30</time>
</SearchByTime>
</bbps:BillerFetchRequest>

Sample Response API: BBPCU to BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerFetchResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:13:46+05:30" origInst="BBCU"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713" />
<biller>
<billerId>NETFLIX00NAT02</billerId>
<billerName>Netflix - Dummy</billerName>
<billerAliasName>Netflix - Dummy</billerAliasName>
<billerCategoryName>Subscription</billerCategoryName>
<billerMode>ONLINE</billerMode>
<billerAcceptsAdhoc>true</billerAcceptsAdhoc>
<parentBiller>false</parentBiller>
<billerOwnerShp>Private</billerOwnerShp>
<billerCoverage>IND</billerCoverage>
<fetchRequirement>NOT_SUPPORTED</fetchRequirement>
<paymentAmountExactness>Exact</paymentAmountExactness>
<supportBillValidation>MANDATORY</supportBillValidation>
<billerEffctvFrom>2021-01-15</billerEffctvFrom>
<billerEffctvTo>2031-12-31</billerEffctvTo>
<billerTempDeactivationStart />
<billerTempDeactivationEnd />
<billerPaymentModes>
<paymentMode>Internet Banking</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Debit Card</paymentMode>
<minLimit>1</minLimit>

BBPS API SPECIFICATIONS | Version 14.0

<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Credit Card</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Prepaid Card</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>IMPS</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Cash</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>No</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>UPI</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Wallet</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>NEFT</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>AEPS</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Account Transfer</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentModes>
<paymentMode>Bharat QR</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>

BBPS API SPECIFICATIONS | Version 14.0

</billerPaymentModes>
<billerPaymentModes>
<paymentMode>USSD</paymentMode>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentModes>
<billerPaymentChannels>
<paymentChannel>INT</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>INTB</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>MOB</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>MOBB</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>POS</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>MPOS</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>ATM</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>BNKBRNCH</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>No</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>KIOSK</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>Yes</supportPendingStatus>
</billerPaymentChannels>

BBPS API SPECIFICATIONS | Version 14.0

<billerPaymentChannels>
<paymentChannel>AGT</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>No</supportPendingStatus>
</billerPaymentChannels>
<billerPaymentChannels>
<paymentChannel>BSC</paymentChannel>
<minLimit>1</minLimit>
<supportPendingStatus>No</supportPendingStatus>
</billerPaymentChannels>
<billerCustomerParams>
<paramName>Customer Mobile Number</paramName>
<dataType>NUMERIC</dataType>
<optional>true</optional>
<minLength>10</minLength>
<maxLength>10</maxLength>
<regex>^[6-9]{1}[0-9]{9}$</regex>
<visibility>true</visibility>
</billerCustomerParams>
<billerCustomerParams>
<paramName>Email ID</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
<minLength>3</minLength>
<maxLength>70</maxLength>
<visibility>true</visibility>
</billerCustomerParams>
<billerCustomerParams>
<paramName>Id</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
<visibility>false</visibility>
</billerCustomerParams>
<customerParamGroups>
<group name="Group1.1" input="1">
<param>Customer Mobile Number</param>
<group name="Group1.2" input="1">
<param>Email ID</param>
</group>
</group>
</customerParamGroups>
<billerResponseParams>
<amountOptions>
<amountBreakupSet>BASE_BILL_AMOUNT</amountBreakupSet>
</amountOptions>
</billerResponseParams>
<billerAdditionalInfo>
<paramName>Package Name</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
</billerAdditionalInfo>

BBPS API SPECIFICATIONS | Version 14.0

<billerAdditionalInfo>
<paramName>Package Duration</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
</billerAdditionalInfo>
<billerAdditionalInfo>
<paramName>Package Price</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
</billerAdditionalInfo>
<billerAdditionalInfoPayment>
<paramName>URL</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>true</optional>
</billerAdditionalInfoPayment>
<interchangeFeeConf>
<mti>PAYMENT</mti>
<responseCode>000</responseCode>
<fees>EBF</fees>
<fees>CCF</fees>
<defaultFee>true</defaultFee>
<effctvFrom>20180925</effctvFrom>
</interchangeFeeConf>
<interchangeFeeConf>
<mti>PAYMENT</mti>
<paymentChannel>AGT</paymentChannel>
<responseCode>000</responseCode>
<fees>PBF</fees>
<fees>CCF</fees>
<defaultFee>false</defaultFee>
<effctvFrom>20180925</effctvFrom>
</interchangeFeeConf>
<interchangeFeeConf>
<mti>PAYMENT</mti>
<paymentChannel>BNKBRNCH</paymentChannel>
<responseCode>000</responseCode>
<fees>PBF</fees>
<fees>CCF</fees>
<defaultFee>false</defaultFee>
<effctvFrom>20180925</effctvFrom>
</interchangeFeeConf>
<interchangeFeeConf>
<mti>PAYMENT</mti>
<paymentChannel>BSC</paymentChannel>
<responseCode>000</responseCode>
<fees>PBF</fees>
<fees>CCF</fees>
<defaultFee>false</defaultFee>
<effctvFrom>20180925</effctvFrom>
</interchangeFeeConf>
<interchangeFee>

BBPS API SPECIFICATIONS | Version 14.0

<feeCode>PBF</feeCode>
<feeDesc>Biller Fee</feeDesc>
<feeDirection>B2C</feeDirection>
<interchangeFeeDetails>
<tranAmtRangeMax>9223372036854775807</tranAmtRangeMax>
<tranAmtRangeMin>0</tranAmtRangeMin>
<percentFee>0.00</percentFee>
<flatFee>500</flatFee>
<effctvFrom>2018-09-25</effctvFrom>
<effctvTo />
</interchangeFeeDetails>
</interchangeFee>
<interchangeFee>
<feeCode>CCF</feeCode>
<feeDesc>Customer Convenience Fee</feeDesc>
<feeDirection>C2B</feeDirection>
<interchangeFeeDetails>
<tranAmtRangeMax>9223372036854775807</tranAmtRangeMax>
<tranAmtRangeMin>0</tranAmtRangeMin>
<percentFee>0.00</percentFee>
<flatFee>0</flatFee>
<effctvFrom>2018-09-25</effctvFrom>
<effctvTo />
</interchangeFeeDetails>
</interchangeFee>
<interchangeFee>
<feeCode>EBF</feeCode>
<feeDesc>Biller Fee</feeDesc>
<feeDirection>B2C</feeDirection>
<interchangeFeeDetails>
<tranAmtRangeMax>9223372036854775807</tranAmtRangeMax>
<tranAmtRangeMin>0</tranAmtRangeMin>
<percentFee>0.00</percentFee>
<flatFee>250</flatFee>
<effctvFrom>2018-09-25</effctvFrom>
<effctvTo />
</interchangeFeeDetails>
</interchangeFee>
<Status>ACTIVE</Status>
<billerDescription>Sample Biller MDM Response</billerDescription>
<supportDeemed>Yes</supportDeemed>
<supportPendingStatus>Yes</supportPendingStatus>
<billerTimeOut>120</billerTimeOut>
<planMdmRequirement>MANDATORY</planMdmRequirement>
<planAdditionalInfo>
<paramName>Package Name</paramName>
<dataType>ALPHANUMERIC</dataType>
<optional>false</optional>
</planAdditionalInfo>
<planAdditionalInfo>
<paramName>Package Duration</paramName>

BBPS API SPECIFICATIONS | Version 14.0

<dataType>ALPHANUMERIC</dataType>
<optional>false</optional>
</planAdditionalInfo>
</biller>
</bbps:BillerFetchResponse>

Biller Fetch MDM Request Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerFetchReques API Name 1..1
t>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <SearchMyBiller> Tag for searching the Biller details associated or non-associated 0..1
with the BBPOU initiating the request
3.1.1 mybiller Flag indicating request for the Biller details associated or non- 1..1
associated with the BBPOU initiating the request
4.1 <Search> Tag for searching the Biller details based on certain parameters 0..1
4.2 <Search.billerId> Biller ID for which the Biller details are requested 1..n
<Search.billerCategoryN Biller Category Name for which the Biller details are requested 1..n
ame>
5.1 <SearchByTime> Tag for searching the Biller details based on time parameter 0..1
5.2 <SearchByTime.time> Request for Biller details for all the Billers updated in the system 1..1
after the time provided

Biller Fetch MDM Request XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:complexType name="searchType">
<xs:sequence>
<xs:element type="xs:string" name="billerId" minOccurs="0" maxOccurs="unbounded" />
<xs:element type="xs:string" name="billerName" minOccurs="0" maxOccurs="unbounded" />
<xs:element type="xs:string" name="billerCategoryName" minOccurs="0" maxOccurs="unbounded" />
<xs:element type="xs:string" name="paymentMode" minOccurs="0" maxOccurs="unbounded" />
<xs:element type="xs:string" name="paymentChannel" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="searchByTime">
<xs:sequence>
<xs:element type="xs:string" name="time" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="searchMyBiller">
<xs:attribute type="bbps:myBiller" name="mybiller" />
</xs:complexType>
<xs:simpleType name="myBiller">
<xs:restriction base="xs:string">
<xs:enumeration value="Yes" />
<xs:enumeration value="No" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

Biller Fetch MDM Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerFetchRespon API Name 1..1
se>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <biller> MDM details of the Biller 0..n
3.2 <biller.billerId> Identifier of the Biller 1..1
3.3 <biller.billerName> Name of the Biller 1..1
3.4 <biller.billerAliasName> Alias name of the Biller 1..1
3.5 <biller.billerCategoryNa Biller category 1..1
me>
3.6 <biller.billerMode> Biller mode, i.e., Online, Offline A, Offline B 1..1
3.7 <biller.billerAcceptsAdho Flag indicating if the Biller accepts adhoc payment 1..1
c>
3.8 <biller.parentBiller> Flag indicating if the Biller is a parent Biller 1..1
3.9 <biller.parentBillerId> Identifier of the parent Biller 0..1
3.10 <biller.billerOwnerShp> Biller ownership, i.e., Government, PSU, Private 1..1
3.11 <biller.billerCoverage> Coverage of the Biller, i.e., National, State/UT, City/District 1..1

BBPS API SPECIFICATIONS | Version 14.0

3.12 <biller.fetchRequirement Indicates if the Biller allows Bill Fetch or not – possible values are 1..1
> MANDATORY, OPTIONAL, NOT_SUPPORTED
3.13 <biller.supportBillValidat Indicates if the Biller allows Bill Validation or not – possible values 1..1
ion> are MANDATORY, OPTIONAL, NOT_SUPPORTED
3.14 <biller.paymentAmountE Indicates if the Biller (having Mandatory Bill Fetch) allows exact 0..1
xactness> payment or not – possible values are Exact, Exact and above, Exact
and below
3.15 <biller.billerEffctvFrom> Effective from date of the Biller 1..1
3.16 <biller.billerEffctvTo> Effective to date of the Biller 1..1
3.17 <biller.billerTempDeactiv Temporary deactivation start date of the Biller 1..1
ationStart>
3.18 <biller.billerTempDeactiv Temporary deactivation end date of the Biller 1..1
ationEnd>
3.19 <biller.billerPaymentMo Payment mode details of the Biller 1..n
des>
3.19.1 <biller.billerPaymentMo Payment modes supported by the Biller 1..1
des.paymentMode>
3.19.2 <biller.billerPaymentMo Maximum limit accepted by a Biller for a particular payment mode 0..1
des.maxLimit>
3.19.3 <biller.billerPaymentMo Minimum limit accepted by a Biller for a particular payment mode 1..1
des.minLimit>
3.19.4 <biller.billerPaymentMo Flag indicating whether Pending Status is applicable for the 0..1
des.supportPendingStat payment mode or not – Yes/No
us>
3.20 <biller.billerPaymentCha Payment channel details of the Biller 1..n
nnels>
3.20.1 <biller.billerPaymentCha Payment channels supported by the Biller 1..1
nnels.paymentChannel>
3.20.2 <biller.billerPaymentCha Maximum limit accepted by a Biller for a particular payment 0..1
nnels.maxLimit> channel
3.20.3 <biller.billerPaymentCha Minimum limit accepted by a Biller for a particular payment 1..1
nnels.minLimit> channel
3.20.4 <biller.billerPaymentCha Flag indicating whether Pending Status is applicable for the 0..1
nnels.supportPendingSta payment channel or not – Yes/No
tus>
3.21 <biller.billerCustomerPar Customer parameter details of the Biller 1..n
ams>
3.21.1 <biller.billerCustomerPar Customer parameter name 1..1
ams.paramName>
3.21.2 <biller.billerCustomerPar Customer parameter data type 1..1
ams.dataType>
3.21.3 <biller.billerCustomerPar Flag indicating if the Customer parameter is optional 1..1
ams.optional>
3.21.4 <biller.billerCustomerPar Minimum length of the Customer parameter 0..1
ams.minLength>
3.21.5 <biller.billerCustomerPar Maximum length of the Customer parameter 0..1
ams.maxLength>

BBPS API SPECIFICATIONS | Version 14.0

3.21.6 <biller.billerCustomerPar Regular expression (RegEx) is a string of characters representing 0..1

ams.regex> permissible values of the customer parameters for a biller.
3.21.7 <biller.billerCustomerPar Default (possible) values list against a Customer Parameter 0..1
ams.values>
3.21.8 <biller.billerCustomerPar Visibility of the customer parameter at COUs front-end channel 1..1
ams.visibility>
3.22 <biller.customerParamGr Customer Parameter Groups with respect to the various 0..1
oups> combinations supported
3.22.1 <biller.customerParamGr Customer Parameter Group 1..n
oups.group>
3.22.2 <biller.customerParamGr Name of the Parent/Sub-Group 1..1
oups.group.name>
3.22.3 <biller.customerParamGr Flag indicating the required number of tags from the group. 1..1
oups.group.input>
3.22.4 <biller.customerParamGr Customer parameter name 1..n
oups.group.param>
3.23 <biller.billerResponsePar Biller Responses with respect to the various amount combinations 1..1
ams> supported
3.23.1 <biller.billerResponsePar Amount options supported by the Biller 1..n
ams.amountOptions>
3.23.2 <biller.billerResponsePar Amount combination for a particular amount option 1..n
ams.amountOptions.am
ountBreakupSet>
3.24 <biller.billerAdditionalInf Additional information details provided by the Biller 0..n
o>
3.24.1 <biller.billerAdditionalInf Additional information parameter name 1..1
o.paramName>
3.24.2 <biller.billerAdditionalInf Additional information parameter data type 1..1
o.dataType>
3.24.3 <biller.billerAdditionalInf Flag indicating if the additional information parameter is optional 1..1
o.optional>
3.25 <biller.billerAdditionalInf Additional information details provided by the Biller in Payment 0..n
oPayment> Response
3.25.1 <biller.billerAdditionalInf Payment Additional information parameter name 1..1
oPayment.paramName>
3.25.2 <biller.billerAdditionalInf Payment Additional information parameter data type 1..1
oPayment.dataType>
3.25.3 <biller.billerAdditionalInf Flag indicating if the additional information parameter is optional 1..1
oPayment.optional>
3.26 <biller.interchangeFeeCo Interchange fee configuration details of the Biller 1..n
nf>
3.26.1 <biller.interchangeFeeCo Message Type Indicator for the fee, i.e., fetch, payment, etc. 1..1
nf.mti>
3.26.2 <biller.interchangeFeeCo Response code associated with the fee 1..1
nf.responseCode>
3.26.3 <biller.interchangeFeeCo Payment mode associated with the fee 0..1
nf.paymentMode>

BBPS API SPECIFICATIONS | Version 14.0

3.26.4 <biller.interchangeFeeCo Payment channel associated with the fee 0..1

nf.paymentChannel>
3.26.5 <biller.interchangeFeeCo Fee codes for applicable interchange fee 1..n
nf.fees>
3.26.6 <biller.interchangeFeeCo Flag indicating if it is a default fee or not 1..1
nf.defaultFee>
3.26.7 <biller.interchangeFeeCo Effective from date for the fee 1..1
nf.effctvFrom>
3.26.8 <biller.interchangeFeeCo Effective to date for the fee 1..1
nf.effctvTo>
3.27 <biller.interchangeFee> Interchange fee details of the Biller 1..n
3.27.1 <biller.interchangeFee.fe Fee code associated with the Biller 1..1
eCode>
3.27.2 <biller.interchangeFee.fe Description of the corresponding fee code 1..1
eDesc>
3.27.3 <biller.interchangeFee.fe Direction of fee movement, i.e., Customer BBPOU to Biller BBPOU 1..1
eDirection> or vice-versa
3.27.4 <biller.interchangeFee.in Interchange fee details pertaining to range, type and validity 1..n
terchangeFeeDetails>
3.27.5 <biller.interchangeFee.in Maximum range for a particular fee configuration 1..1
terchangeFeeDetails.tra
nAmtRangeMax>
3.27.6 <biller.interchangeFee.in Minimum range for a particular fee configuration 1..1
terchangeFeeDetails.tra
nAmtRangeMin>
3.27.7 <biller.interchangeFee.in Percentage fee details 1..1
terchangeFeeDetails.per
centFee>
3.27.8 <biller.interchangeFee.in Flat fee details 1..1
terchangeFeeDetails.flat
Fee>
3.27.9 <biller.interchangeFee.in Effective from date for the fee configuration 1..1
terchangeFeeDetails.effc
tvFrom>
3.27.10 <biller.interchangeFee.in Effective to date for the fee configuration 1..1
terchangeFeeDetails.effc
tvTo>
3.28 <biller.Status> Status of the Biller, i.e., active, deactivated, etc. 1..1
3.29 <biller.billerDescription> Additional information related to Billers 0..1
3.30 <biller.supportDeemed> Flag indicating whether deemed success is applicable for the biller 0..1
or not – Yes/No
3.31 <biller.supportPendingSt Flag indicating whether pending status is applicable for the biller 0..1
atus> or not – Yes/No
3.32 <biller.billerTimeOut> Biller outer limit for providing the response in minutes. This will be 0..1
applicable only if "Support Pending Status" is Yes.
3.33 <biller.planMdmRequire Indicates if the Biller support Plan MDM functionality – possible 1..1
ment> values are MANDATORY, OPTIONAL, NOT_SUPPORTED
3.34 <biller.planAdditionalInf Additional information details of the Plan provided by the 0..n
o> Biller/BOU as part of Plan MDM
3.34.1 <biller.planAdditionalInf Plan Additional information parameter name 1..1
o.paramName>
3.34.2 <biller.planAdditionalInf Plan Additional information parameter data type 1..1

BBPS API SPECIFICATIONS | Version 14.0

o.dataType>
3.34.3 <biller.planAdditionalInf Flag indicating if the plan additional information parameter is 1..1
o.optional> optional

Biller Fetch 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="0" maxOccurs="unbounded" />
<xs:element type="bbps:SearchResult" name="searchResult" minOccurs="0" maxOccurs="1" />
</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="billerAliasName" 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 type="bbps:FetchRequirement" name="fetchRequirement" minOccurs="1" maxOccurs="1" />
<xs:element name="paymentAmountExactness" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="supportBillValidation" type="xs:string" minOccurs="0" 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 name="billerTempDeactivationStart" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="billerTempDeactivationEnd" type="xs:string" minOccurs="0" 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 type="bbps:ParamConfig" name="billerCustomerParams" minOccurs="1" maxOccurs="unbounded" />
<xs:element type="bbps:CustomerParamGroups" name="customerParamGroups" minOccurs="0" maxOccurs="1" />

<xs:element type="bbps:BillerResponseParams" name="billerResponseParams" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:ParamConfig" name="billerAdditionalInfo" minOccurs="1" maxOccurs="unbounded" />
<xs:element type="bbps:ParamConfig" name="billerAdditionalInfoPayment" minOccurs="1"
maxOccurs="unbounded" />
<xs:element type="bbps:InterchangeFeeConf" name="interchangeFeeConf" minOccurs="1"
maxOccurs="unbounded" />
<xs:element type="bbps:InterchangeFee" name="interchangeFee" minOccurs="1" maxOccurs="unbounded" />

BBPS API SPECIFICATIONS | Version 14.0

<xs:element type="xs:string" name="Status" minOccurs="0" maxOccurs="1" />

<xs:element type="xs:string" name="billerDescription" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="supportDeemed" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="supportPendingStatus" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="billerTimeOut" minOccurs="0" maxOccurs="1" />
<xs:element type="bbps:PlanMDMRequirement" name="planMdmRequirement" minOccurs="0" maxOccurs="1" />
<xs:element type="bbps:ParamConfig" name="planAdditionalInfo" minOccurs="0" 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:element type="xs:long" name="minLimit" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="supportPendingStatus" 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="0" maxOccurs="1" />
<xs:element type="xs:long" name="minLimit" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="supportPendingStatus" minOccurs="0" 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:element type="xs:int" name="minLength" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:int" name="maxLength" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="regex" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="values" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:boolean" name="visibility" minOccurs="0" maxOccurs="1" />
</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="CustomerParamGroups">
<xs:sequence>
<xs:element type="bbps:Group" name="group" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="Group">
<xs:sequence>
<xs:element type="xs:string" name="param" minOccurs="1" maxOccurs="unbounded" />

BBPS API SPECIFICATIONS | Version 14.0

<xs:element type="bbps:Group" name="group" minOccurs="0" maxOccurs="unbounded" />

</xs:sequence>
<xs:attribute type="xs:string" name="name" use="required" />
<xs:attribute type="xs:string" name="input" use="optional" />
</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:complexType name="SearchResult">
<xs:sequence>
<xs:element type="xs:string" name="result" 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:simpleType name="FetchRequirement">
<xs:restriction base="xs:string">
<xs:enumeration value="MANDATORY" />
<xs:enumeration value="OPTIONAL" />
<xs:enumeration value="NOT_SUPPORTED" />

BBPS API SPECIFICATIONS | Version 14.0

</xs:restriction>
</xs:simpleType>
<xs:simpleType name="PlanMDMRequirement">
<xs:restriction base="xs:string">
<xs:enumeration value="MANDATORY" />
<xs:enumeration value="OPTIONAL" />
<xs:enumeration value="NOT_SUPPORTED" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

8 Agent MDM Fetch Request & Response

Sample Request API: BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:AgentFetchRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:13:46+05:30" origInst="OP01"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713"/>
<Search>
<agentId>OU21AB21MOB520528256</agentId>
</Search>
<SearchByTime>
<time>2021-02-14T16:26:02+05:30</time>
</SearchByTime>
</bbps:AgentFetchRequest>

Sample Response API: BBPCU to BBPOU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:AgentFetchResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-15T17:13:46+05:30" origInst="BBCU"
refId="LWPGWSEQFHVLWPBFDSSO1VFFIJS10461713" />
<Agent>
<agentId>OP01OP11AGT000000001</agentId>
<agentBusnsType>Aggregator</agentBusnsType>
<agentName>Manoj Chekuri</agentName>
<agentAliasName>Manoj</agentAliasName>
<agentLinkedAgentInst>OP11</agentLinkedAgentInst>
<agentGeoCode>22.2222,88.8888</agentGeoCode>
<agent_shop_name>OP01 AGT</agent_shop_name>
<agent_mobile_no>9505987798</agent_mobile_no>
<agentDummy>False</agentDummy>
<agentPaymentModes>
<paymentMode>Internet_Banking</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Debit_Card</paymentMode>

BBPS API SPECIFICATIONS | Version 14.0

<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Credit_Card</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Prepaid_Card</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>IMPS</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Cash</paymentMode>
<maxLimit>4999900</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>UPI</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Wallet</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>NEFT</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>AEPS</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentModes>
<paymentMode>Account_Transfer</paymentMode>
<maxLimit>20000000</maxLimit>
<minLimit>1</minLimit>
</agentPaymentModes>
<agentPaymentChannels>
<paymentChannel>Agent</paymentChannel>
<maxLimit>20000000</maxLimit>

BBPS API SPECIFICATIONS | Version 14.0

<minLimit>1</minLimit>
</agentPaymentChannels>
<agentEffctvFrom>2017-08-30</agentEffctvFrom>
<agentEffctvTo />
<agentStatus>ACTIVE</agentStatus>
<agentTempDeactivationStart />
<agentTempDeactivationEnd />
<agentRefId>Physical Agent 1</ agentRefId >
<agentBulk>False</agentBulk>
<agentPinCode>400063</agentPinCode>
<agentRegisteredCity>Mumbai</agentRegisteredCity>
<agentRegisteredState>MAHARASHTRA</agentRegisteredState>
<agentRegisteredAddress>Hub mall</agentRegisteredAddress>
<agentRegisteredCountry>India</agentRegisteredCountry>
</Agent>
</bbps:AgentFetchResponse>

Agent MDM Fetch Request Tag Details

Index XML Element Description Occurrence
1.1 <bbps:AgentFetchReque API Name 1..1
st>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Search> Tag for searching the Agent details based on certain parameters 0..1
3.2 <Search.agentId> Agent ID for which the Agent details are requested 1..n
4.1 <SearchByTime> Tag for searching the Agent details based on time parameter 0..1
4.2 <SearchByTime.time> Request for Agent details for all the Agents updated in the system 1..1
after the time provided

Agent MDM Fetch Request XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:element type="bbps:searchTypeForAgent" name="Search" minOccurs="0" maxOccurs="1" />

<xs:element type="bbps:searchByTime" name="SearchByTime" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="searchTypeForAgent">
<xs:sequence>
<xs:element type="xs:string" name="agentId" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="searchByTime">
<xs:sequence>
<xs:element type="xs:string" name="time" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:schema>

Agent MDM Fetch Response Tag Details

Index XML Element Description Occurrence
1.1 <bbps:AgentFetchRespo API Name 1..1
nse>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the 1..1
transaction
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Agent> MDM details of the Agent 0..n
3.2 <Agent.agentId> Identifier of the Agent 1..1
3.3 <Agent.agentBusnsType Business type of the Agent 1..1
>
3.4 <Agent.agentName> Name of the Agent 1..1
3.5 <Agent.agentAliasName Alias name of the Agent 1..1
>
3.6 <Agent.agentLinkedAgen Code of the Agent Institution associated with the Agent 1..1
tInst>
3.7 <Agent.agentGeoCode> Agent geo-location 1..1
3.8 <Agent.agent_shop_nam Shop name of the Agent 1..1
e>
3.9 <Agent.agent_mobile_n Mobile number of the Agent 1..1
o>
3.10 <Agent.agentDummy> Flag indicating if the Agent represents an electronic or physical 1..1
channel
3.11 <Agent.agentPaymentM Payment mode details of the Agent 1..n
odes>
3.12 <Agent.agentPaymentM Payment modes supported by the Agent 1..1
odes.paymentMode>
3.13 <Agent.agentPaymentM Maximum limit accepted by an Agent for a particular payment 0..1
odes.maxLimit> mode

BBPS API SPECIFICATIONS | Version 14.0

3.14 <Agent.agentPaymentM Minimum limit accepted by an Agent for a particular payment 1..1
odes.minLimit> mode
3.15 <Agent.agentPaymentCh Payment channel details of the Agent 1..1
annels>
3.16 <Agent.agentPaymentCh Payment channels supported by the Agent 1..1
annels.paymentChannel
>
3.17 <Agent.agentPaymentCh Maximum limit accepted by an Agent for a particular payment 0..1
annels.maxLimit> channel
3.18 <Agent.agentPaymentCh Minimum limit accepted by an Agent for a particular payment 1..1
annels.minLimit> channel
3.19 <Agent.agentBulk> Flag indicating if the Agent is configured through bulk upload 1..1
feature in BBPS Canvas (intranet portal).
3.20 <Agent.agentRefId> ID used by a BBPOU / Agent Institution to internally identify an 1..1
Agent
3.21 <Agent.agentPinCode> PIN Code of the Agent 1..1
3.22 <Agent.agentRegistered Registered city of the Agent 1..1
City>
3.23 <Agent.agentRegistered Registered state of the Agent 1..1
State>
3.24 <Agent.agentRegistered Registered address of the Agent 1..1
Address>
3.25 <Agent.agentRegistered Registered country of the Agent 1..1
Country>
3.26 <Agent.agentEffctvFrom Effective from date of the Agent 1..1
>
3.27 <Agent.agentEffctvTo> Effective to date of the Agent 1..1
3.28 <Agent.agentTempDeact Temporary deactivation start date of the Agent 1..1
ivationStart>
3.29 <Agent.agentTempDeact Temporary deactivation end date of the Agent 1..1
ivationEnd>
3.30 <Agent.agentStatus> Status of the Agent, i.e., active, deactivated, etc. 1..1

Agent MDM Fetch Response XSD

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

BBPS API SPECIFICATIONS | Version 14.0

<xs:complexType name="agent">
<xs:sequence>
<xs:element type="xs:string" name="agentId" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentBusnsType" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentName" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentAliasName" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentLinkedAgentInst" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentGeoCode" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agent_shop_name" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agent_mobile_no" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentDummy" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:PaymentModeLimit" name="agentPaymentModes" minOccurs="1"
maxOccurs="unbounded" />
<xs:element type="bbps:PaymentChannelLimit" name="agentPaymentChannels" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentEffctvFrom" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentEffctvTo" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentStatus" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentTempDeactivationStart" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentTempDeactivationEnd" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentRefId" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:boolean" name="agentBulk" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentPinCode" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentRegisteredCity" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentRegisteredState" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentRegisteredAddress" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="agentRegisteredCountry" minOccurs="1" maxOccurs="1" />
</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:element type="xs:long" name="minLimit" minOccurs="1" 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="0" maxOccurs="1" />
<xs:element type="xs:long" name="minLimit" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</schema>

BBPS API SPECIFICATIONS | Version 14.0

9 Plan MDM APIs

Plan MDM is a complete automated solution wherein Biller BBPOU pushes the latest plans to BBPCU. BBPCU will do
the basic validations & if all the details are valid, then these plans will be broadcasted to Customer BBPOUs and
Participating AIs who are enabled for Plan MDM. Customer BBPOUs/Participating AIs will make use of this Generic
Plan MDM API to display the available denominations/plans in their respective front end application

There are 4 different mechanishs to Push/Pull the plans:

1. Plan MDM Push – BOU to BBPCU

a. BOU to push the delta plans to BBPCU (i.e. any additional/new changes as and when updated from
Biller)
2. Plan MDM Pull – BBPCU to BOU
a. Scheduled Pull – BBPCU will pull the delta plans from BOUs (i.e. at a scheduled time BBPCU will
initiate the Pull request to BOUs)
b. Ad-hoc Pull – BBPCU will initiate the Pull Request to BOUs (i.e. all Plans/Biller wise/Delta Plans)
3. Plan MDM Push – BBCU to COU/PAI
a. Scheduled Push – BBPCU will push the delta plans to COUs/PAIs (i.e. at a scheduled time BBPCU will
Push the Plans to COUs/PAIs)
b. Ad-hoc Push – BBPCU will Push the Plans COUs/PAIs (i.e. all Plans/Biller wise/Delta Plans)
4. Plan MDM Pull – COU/PAI to BBCU
a. COUs/PAIs to pull the plans from BBPCU (i.e. either Search by Time or Search by Biller)

Considerations for BOUs

1. Biller BBPOUs need to integrate with their respective Billers, which supports Plan MDM for fetching the Plan
details.
2. Once BOU received Plan Details (new/update) from Biller, BOU should push the same to BBPCU.
3. In case Biller has multiple BOUs, both the BOUs should update the plans at their end.
4. While sending the Plan Details to BBPCU, BOUs should not modify/tamper the Plan Details, such as Plan ID,
Amount, Description, etc.
5. Whenever BBPCU sent Plan MDM Pull request to BOU, BOU should send only incremental Plan Details
(new/updated) to BBPCU.

Considerations for COUs/Participating AIs

1. COUs/AIs should store all the Plan Details against the Billers shared by BBPCU in their local repository.
2. COUs/AIs should show respective Plan Details in their front-end screens whenever user select the biller,
under "Please Choose the Plan" option along with the mandatory input parameter.
3. Once user entered the input parameter and choose the plan, COUs/AIs need to send the Validation Request
with corresponding Plan Id under parameter name "Id" in CustomerParams block along with other input
parameters.
4. If Validation is successful, COUs/AIs has to show the amount associated with the validated Plan Id as Payable
Amount in the front-end screen (as non-editable) and should pass the same amount while initiating the
Payment Request.

BBPS API SPECIFICATIONS | Version 14.0

Sample Plan MDM Push Request API: Biller BBPOU to

BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BBPSPlanMDMPush xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:07:30+05:30" origInst="OP22"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431207" type="REQUEST/RESPONSE" />
<PlanDetails>
<Id>1</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>1 Month</subType>
</categorySubType>
<amountInRupees>99</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premium 1 Month Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>2</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>3 Months</subType>
</categorySubType>
<amountInRupees>299</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 3 Months Plan" />
<Tag paramName="Package Duration" paramValue="3 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>3</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>6 Months</subType>
</categorySubType>

BBPS API SPECIFICATIONS | Version 14.0

<amountInRupees>599</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 6 Months Plan" />
<Tag paramName="Package Duration" paramValue="6 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>4</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>999</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 12 Months Plan" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>5</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Club</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>365</amountInRupees>
<planDescription>TV shows before telecast, Select ZEE5 Originals, Select ALT Balaji Shows, Select Movies, Zindagi
TV Shows, Kids, Live TV. Watch on 2 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Club 12 Months Plan" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>1</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>Premium</categoryType>

BBPS API SPECIFICATIONS | Version 14.0

<categorySubType>
<subType>1 Month</subType>
</categorySubType>
<amountInRupees>299</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Disney+ Movies, Hollywood Movies, Kids Content, English Shows, Disney+ Originals. Full HD Quality and
Stream on 2 devices simultaneously</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar Premium" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>2</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>1499</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Disney+ Movies, Hollywood Movies, Kids Content, English Shows, Disney+ Originals. Full HD Quality and
Stream on 2 devices simultaneously</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar Premium" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>3</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>VIP</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>399</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Dubbed Disney+ Movies Hollywood Movies Kids Content. HD Quality and Stream on 1
device</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar VIP" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>

BBPS API SPECIFICATIONS | Version 14.0

<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>1</Id>
<billerId>NETFLIX00NAT01</billerId>
<categoryType>Mobile</categoryType>
<amountInRupees>199</amountInRupees>
<planDescription>Watch on 1 mobile phone or tablet at a time in Standard Definition. Download videos on 1
phone or tablet</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Netflix Mobile Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>2</Id>
<billerId>NETFLIX00NAT01</billerId>
<categoryType>Basic</categoryType>
<amountInRupees>499</amountInRupees>
<planDescription>Watch on 1 screen (TV or Computer or Mobile Phone or Tablet) at a time in Standard
Definition. Download videos on 1 phone or tablet</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Netflix Basic Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>3</Id>
<billerId>NETFLIX00NAT01</billerId>
<categoryType>Standard</categoryType>
<amountInRupees>649</amountInRupees>
<planDescription>Watch on 2 screens at a time in Full HD(1080p). Download videos on 2 phones or
tablets</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Netflix Standard Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>4</Id>
<billerId>NETFLIX00NAT01</billerId>
<categoryType>Premium</categoryType>

BBPS API SPECIFICATIONS | Version 14.0

<amountInRupees>799</amountInRupees>
<planDescription>Watch on 4 screens at a time in Full HD(1080p) and Ultra HD(4k). Download videos on 4 phones
or tablets</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Netflix Premium Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
</bbps:BBPSPlanMDMPush>

Sample Plan MDM Pull Request API: BBPCU to Biller BBPOU

9.4.1Scheduled Pull:
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BBPSPlanMDMPull xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-11T18:00:13+05:30" origInst="BBCU"
refId="NQMOHTQBKHUZVYUWXEGYZKOU1P110421800" type="REQUEST" />
</bbps:BBPSPlanMDMPull>

9.4.2Ad-hoc Pull:
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BBPSPlanMDMPull xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-10T18:20:12+05:30" origInst="BBCU"
refId="GSPOQDAUAEHBZPAJFONIJOTD1ZZ10411820" type="REQUEST" />
<Search>
<billerId>HOTSTAR00NAT01</billerId>
<billerId>NETFLIX00NAT01</billerId>
<billerId>ZEE500000NAT01</billerId>
</Search>
<SearchByTime>
<time>2020-11-01T00:00:00+05:30</time>
</SearchByTime>
</bbps:BBPSPlanMDMPull>

Sample Plan MDM Push Request API: BBPCU to Customer

BBPOU / Participating AI
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BBPSPlanMDMPush xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T11:00:13+05:30" origInst="BBCU"
refId="WGMTEATHUURJHDZMDQFNLZPRKEA10431100" type="REQUEST/RESPONSE" />
<PlanDetails>
<Id>1</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>

BBPS API SPECIFICATIONS | Version 14.0

<categorySubType>
<subType>1 Month</subType>
</categorySubType>
<amountInRupees>99.0</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premium 1 Month Plan" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>2</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>3 Months</subType>
</categorySubType>
<amountInRupees>299.0</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 3 Months Plan" />
<Tag paramName="Package Duration" paramValue="3 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>3</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>6 Months</subType>
</categorySubType>
<amountInRupees>599.0</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 6 Months Plan" />
<Tag paramName="Package Duration" paramValue="6 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>

BBPS API SPECIFICATIONS | Version 14.0

<Id>4</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>999.0</amountInRupees>
<planDescription>All ZEE5 Originals and Exclusives, Blockbuster Movies, All ALT Balaji Shows, Zindagi TV Shows,
Kids, Live TV, TV shows before telecast. Watch on 5 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Premiun 12 Months Plan" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>5</Id>
<billerId>ZEE500000NAT01</billerId>
<categoryType>Club</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>365.0</amountInRupees>
<planDescription>TV shows before telecast, Select ZEE5 Originals, Select ALT Balaji Shows, Select Movies, Zindagi
TV Shows, Kids, Live TV. Watch on 2 devices at a time</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="ZEE5 Club 12 Months Plan" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>1</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>1 Month</subType>
</categorySubType>
<amountInRupees>299.0</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Disney+ Movies, Hollywood Movies, Kids Content, English Shows, Disney+ Originals. Full HD Quality and
Stream on 2 devices simultaneously</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar Premium" />
<Tag paramName="Package Duration" paramValue="1 Month" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>

BBPS API SPECIFICATIONS | Version 14.0

<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>2</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>Premium</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>1499.0</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Disney+ Movies, Hollywood Movies, Kids Content, English Shows, Disney+ Originals. Full HD Quality and
Stream on 2 devices simultaneously</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar Premium" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
<PlanDetails>
<Id>3</Id>
<billerId>HOTSTAR00NAT01</billerId>
<categoryType>VIP</categoryType>
<categorySubType>
<subType>12 Months</subType>
</categorySubType>
<amountInRupees>399.0</amountInRupees>
<planDescription>Unlimited Live Sports, Hotstar Specials and Star serials before TV, Multiples and New Indian
Movies, Dubbed Disney+ Movies Hollywood Movies Kids Content. HD Quality and Stream on 1
device</planDescription>
<planAdditionalInfo>
<Tag paramName="Package Name" paramValue="Disney+ Hotstar VIP" />
<Tag paramName="Package Duration" paramValue="12 Months" />
</planAdditionalInfo>
<effctvFrom>2021-01-01</effctvFrom>
<effctvTo>2021-12-31</effctvTo>
<status>ACTIVE</status>
</PlanDetails>
</bbps:BBPSPlanMDMPush>

Sample Plan MDM Pull Request API: Customer BBPOU /

Participating AI to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BBPSPlanMDMPull xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:07:30+05:30" origInst="OP01"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431207" type="REQUEST" />

BBPS API SPECIFICATIONS | Version 14.0

<Search>
<billerId>ZEE500000NAT01</billerId>
<billerId>HOTSTAR00NAT01</billerId>
<billerId>NETFLIX00NAT01</billerId>
</Search>
<SearchByTime>
<time>2021-02-04T10:00:00+05:30</time>
</SearchByTime>
</bbps:BBPSPlanMDMPull>

Plan MDM Push Request API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BBPSPlanMDMPu API Name 1..1
sh>
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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 type Indicates whether it is request/response. Possible values REQUEST 1..1
or RESPONSE
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
2.2 <PlanDetails > Captures all the plan details 1..n
2.2.1 <PlanDetails.Id> Unique ID against the Plan for a Biller 1..1
2.2.2 <PlanDetails.billerId> Biller ID against which Plan Details are shared 1..1
2.2.3 <PlanDetails.categoryTy Plan Category 1..1
pe>
2.2.4 <PlanDetails.categorySu Sub category of the Plan 0..1
bType>
2.2.4.1 <PlanDetails.categorySu Type of the Sub Category 1..n
bType.subType>
2.2.5 <PlanDetails.amountInR Plan Amount 1..1
upees>
2.2.6 <PlanDetails.planDescrip Plan Description 1..1
tion>
2.2.7 <PlanDetails.planAdditio Additional information parameters provided by the Biller for a Plan 0..1
nalInfo>
2.2.7.1 <PlanDetails.planAdditio Tag indicating any additional information provided by the Biller 1..n
nalInfo.Tag>
2.2.7.2 paramName Name of the field assigned by the Biller 1..n
2.2.7.3 paramValue Value of the field 1..n
2.2.8 <PlanDetails.effctvFrom> Effective From Date of the Plan 1..1
2.2.9 <PlanDetails.effctvTo> Effective To Date of the Plan 0..1
2.2.10 <PlanDetails.status> Status of the Plan. Possible values ACTIVE/DEACTIVATED 1..1

BBPS API SPECIFICATIONS | Version 14.0

Plan MDM Push 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="BillerFetchResponse.xsd" />
<xs:element name="BBPSPlanMDMPush" type="bbps:BBPSPlanMDMPushType">
<xs:annotation>
<xs:documentation>BBPS Plan MDM Push</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="BBPSPlanMDMPushType">
<xs:sequence>
<xs:element type="bbps:PlanHeadType" name="Head" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:PlanDetail" name="PlanDetails" minOccurs="0" maxOccurs="unbounded" />
<xs:element type="bbps:SearchResult" name="searchResult" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="PlanDetail">
<xs:sequence>
<xs:element type="xs:string" name="Id" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="billerId" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="categoryType" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:CategorySubType" name="categorySubType" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:double" name="amountInRupees" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="planDescription" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:PlanAdditionalInfo" name="planAdditionalInfo" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="effctvFrom" minOccurs="1" maxOccurs="1" />
<xs:element type="xs:string" name="effctvTo" minOccurs="0" maxOccurs="1" />
<xs:element type="xs:string" name="status" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="CategorySubType">
<xs:sequence>
<xs:element type="xs:string" name="subType" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="PlanAdditionalInfo">
<xs:sequence>
<xs:element name="Tag" maxOccurs="unbounded" minOccurs="1">
<xs:complexType>
<xs:attribute type="xs:string" name="paramName" use="required" />
<xs:attribute type="xs:string" name="paramValue" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PlanHeadType">
<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:attribute type="bbps:HeadRequestType" name="type" use="required" />
</xs:complexType>
<xs:simpleType name="HeadRequestType">
<xs:restriction base="xs:string">

BBPS API SPECIFICATIONS | Version 14.0

<xs:enumeration value="REQUEST" />

<xs:enumeration value="RESPONSE" />
</xs:restriction>
</xs:simpleType>
</xs:schema>

Plan MDM Pull Request API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BBPSPlanMDMPul API Name 1..1
l>
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 timestamp of the message which will be updated at each 1..1
leg
2.1.3 type Indicates whether it is request/response. Possible values REQUEST 1..1
or RESPONSE
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain, binding the
Fetch and Payment messages
2.2 <Search> Tag for searching the Plan details based on certain parameters 0..1
2.2.1 <Search.billerId> Biller ID for which the Plan details are requested 1..n
2.2.2 <SearchByTime> Tag for searching the plan details based on time parameter 0..1
2.2.3 <SearchByTime.time> Request for plan details for all the Billers updated in the system 1..1
after the time provided

Plan MDM Pull Request XSD

BBPS API SPECIFICATIONS | Version 14.0

10 Biller Status Check/Update APIs

XchangeId Request Type Description
601 Biller Fluctuation Request Fluctuations in Biller Services
602 Biller Deactivation Request Biller Services unavailable
603 Biller Activation Request Biller Services available

Sample Biller Status Update API: Biller BBPOU to BBPCU

<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerStatusUpdate xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:07:30+05:30" origInst="OU12"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431207" />
<Biller id="TSTO00000NAT01" xchangeId="601" startTime="2021-02-12T13:07:30+05:30" description="Fluctuation
in bill payment services for this biller" />
<Biller id="TEST00000NATNN" xchangeId="602" startTime="2021-02-12T13:07:30+05:30"
durationInMinutes="120" description="Biller not available to process payment" />
<Biller id="TEST00000NATAA" xchangeId="603" startTime="2021-02-12T13:07:30+05:30" description="Biller is
available to process payment" />
</bbps:BillerStatusUpdate>

Sample Biller Status Update API: BBPCU to Customer

BBPOUs/Participating AIs
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerStatusUpdate xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:30+05:30" origInst="BBCU"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
<Biller id="TSTO00000NAT01" xchangeId="601" startTime="2021-02-12T13:07:30+05:30" description="Fluctuation
in bill payment services for this biller" />
<Biller id="TEST00000NATNN" xchangeId="602" startTime="2021-02-12T13:07:30+05:30"
durationInMinutes="120" description="Biller not available to process payment" />
<Biller id="TEST00000NATAA" xchangeId="603" startTime="2021-02-12T13:07:30+05:30" description="Biller is
available to process payment" />
</bbps:BillerStatusUpdate>

Biller Status Update API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerStatusUpd API Name 1..1
ate>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain

BBPS API SPECIFICATIONS | Version 14.0

3.1 <Biller> Biller related data 1..n

3.1.1 <Biller.id> Unique identification code allocated to the Biller 1..1
3.1.2 <Biller.xchangeId> Identification of the type of request – Biller Fluctuation Request (601), 1..1
Biller Deactivation Request (602), Biller Activation Request (603)
3.1.3 <Biller.startTime> Start time of the Biller for the specific request 0..1
3.1.4 <Biller.durationInMinu Specifies the number of minutes the Biller will be down or facing 0..1
tes> fluctuations
3.1.5 <Biller.description> Reason for entity fluctuation / deactivation / activation 1..1

Biller Status Update XSD

Sample Biller Activation Check Request API: BBPCU to

Biller BBPOU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerActivationCheckRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:30+05:30" origInst="BBCU"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
<Search>
<billerId>TEST00000NATNN</billerId>
<billerId>TSTO00000NAT01</billerId>
</Search>
</bbps:BillerActivationCheckRequest>

BBPS API SPECIFICATIONS | Version 14.0

Sample Biller Activation Check Response API: Biller

BBPOU to BBPCU
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerActivationCheckResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:31+05:30" origInst="OU12"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
<Biller id="TEST00000NATNN" extendDownTime="TRUE" durationInMinutes="120" />
<Biller id="TSTO00000NAT01" extendDownTime="FALSE" />
</bbps:BillerActivationCheckResponse>

Biller Activation Check Request API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerActivation API Name 1..1
CheckRequest>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Search> Tag for searching the Biller details based on certain parameters 0..1
3.1.1 <Search.billerId> Biller ID for which the Biller Status was requested 1..n

Biller Activation Check Request XSD

Biller Activation Check Response API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerActivation API Name 1..1
CheckResponse>

BBPS API SPECIFICATIONS | Version 14.0

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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Biller> Biller related data 1..n
3.1.1 <Biller.id> Unique identification code allocated to the Biller 1..1
3.1.2 <Biller.extendDownTi Falg indicates whether down time needs to be ectnded or not. 1..1
me> Possible values TRUE/FALSE.
3.1.3 <Biller.durationInMinu Exdended down time duration of the Biller. 0..1
tes>

Biller Activation Check Response XSD

Sample Biller Status Check Request API:

BBPOU/Participating AI to BBPCU (Search by Biller Id)
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerStatusRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:30+05:30" origInst="OU01"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
<Search>
<billerId>GSTM00000MUM01</billerId>
<billerId>GSTM00000MUM02</billerId>
<billerId>GSTM00000MUM03</billerId>
</Search>
</bbps:BillerStatusRequest>

BBPS API SPECIFICATIONS | Version 14.0

Sample Biller Status Check Response API: BBPCU to

BBPOU/Participating AI
<?xml version="1.0" encoding="UTF-8"?>
<bbps:BillerStatusResponse xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:30+05:30" origInst="BBCU"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
<Biller id="GSTM00000MUM01" xchangeID="602" status="FLUCTUATING" startTime="2021-02-
12T11:09:30+05:30" description="Fluctuation in bill payment services for this biller" />
<Biller id="GSTM00000MUM02" xchangeID="601" status="DISABLED" startTime="2021-02-12T11:09:30+05:30"
description="Biller is currently not available to process payment" />
<Biller id="GSTM00000MUM03" status="ACTIVE" description="Biller is available for processing transactions" />
</bbps:BillerStatusResponse>

Sample Biller Status Check Request API:

BBPOU/Participating AI to BBPCU (without Search
Parameter)
Note: Whenever OU/AI initiates Biller Status Check request without any search parameter, system will give all the
Disabled and Fluctuating Biller details as response back to OU/AI.

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

<bbps:BillerStatusRequest xmlns:bbps="http://bbps.org/schema">
<Head ver="1.0" ts="2021-02-12T12:09:30+05:30" origInst="OU01"
refId="YWPNSPVBPVPWDALTOMJSNBFQNOS10431209" />
</bbps:BillerStatusRequest>

Biller Status Check Request API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerStatusReq API Name 1..1
uest>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Search> Tag for searching the Biller details based on certain parameters 0..1
3.1.1 <Search.billerId> Biller ID for which the Biller Status was requested 1..n

Biller Status Check Request XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:include schemaLocation="BBPS-Common.xsd" />

<xs:element name="BillerStatusRequest" type="bbps:BillerStatusRequestType">
<xs:annotation>
<xs:documentation>Biller Status Request</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="BillerStatusRequestType">
<xs:sequence>
<xs:element type="bbps:headType" name="Head" minOccurs="1" maxOccurs="1" />
<xs:element type="bbps:search" name="Search" minOccurs="0" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:schema>

Biller Status Check Response API Tag Details

Index XML Element Description Occurrence
1.1 <bbps:BillerStatusResp API Name 1..1
onse>
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 timestamp of the message 1..1
2.1.3 origInst Code assigned to the BBPOU / BBPCU which forwards the transaction 1..1
2.1.4 refId Unique identification assigned by the initiating BBPOU to 1..1
unambiguously identify the transaction which is passed on,
unchanged, throughout the entire end-to-end chain
3.1 <Biller> Biller related data 1..n
3.1.1 <Biller.id> Unique identification code allocated to the Biller 1..1
3.1.2 <Biller.xchangeId> Identification of the type of request – Biller Fluctuation Request (601), 1..1
Biller Deactivation Request (602), Biller Activation Request (603)
3.1.3 <Biller.status> Specifies the number of minutes the Biller will be down or facing 1..1
fluctuations
3.1.4 <Biller.startTime> Start time of the Biller Status for the specific request 0..1
3.1.5 <Biller.description> Reason for entity fluctuation / deactivation / activation 1..1

Biller Activation Check Response XSD

BBPS API SPECIFICATIONS | Version 14.0

<xs:attribute type="xs:string" name="id" />

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

11 Acknowledgment
Sample ACK for Fetch & Payment APIs
<?xml version="1.0" encoding="UTF-8"?>
<bbps:Ack xmlns:bbps="http://bbps.org/schema" api="PAYMENT_REQUEST"
refId="LNMSQQR4RKT7X1UGPY7JGUV454PL9T2C689" msgId="HENSVVR4QOS7X1UGPY7JGUV444P10461713"
RspCd="Successful/VALIDATION_ERR/DUPLICATE_REQ" ts="2021-02-15T17:13:46+05:30">
<errorMessages>
<errorCd>CPR001</errorCd>
<errorDtl> CustomerParams mandatory</errorDtl>
</errorMessages>
</bbps:Ack>

Sample ACK for Other APIs

<?xml version="1.0" encoding="UTF-8"?>
<bbps:Ack xmlns:bbps="http://bbps.org/schema" api="TxnStatusComplainRequest"
refId="HENSVVR4QOS7X1UGPY7JGUV444P10461713" RspCd="Successful/VALIDATION_ERR/DUPLICATE_REQ"
ts="2021-02-15T17:13:46+05:30">
<errorMessages>
<errorCd>CMR101</errorCd>
<errorDtl>Complaint Management - Exchange Id not supported</errorDtl>
</errorMessages>
</bbps:Ack>

Acknowledgment Tag Details

Index XML Element Description Occurrence
1.1 <bbps:Ack> API Name 1..1
1.1.1 xmlns API schema namespace 1..1
1.1.2 api Name of the API for which acknowledgement is given out 1..1
1.1.3 refId Reference ID corresponding to the initiating request or response 1..1
for which the acknowledgement is sent
1.1.4 msgId Message ID corresponding to the initiating request or response for 0..1
which the acknowledgement is sent – only applicable for fetch and
payment APIs
1.1.5 RspCd Denotes success or failure in receiving the original request 1..1
message
1.1.6 ts Transmission date and time of the transaction 1..1
2.1 <errorMessages> List of error(s) in the request or response message 0..n
2.2 <errorMessages.errorCd> Code of the error 1..1

BBPS API SPECIFICATIONS | Version 14.0

2.3 <errorMessages.errorDtl> Description of the error 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: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>

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" />

BBPS API SPECIFICATIONS | Version 14.0

<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="offUsPayType">
<xs:restriction base="xs:string">
<xs:enumeration value="Yes" />
<xs:enumeration value="No" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="siTxnType">
<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" />

BBPS API SPECIFICATIONS | Version 14.0

<xs:attribute type="xs:string" name="refId" use="required" />

<xs:attribute type="xs:string" name="origRefId" use="optional" />
<xs:attribute type="bbps:siTxnType" name="siTxn" use="optional" />
</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:attribute type="bbps:directBillChannelType" name="directBillChannel" use="optional" />
<xs:attribute type="xs:string" name="directBillContentId" use="optional" />



<xs:attribute type="xs:string" name="paymentRefId" use="optional" />

</xs:complexType>

<xs:simpleType name="directBillChannelType">
<xs:restriction base="xs:string">
<xs:enumeration value="L1QR" />
<xs:enumeration value="L2QR" />
<xs:enumeration value="L3QR" />
<xs:enumeration value="L1PL" />
<xs:enumeration value="L2PL" />
<xs:enumeration value="L3PL" />
</xs:restriction>

BBPS API SPECIFICATIONS | Version 14.0

</xs:simpleType>
<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>

BBPS API SPECIFICATIONS | Version 14.0

<xs:attribute type="xs:string" name="customerName" use="optional" />

<xs:attribute type="xs:string" name="amount" use="required" />
<xs:attribute type="xs:string" name="dueDate" use="optional" />
<xs:attribute type="xs:string" name="custConvFee" use="optional" />
<xs:attribute type="xs:string" name="billDate" use="optional" />
<xs:attribute type="xs:string" name="billNumber" use="optional" />
<xs:attribute type="xs:string" name="billPeriod" use="optional" />
</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="bbps:offUsPayType" name="OFFUSPay" use="optional" />
<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:attribute type="xs:string" name="COUcustConvFee" use="optional" />
</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>

BBPS API SPECIFICATIONS | Version 14.0

<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:complexType name="search">
<xs:sequence>
<xs:element type="xs:string" name="billerId" minOccurs="1" maxOccurs="unbounded" />
</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#rsa-sha1" />
<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>kQYYeIFygZzHrwGxxfcah8YNO2QROfW7k85yeSK0YkE=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>VzOIbjYChpNmoCfq4GmY1w33Vnt2envQNBDUERfQLWXwe/pzNXK6cRQcZONUPi3SBmdu9Iyv8vTx
R+rPfNian+wEpuReOm23CuyasgtTGp+uf3QIyqhlCuZlR65ZfUhpFEraShYdRIOzfGFAiyGnG7Fl
Ilf4q/7mgCQjOw7/paAFiK0h5ERT909PeArLL4isA6KOkindYpTOkAyAGC3t2AJDVJP4SujHbRwx
BmcdPbfvMt6aY3n/u5pL/d6XlebWW2l6DhIGSTSBrwx+S2l9EvkRJvKZncNJDbWdUKy2mM0H4YSD
javG0rqE2u5CPftUWvHxiiwwqizyOEKMILMOyg==</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>vCidzRWCs8Mukb1E/R1JGCgexwhiDfQDuO0tPHXgX+SDdBptkr+1ThjSBW2D+kH6ZLc22EAL9o/o
zBVIJgWwMw4b0LlsdK0dEYjZiFiwFY1AlO4kLB48J2PwZ5Ly2ADKP+CzpZ7YhPNUz7tGCqiKyM3E
IXWqvzS1Yb4+zYardGBtUkLAJDNDltSgyDe/Fb27viTTxsps2rTZ7VZCWRGyCON5F149EVXnVFUt
SD1oye1x1IxDcfYEc49OAa+BZiheGMpNpzkCR263CFbe0UnQbuQwz9eaoPuCn5tQBxFv5v4/Ho1W
zbTZBSSf2Ow1N6fqXzWLw444Ea5ftyNpDq+HUw==</Modulus>
<Exponent>Aw==</Exponent>
</RSAKeyValue>

BBPS API SPECIFICATIONS | Version 14.0

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

14 URLs for Different API Messages

Request URL format (Customer BBPOU / Participating AI to
BBPCU):
Request Type Service URL
Bill Fetch Request <Base URL>/bbps/BillFetchRequest/1.0/urn:referenceId:{referenceId}
Bill Payment Request <Base URL>/bbps/BillPaymentRequest/1.0/urn:referenceId:{referenceId}
Bill Validation Request <Base URL>/bbps/BillValidationRequest/1.0/urn:referenceId:{referenceId}
Plan MDM Pull <Base URL>/bbps/planMDMPullCouToCu/1.0/urn:referenceId:

Request URL format (BBPCU to Biller BBPOU):

Request Type Service URL
Bill Fetch Request <Endpoint URL >/BillFetchRequest/1.0/urn:referenceId:{referenceId}
Bill Payment Request <Endpoint URL>/BillPaymentRequest/1.0/urn:referenceId:{referenceId}
Bill Validation Request <Endpoint URL>/BillValidationRequest/1.0/urn:referenceId:{referenceId}
Txn Status Request 402 <Endpoint URL>/TxnStatusRequest402/1.0/urn:referenceId:{referenceId}
Plan MDM Pull <Endpoint URL>/planMDMPullCuToBou/1.0/urn:referenceId:{referenceId}
Biller Activation Check Request <Endpoint URL>/BillerActivationCheckRequest

Response URL format (Biller BBPOU to BBPCU):

Response Type Service_url
Bill Fetch Response <Base URL>/bbps/BillFetchResponse/1.0/urn:referenceId:
Bill Payment Response <Base URL>/bbps/BillPaymentResponse/1.0/urn:referenceId:
Bill Validation Response <Base URL>/bbps/BillValidationResponse/1.0/urn:referenceId:
Txn Status Response 402 <Base URL>/bbps/TxnStatusResponse402/1.0/urn:referenceId:
Plan MDM Push <Base URL>/bbps/planMDMPushBouToCu/1.0/urn:referenceId:
Biller Status Update <Base URL>/BillerStatusUpdate
Biller Activation Check Response <Base URL>/BillerActivationResponse

Response URL format (BBPCU to Customer BBPOU /

Participating AI):
Response Type Service_url
Bill Fetch Response <Endpoint URL>/BillFetchResponse/1.0/urn:referenceId:
Bill Payment Response <Endpoint URL>/BillPaymentResponse/1.0/urn:referenceId:
Bill Validation Response <Endpoint URL>/BillValidationResponse/1.0/urn:referenceId:

BBPS API SPECIFICATIONS | Version 14.0

Plan MDM Push <Endpoint URL>/planMDMPushCuToCou/1.0/urn:referenceId:

Biller Status Update <Endpoint URL>/BillerStatusUpdate

Request URL format (BBPOU / Participating AI to BBPCU):

Request Type Service URL
Diagnostic Request <Base URL>/bbps/ReqHbt/1.0/urn:referenceId: {referenceId}
Complaint Request – (existing) <Base URL>/CMS/TxnStatusComplainRequest
Complaint Request – (new) <Base URL>/CMS/TxnStatusComplainRequest/V2
Biller MDM <Base URL>/bbps/BillerFetchRequest/1.0/urn:referenceId:{referenceId}
Agent MDM <Base URL>/bbps/AgentFetchRequest/1.0/urn:referenceId:{referenceId}
Biller Status Check Request <Base URL>/BillerStatusRequest

Response URL format (BBPCU to BBPOU/Participating AI):

Response Type Service_url
Complaint Response <Endpoint URL>/TxnStatusComplainResponse
Biller MDM <Endpoint URL>/BillerFetchResponse/1.0/urn:referenceId:
Agent MDM <Endpoint URL>/AgentFetchResponse/1.0/urn:referenceId:
Biller Status Check Response <Endpoint URL>/BillerStatusResponse

BBPS API SPECIFICATIONS | Version 14.0

15 Error Codes and Declines

The codes for the system can be configured as follows:
S. No. Scenario Response Code Response Reason

1 Forward Request / Response 000 Successful

2 Force Closed Transactions 100 Failure
3 Reversals 101 – 199 Failure
4 CU declines 001 – 099 Failure
5 BOU Declines 200 – 299 Failure
6 COU Declines 300 – 399 Failure

For all the above response codes, there will be corresponding compliance response codes and compliance reasons.
Compliance response code will follow the following nomenclature.

Compliance Code Compliance Reason Explanation

XXX111 Description of the error Where XXX are alpha characters and 111 are numeric characters

All the compliance codes and their reasons will be accessible through a table and any modification to the list will be
possible.

BBPCU Declines
Under BBPCU declines, there will be list of compliance codes and compliance reasons for each tag / attribute. Please
note that the following terms have been used interchangeably in the following table:

 BBPCU and CU
 Customer BBPOU and Customer OU / COU
 Biller BBPOU and Biller OU / BOU
Leg Scenario Fetch / Validation Payment
COU  CU CU receives malformed CU declines COU request with a negative CU declines COU request with a negative
request from COU. ACK. ACK.

No other response from CU is required as No other response from CU is required as

all Error Codes are populated as part of all Error Codes are populated as part of
the Negative ACK from CU. the Negative ACK from CU.
CU  BOU CU unable to connect to CU initiates a Response Code 001 and CU initiates a Response Code 001 and
BOU even after multiple Response Reason "Failure" decline to Response Reason "Failure" decline to
retries. COU. COU.

Compliance Response Code will be Compliance Response Code will be

BOU006 and Compliance Reason will carry BOU006 and Compliance Reason will carry
"Connect Timeout at BOU". "Connect Timeout at BOU".

TYPE: FORWARD TYPE RESPONSE

CU makes multiple retry CU initiates a Response Code 001 and CU initiates a Response Code 001 and
attempts without any Response Reason "Failure" decline to Response Reason "Failure" decline to
success in any of the COU. COU.
following cases:
 No ACK by BOU (ACK Compliance Response Code will be Compliance Response Code will be
relaxation disabled) BOU007 and Compliance Reason will carry BOU007 and Compliance Reason will carry
 Delayed ACK by BOU "Read Timeout at BOU". "Read Timeout at BOU".

BBPS API SPECIFICATIONS | Version 14.0

(beyond timeout
period) TYPE: FORWARD TYPE RESPONSE
 Positive ACK by BOU
but not reaching CU

Any other generic reason CU initiates a Response Code 001 and CU initiates a Response Code 001 and
for request failure to Response Reason "Failure" decline to Response Reason "Failure" decline to
BOU, e.g., Connection COU. COU.
Reset, Connection
Refused, Bad Gateway, Compliance Response Code will be Compliance Response Code will be
Internal Server Error, BOU008 and Compliance Reason will carry BOU008 and Compliance Reason will carry
Null Pointer Exception, "Unable to Connect to BOU". "Unable to Connect to BOU".
etc.
TYPE: FORWARD TYPE RESPONSE
BOU is temporarily down CU initiates a Response Code 001 and CU initiates a Response Code 001 and
(BOU is not sending Response Reason "Failure" decline to Response Reason "Failure" decline to
diagnostic request). COU. COU.

Compliance Response Code will be Compliance Response Code will be

BOU001 and Compliance Reason will carry BOU001 and Compliance Reason will carry
"Send Failed to BOU". "Send Failed to BOU".

TYPE: FORWARD TYPE RESPONSE

CU forwards the request CU initiates a Response Code 001 and CU initiates a Response Code 001 and
to BOU but BOU declines Response Reason "Failure" decline to Response Reason "Failure" decline to
with a negative ACK. COU. COU.

Compliance Response Code will be Compliance Response Code will be

BOU002 and Compliance Reason will carry BOU002 and Compliance Reason will carry
"<all the Error Codes from Negative "<all the Error Codes from Negative
ACK>". ACK>".

TYPE: FORWARD TYPE RESPONSE

Timeout for request sent CU initiates a Response Code 001 and CU initiates a Response Code 001 and
to BOU, i.e., Response Response Reason "Failure" decline to Response Reason "Failure" decline to
Timeout by BOU. COU. COU.

Compliance Response Code will be Compliance Response Code will be

BOU003 and Compliance Reason will carry BOU003 and Compliance Reason will carry
"Timeout at BOU". "Timeout at BOU".

TYPE: FORWARD TYPE RESPONSE

Pending Transaction NA CU initiates a Response Code 001 and
Timeout for request sent Response Reason "Failure" decline to
to BOU, i.e., Response COU.
Timeout by BOU.
Compliance Response Code will be
BOU009 and Compliance Reason will carry
"Pending Transaction Timeout at BOU".

TYPE: FORWARD TYPE RESPONSE

BOU  CU BOU responds, but with CU initiates a Response Code 002 and Pending not applicable:
malformed response. CU Response Reason "Failure" decline to
rejects the BOU COU. CU initiates a Response Code 002 and
response with negative Response Reason "Failure" decline to
ACK and allows BOU to Compliance Response Code will be COU.

BBPS API SPECIFICATIONS | Version 14.0

retry within the timeout BOU002 and Compliance Reason will carry
period. Yet, there is no "<all the Error Codes from Negative Compliance Response Code will be
proper response from ACK>". BOU002 and Compliance Reason will carry
BOU within this timeout "<all the Error Codes from Negative
period. ACK>".

TYPE: FORWARD TYPE RESPONSE

Pending applicable:

CU declines response given by BOU with a

negative ACK and initiate 402 API to BOU
to check the status of the transaction at
pre-defined interval till Biller Timeout
Period.
CU COU CU unable to connect to For a successful BOU -> CU response: For a successful BOU -> CU response:
COU even after multiple
retries. CU closes and records the transaction with CU closes and records the transaction with
a Response Code 000 and Response a Response Code 000 and Response
Reason "Successful". Reason "Successful".

As a distinguishing identifier from As a distinguishing identifier from

successfully acknowledged responses, successfully acknowledged responses,
Compliance Response Code will be Compliance Response Code will be
COU006 and Compliance Reason will carry COU006 and Compliance Reason will carry
"Connect Timeout at COU". "Connect Timeout at COU".

For a failed BOU -> CU response: For a failed BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 003 and Response a Response Code 003 and Response
Reason "Failure". Reason "Failure".

Compliance Response Code will be Compliance Response Code will be

COU006 and Compliance Reason will carry COU006 and Compliance Reason will carry
"<Compliance Code between BOU to "<Compliance Code between BOU to
CU>, Connect Timeout at COU". CU>, Connect Timeout at COU".

TYPE: FORWARD TYPE RESPONSE

CU makes multiple retry For a successful BOU -> CU response: For a successful BOU -> CU response:
attempts without any
success in any of the CU closes and records the transaction with CU closes and records the transaction with
following cases: a Response Code 000 and Response a Response Code 000 and Response
 No ACK by COU Reason "Successful". Reason "Successful".
 Delayed ACK by COU
(beyond timeout As a distinguishing identifier from As a distinguishing identifier from
period) successfully acknowledged responses, successfully acknowledged responses,
 Positive ACK by COU Compliance Response Code will be Compliance Response Code will be
but not reaching CU COU007 and Compliance Reason will carry COU007 and Compliance Reason will carry
"Read Timeout at COU". "Read Timeout at COU".

For a failed BOU -> CU response: For a failed BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 003 and Response a Response Code 003 and Response
Reason "Failure". Reason "Failure".

BBPS API SPECIFICATIONS | Version 14.0

Compliance Response Code will be Compliance Response Code will be

COU007 and Compliance Reason will carry COU007 and Compliance Reason will carry
"<Compliance Code between BOU to "<Compliance Code between BOU to
CU>, Read Timeout at COU". CU>, Read Timeout at COU".

TYPE: FORWARD TYPE RESPONSE

Any other generic reason For a successful BOU -> CU response: For a successful BOU -> CU response:
for response failure to
COU, e.g., Connection CU closes and records the transaction with CU closes and records the transaction with
Reset, Connection a Response Code 000 and Response a Response Code 000 and Response
Refused, Bad Gateway, Reason "Successful". Reason "Successful".
Internal Server Error,
Null Pointer Exception, As a distinguishing identifier from As a distinguishing identifier from
etc. successfully acknowledged responses, successfully acknowledged responses,
Compliance Response Code will be Compliance Response Code will be
COU008 and Compliance Reason will carry COU008 and Compliance Reason will carry
"Unable to Connect to COU". "Unable to Connect to COU".

For a failed BOU -> CU response: For a failed BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 003 and Response a Response Code 003 and Response
Reason "Failure". Reason "Failure".

Compliance Response Code will be Compliance Response Code will be

COU008 and Compliance Reason will carry COU008 and Compliance Reason will carry
"<Compliance Code between BOU to "<Compliance Code between BOU to
CU>, Unable to Connect to COU". CU>, Unable to Connect to COU".

TYPE: FORWARD TYPE RESPONSE

COU is temporarily down For a successful BOU -> CU response: For a successful BOU -> CU response:
(COU is not sending
diagnostic request). CU closes and records the transaction with CU closes and records the transaction with
a Response Code 000 and Response a Response Code 000 and Response
Reason "Successful". Reason "Successful".

As a distinguishing identifier from As a distinguishing identifier from

successfully acknowledged responses, successfully acknowledged responses,
Compliance Response Code will be Compliance Response Code will be
COU001 and Compliance Reason will carry COU001 and Compliance Reason will carry
"Send Failed to COU". "Send Failed to COU".

For a failed BOU -> CU response: For a failed BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 003 and Response a Response Code 003 and Response
Reason "Failure". Reason "Failure".

Compliance Response Code will be Compliance Response Code will be

COU001 and Compliance Reason will carry COU001 and Compliance Reason will carry
"<Compliance Code between BOU to "<Compliance Code between BOU to
CU>, Send Failed to COU". CU>, Send Failed to COU".

TYPE: FORWARD TYPE RESPONSE

CU forwards the No other response from CU is required No other response from CU is required
response to COU but towards COU. Do away with negative ACK towards COU. Do away with negative ACK

BBPS API SPECIFICATIONS | Version 14.0

COU declines with a by COU. by COU.

negative ACK.
For a successful BOU -> CU response: For a successful BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 000 and Response a Response Code 000 and Response
Reason "Successful". Reason "Successful".

As a distinguishing identifier from As a distinguishing identifier from

successfully acknowledged responses, successfully acknowledged responses,
Compliance Response Code will be Compliance Response Code will be
COU002 and Compliance Reason will carry COU002 and Compliance Reason will carry
all the Error Codes from Negative ACK. all the Error Codes from Negative ACK.

Note: COU can raise a complaint for the

respective transaction if required.

For a failed BOU -> CU response: For a failed BOU -> CU response:

CU closes and records the transaction with CU closes and records the transaction with
a Response Code 003 and Response a Response Code 003 and Response
Reason "Failure". Reason "Failure".

Compliance Response Code will be Compliance Response Code will be

COU002 and Compliance Reason will carry COU002 and Compliance Reason will carry
"<Compliance Code between BOU to "<Compliance Code between BOU to
CU>, <all the Error Codes from Negative CU>, <all the Error Codes from Negative
ACK>". ACK>".

TYPE: FORWARD TYPE RESPONSE

For the Billers, which does not support deemed success; the existing response codes and compliance codes will be
applicable (as mentioned below).
Leg Scenario Fetch / Validation Payment
CU COU Send Failed for response CU closes and records the transaction with CU will initiate a Reversal request to BOU.
sent to COU. a Response Code 001 and Response BOU will send a Reversal Response with
Reason “Failure”. Response Code 103 and Response Reason
Compliance Response Code will be “Failure”. On its way back to COU, the CU
COU001 and Compliance Reason will carry populates Compliance Response Code as
“Send Failed to COU”. COU001 and Compliance Reason will carry
“Send Failed to COU”.
If COU is down at that moment, it will be
retried till the point it is successfully
delivered.

Type : REVERSAL TYPE RESPONSE

CU forwards the No other response from CU is required CU will initiate a Reversal request to BOU.
response to COU but towards COU. CU closes and records the BOU will send a Reversal Response with
COU declines with a transaction with a Response Code 301 and Response Code 103 and Response Reason
negative ACK. Response Reason “Failure”. “Failure”. On its way back to COU, the CU
Compliance Response Code will be populates Compliance Response Code as
COU002 and Compliance Reason will carry COU002 and Compliance Reason will carry
"<all the Error Codes from Negative "<all the Error Codes from Negative
ACK>". ACK>".
If COU is down at that moment, it will be
retried till the point it is successfully

BBPS API SPECIFICATIONS | Version 14.0

delivered.

Type : REVERSAL TYPE RESPONSE

Biller BBPOU Declines

There are scenarios which can emerge when there are issues between BOU and the Biller. List of Compliance Codes
which has to be populated at the time of BOU business rejections are as follows:
Response Compliance Compliance Description
Code Code
Bill Fetch
200 BFR001 Incorrect / invalid Customer account
200 BFR002 Invalid combination of Customer parameters
200 BFR003 No bill data available
200 BFR004 Payment received for the billing period - no bill due
200 BFR005 Customer account is blocked / closed
200 BFR006 Customer account is not activated
200 BFR007 Bill due date has expired - bill details are not available
200 BFR008 Unable to get bill details from Biller
200 BFR009 Scheduled downtime taken by biller for maintenance activity. Please try again later
200 BFR010 Unscheduled downtime taken by biller for maintenance activity. Please try again later
200 BFR011 Incomplete details in Biller system - update Customer profile
200 BFR012 ePayment not enabled for the dealer
200 BFR013 Maximum Refill Count Has Been Reached. {schemename} consumers can get maximum
{RefillPerYear} refills in a year.
200 BFR014 This consumer has reported loss of cylinder
200 BFR015 Can not take booking as the consumer not yet submitted KYC.
200 BFR016 One prior booking is pending against this Consumer
200 BFR017 Price not yet set for Nature code - {NatureCode} and Package Code - {ItemDescription}
200 BFR018 Day-End not done. Please try after some time
200 BFR019 Consumer No. and Distributor not matching
200 BFR020 LPGId not found
200 BFR021 Vehicle Registered Number entered is not exists or Invalid
200 BFR022 Entered Fastag is Inactive/blocked. Recharge not allowed
200 BFR023 Entered Fastag is exempted. Recharge not allowed
Bill Payment
200 BPR001 Incorrect / invalid Customer account
200 BPR002 Invalid combination of Customer parameters
200 BPR003 Customer account is blocked / closed
200 BPR004 Customer account is not activated
200 BPR005 Payment cannot be accepted at this time
200 BPR006 Payment request has been exceeded for the day
200 BPR007 Repeat payment request
200 BPR008 Due date has been expired to pay this amount. Please re-fetch again to get the current
outstanding

BBPS API SPECIFICATIONS | Version 14.0

200 BPR009 Scheduled downtime taken by biller for maintenance activity. Please try again later
200 BPR010 Unscheduled downtime taken by biller for maintenance activity. Please try again later
200 BPR011 Payment Amount is different from current outstanding Amount
200 BPR012 FASTag Top-up is failed, Please try again later
Bill Validation
200 BVR001 Incorrect / invalid Customer account
200 BVR002 Invalid combination of Customer parameters
200 BVR003 Customer account is blocked / closed
200 BVR004 Customer account is not activated
200 BVR005 Invalid Amount
200 BVR006 Customer account deactivated - pay Rs. <xxx> to activate account
200 BVR007 Incomplete details in Biller system - update Customer profile
200 BVR008 Customer account valid but no bill due
200 BVR009 Technical exception from biller
200 Future Incorrect / Invalid Plan ID
Purpose
200 Future No recharge found for Plan ID and Customer account combination
Purpose

Some of the Biller BBPOU decline scenarios are as follows:

MTI Scenario Expected Biller Response Parameters Expected Reason Block Codes
Fetch Incorrect / invalid Biller Response block not required Response Code = 200
customer account Response Reason = Failure
Compliance Response Code = BFR001
Compliance Reason = Incorrect / invalid
customer account

Fetch Customer account is valid & Biller Response block not required Response Code = 200
bill data is not available Response Reason = Failure
Compliance Response Code = BFR003
Response Code = No bill data available

Fetch Customer account is Biller Response block not required Response Code = 200
valid & no bill due Response Reason = Failure
Compliance Response Code = BFR004
Compliance Reason = Payment received
for the billing period - no bill due

Payment Bill pay without fetch  Customer Name = As Is (NA if Response Code = 000
Customer Name in unavailable) Response Reason = Successful
 Amount = <copy amount value Compliance Response Code = <blank>
from BP Req> Compliance Reason = <blank>
 Due Date = 0001-01-01
 Bill Date = 0001-01-01
 Bill Number = NA
 Bill Period = NA
 Customer Convenience Fee =

BBPS API SPECIFICATIONS | Version 14.0

<copy custConvFee value from BP

Req>

Payment Customer account not Biller Response block not required Response Code = 200
found Response Reason = Failure
Compliance Response Code = BPR001
Compliance Reason = Incorrect / invalid
customer account

Customer BBPOU Declines

There are scenarios which can emerge when there are issues between Customer BBPOU and its Frontend. Customer
BBPOU can decline certain transactions which then need to be appropriately captured.

List of Compliance Codes which has to be populated at the time of Customer BBPOU rejections are as follows:
Compliance Code Compliance Description
BFS001 Front end channel unavailable
BFS002 Customer has initiated reversal
BFS003 Receipt not generated
BFS004 Unable to process transaction internally

Forced Closure of Transactions by CU

Please refer to the diagram below for Payment leg of a transaction with Legs 1-4 constituting the Payment legs and
Legs 5-7 constituting the Reversal legs as per the existing BBPS payment process flow.

Figure 1: Payment and its subsequent Reversal

For the Billers, which does not support Deemed Success, when the Payment request initiated from Customer OU is
processed successfully and a positive response is provided by the Biller OU (Legs 1 – 3). For some reason (COU001 or
COU002) when Leg 4 of the transaction fails, CU will generate a Reversal Request and send it to the BOU (Leg 5). BOU
then generates a Reversal Response to BOU (Leg 6) which is ultimately forwarded to the COU (Leg 7).

All these “open” transactions (both FETCH and PAYMENT) without any assigned Response or Compliance Codes in
the transaction table even after a significant period of time. Such transactions need to be force closed by CU (moved

BBPS API SPECIFICATIONS | Version 14.0

from transaction to reporting tables) after a certain interval (say, a configurable value of 4 hours) using the following
combination of Response and Compliance Codes.
S. Description Response Response Compliance Compliance Reason*
No. Code Reason Code
1 CU is not able to connect to the BOU for 100 Failure BOU004 <COU001/COU002>,
forwarding the Reversal Request BOU Reversal Retry Failure
2 BOU has not provided an ACK for the 100 Failure BOU004 <COU001/COU002>,
Reversal Request BOU Reversal Retry Failure
3 BOU has provided a negative ACK for the 100 Failure BOU004 <COU001/COU002>,
Reversal Request BOU Reversal Retry Failure
4 BOU has acknowledged the Reversal 100 Failure BOU005 <COU001/COU002>,
Request, but has not sent or has sent a BOU Reversal Response Timeout
malformed Reversal Response
5 CU is not able to connect to the COU for 100 Failure COU003 <COU001/COU002>,
forwarding the Reversal Response COU Reversal Retry Failure
6 COU has not provided an ACK for the 100 Failure COU003 <COU001/COU002>,
Reversal Response COU Reversal Retry Failure
7 COU has provided a negative ACK for the 100 Failure COU003 <COU001/COU002>,
Reversal Response COU Reversal Retry Failure
For the Billers which does not support Deemed Success

The revised CU decline scenarios effectively eliminate the Reversal legs because of the manner in which a failure in
Leg 4 of the transaction is handled for the billers which support Deemed Success. Thus, some transactions remaining
incomplete in the transaction table (OLTP) if one of Legs 5, 6 or 7 fails will no longer be a possibility and will not
require any forced closure by CU.

However, there may be exceptional scenarios like some “open” transactions (both FETCH and PAYMENT) without
any assigned Response or Compliance Codes in the transaction table even after a significant period of time. Such
transactions need to be force closed by CU (moved from transaction to reporting tables) after a certain interval (say,
a configurable value of 4 hours) using the following combination of Response and Compliance Codes.
S. No. Description Response Code Response Reason Compliance Code Compliance Reason
1 Leg 2 (CU to BOU) failure 100 Failure BOU001 Send Failed to BOU
2 Leg 3 (BOU to CU) failure 100 Failure BOU003 Timeout at BOU
3 Leg 4 (CU to COU) failure As sent by BOU As sent by BOU COU001 Send Failed to COU
For the Billers which support Deemed Success

For Leg 4 failure, system will consider the response given by the BOU as the final status for the biller which support
deemed success even for force closure.

BBPS API SPECIFICATIONS | Version 14.0

16 Re-utilization of Fetch / Validation for

Registered Customers
In BBPS for billers supporting Fetch/Validation it may be noted that fetch/validation and payment transactions are
linked through Reference ID. Currently, if a Reference ID is consumed by COU for making a payment once, it cannot
use the same fetch/validation response to initiate another payment using the same Reference ID (unless it is a CU
rejected payment transaction where COUs are expected to re-initiate the payment using the same Reference ID).

Currently, for re-attempting a payment, in case of non CU rejected payment transactions, COUs are expected to re-
fetch the bill (or re-validate the customer params) and then initiate a payment for the same.

Basis the market feedback, we are allowing the Fetch response to be re-utilized only for registered customers, till
payment is successfully posted within 2 days of first try of the Payment. However, if COUs intend to reuse the
Validation response for making multiple retries till payment is successful, the ageing period will be 24 hrs of
successful Validation. In order to reutilize the Fetch/Validation response for multiple payment retries, COUs will be
required to pass siTxn attribute value as ‘Yes’ in all the payment requests mandatorily.

S. No. Activity Sender Receiver Reference ID Message Transaction Original

ID ref ID Reference ID
1 Bill Fetch Request COU CU R1 M1 - -
CU BOU R1 M1 - -
2 Bill Fetch Response BOU CU R1 M1 - -
CU COU R1 M1 - -
3 Bill Payment Request (1st Attempt) COU CU R1 M2 T1 -
CU BOU R1 M2 T1 -
4 Bill Payment Response BOU CU R1 M2 T1 -
CU COU R1 M2 T1 -
5 Bill Payment Request (2nd Attempt) COU CU R2 M3 T2 R1
Can be done if previous attempt was
FAILED.
CU BOU R2 M3 T2 R1
6 Bill Payment Response BOU CU R2 M3 T2 R1
CU COU R2 M3 T2 R1
7 Bill Payment Request (3rd Attempt) COU CU R3 M4 T3 R1
Can be done if previous attempts are
FAILED.
CU BOU R3 M4 T3 R1
8 Bill Payment Response (Successful) BOU CU R3 M4 T3 R1
CU COU R3 M4 T3 R1

Considerations for Customer OUs

1. Reutilization of Fetch / Validation functionality is only for registered customers.
2. This functionality can be used on Digital Channels Only and will not be available for Physical Channels.
3. CU will allow the payment retry attempt, only if the previous attempt was "FAILED". If the previous attempt
is "IN PROGRESS" or "SUCCESSFUL", system will reject the subsequent attempt.
4. If COUs intend to use this feature, they need to pass siTxn value as 'Yes' in all the Payment requests.

BBPS API SPECIFICATIONS | Version 14.0

5. For first payment request COUs will be required to pass only the ref ID along with siTxn tag value as 'Yes'. In
case the payment was failed in BBPS (not CU rejection), COUs can reutilize the fetch/validation response,
however, COUs will be required to pass OrigRefId (original Ref ID will be the ref ID of the first attempt) along
with unique reference ID for each subsequent payment request.
6. For re-utilization of Fetch, there will be an ageing period of 2 days for reattempting payment using the
original reference ID. Ageing period for reutilization of fetch will start from the day of first payment request
made and the ageing period is in days.
7. For re-utilization of Validation, the ageing period will be 24 hrs from the Successful Validation done.
8. If COUs are going to retry payment using the origRefId, in case of first or other subsequent payment
failure(s), COUs should not send any communication (SMS/Email) to customer regarding the fate of
transaction i.e. transaction reference Id. COUs should only provide the information/status of the last
legitimate retry. COUs can provide acknowledgement that the transaction is in progress.
9. Once successful payment has been done, COUs has to send the communication (SMS/Email) to customer
related to transaction (i.e. transaction reference Id, status, etc.), which can be used for Transaction Status
Check, Complaint Registration.
10. If there are multiple payment tries, only the last transaction ref ID will be used for Complaints registration
and Disputes.
11. Additional tag origRefId will appear in the RAW file(s). All the entities who have automated their
reconciliation process needs to take cognisance of the change and act appropriately.

Considerations for Biller OUs

1. Currently BOUs are considering the Ref ID to link the Fetch and Payment transactions. In case BOUs receives
the Payment transaction with tag siTxn as 'Yes' and resulted as failure, there may be subsequent Payment
attempts. So, they have to allow payment to be made for the biller till it is successful using the origRefId till
the ageing period and BOUs should establish the same linkage between Fetch Ref ID and origRefId.
2. Additional tag origRefId will appear in the RAW file(s). All the entities who have automated their
reconciliation process needs to take cognisance of the change and act appropriately.

BBPS API SPECIFICATIONS | Version 14.0

100

17 Biller Types in BBPS

The following table outlines the various Biller integration scenarios in BBPS. These fields are passed on as Biller MDM
Response parameters.
S. Type Accepts Fetch Support Support QuickPay Transaction
No Ad-hoc Requirement Validation Plan MDM value in Pay
. Request
1 ONLINE T OPTIONAL - -  Yes  Ad-hoc Payment can be done (for any amount).
OPTIONAL - -  No  Payment against fetch can also be done for any amount.

2 ONLINE T NOT_SUPPORTED OPTIONAL Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).
NOT_SUPPORTED OPTIONAL Yes (T/F)  No  Payment against validation can also be done for any amount.

3 ONLINE T NOT_SUPPORTED MANDATORY Yes (T/F)  No  Payment against validation can also be done for any amount.

4 ONLINE T NOT_SUPPORTED NOT_SUPPORTED Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).
5 ONLINE T MANDATORY - -  No  Ad-hoc Payment cannot be done. Payment against fetch can
be done for any amount.

6 ONLINE F MANDATORY - -  No  Ad-hoc Payment cannot be done. EXACT, EXACT_UP,

EXACT_DOWN can be paid against fetched bill as per
configuration.

7 OFFLINE A T OPTIONAL - -  Yes  Ad-hoc Payment can be done (for any amount).
OPTIONAL - -  No  Payment against fetch can also be done for any amount.

8 OFFLINE A T NOT_SUPPORTED OPTIONAL Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).
NOT_SUPPORTED OPTIONAL Yes (T/F)  No  Payment against validation can also be done for any amount.

9 OFFLINE A T NOT_SUPPORTED MANDATORY Yes (T/F)  No  Payment against validation can also be done for any amount.

10 OFFLINE A T NOT_SUPPORTED NOT_SUPPORTED Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).
11 OFFLINE A T MANDATORY - -  No  Ad-hoc Payment cannot be done. Payment against fetch can
be done for any amount.

12 OFFLINE A F MANDATORY - -  No  Ad-hoc Payment cannot be done. EXACT, EXACT_UP,

EXACT_DOWN can be paid against fetched bill as per
configuration.

13 OFFLINE B T NOT_SUPPORTED OPTIONAL Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).
NOT_SUPPORTED OPTIONAL Yes (T/F)  No  Payment against validation can also be done for any amount.

14 OFFLINE B T NOT_SUPPORTED MANDATORY Yes (T/F)  No  Payment against validation can also be done for any amount.

15 OFFLINE B T NOT_SUPPORTED NOT_SUPPORTED Yes (T/F)  Yes  Ad-hoc Payment can be done (for any amount).

BBPS API SPECIFICATIONS | Version 14.0

101

18 Amount Block Configuration in Bill Fetch &

Bill Payment Messages
The paymentAmountExactness tag in the Biller MDM Response is applicable only when fetchRequirement tag value
is MANDATORY and billerAcceptsAdhoc tag value is false. For example, if fetch response amount is Rs. 100 then the
payment amount can be the following:

 Exact – Only Rs. 100 can be paid

 Exact and above – Rs. 100 or more can be paid
 Exact and below – Rs. 100 or less can be paid

There might be a scenario where a Biller may pass on various amount values as part of Bill Fetch Response like Early
or Late Payment. These values are applicable only when all the conditions below hold true for a Biller:

1. Fetch is MANDATORY
2. Ad-hoc field is false
3. Biller accepts Exact payment

Following is an example of a biller response block:

<BillerResponse amount="200" billDate="2016-10-01" billNumber="12303001" billPeriod="MONTHLY"

customerName="Manoj" dueDate="2016-10-31">
<Tag name="A" value="50"/>
<Tag name="B" value="75"/>
<Tag name="C" value="25"/>
</BillerResponse>

The biller configuration for this biller is as follows:

paramName:"A","dataType":"NUMERIC","optional":true},
paramName:"B","dataType":"NUMERIC","optional":true},
paramName:"C","dataType":"NUMERIC","optional":true},

"amountOptions":[
{"amountBreakupSet":["BASE_BILL_AMOUNT"]},
{"amountBreakupSet":["A"]},
{"amountBreakupSet":["B"]},
{"amountBreakupSet":["C"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","A"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","B"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","C"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","A","B"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","A","C"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","A","B","C"]},
{"amountBreakupSet":["BASE_BILL_AMOUNT","B","C"]},
{"amountBreakupSet":["A","B"]},
{"amountBreakupSet":["A","C"]},
{"amountBreakupSet":["A","B","C"]},
{"amountBreakupSet":["B","C"]}]

BBPS API SPECIFICATIONS | Version 14.0

102

For the given amount breakup set, following calculations are possible.

Scenario Combination Calculation

1 {"amountBreakupSet":["BASE_BILL_AMOUNT"]}, 200
2 {"amountBreakupSet":["A"]}, 50
3 {"amountBreakupSet":["B"]}, 75
4 {"amountBreakupSet":["C"]}, 25
5 {"amountBreakupSet":["BASE_BILL_AMOUNT","A"]}, 200+50 = 250
6 {"amountBreakupSet":["BASE_BILL_AMOUNT","B"]}, 200+75 = 275
7 {"amountBreakupSet":["BASE_BILL_AMOUNT","C"]}, 200+25 = 225
8 {"amountBreakupSet":["BASE_BILL_AMOUNT","A","B"]}, 200+50+75 = 325
9 {"amountBreakupSet":["BASE_BILL_AMOUNT","A","C"]}, 200+50+25 = 275
10 {"amountBreakupSet":["BASE_BILL_AMOUNT","A","B","C"]}, 200+50+75+25 = 350
11 {"amountBreakupSet":["BASE_BILL_AMOUNT","B","C"]}, 200+75+25 = 300
12 {"amountBreakupSet":["A","B"]}, 50+75 = 125
13 {"amountBreakupSet":["A","C"]}, 50+25 = 75
14 {"amountBreakupSet":["A","B","C"]}, 50+75+25 = 150
15 {"amountBreakupSet":["B","C"]} 75+25 = 100

Now, for the scenarios mentioned in the table, the amount block varies accordingly as shown below:

Scenario 1:
<Amount>
<Amt amount="200" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
</Amount>

Scenario 2:
<Amount>
<Amt amount="50" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
</Amount>

Scenario 3:
<Amount>
<Amt amount="75" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="B" value="75" />
</Amount>

Scenario 4:
<Amount>
<Amt amount="25" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="C" value="25" />
</Amount>

Scenario 5:

BBPS API SPECIFICATIONS | Version 14.0

103

Scenario 6:
<Amount>
<Amt amount="275" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="B" value="75" />
</Amount>

Scenario 7:
<Amount>
<Amt amount="225" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="C" value="25" />
</Amount>

Scenario 8:
<Amount>
<Amt amount="325" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="B" value="75" />
</Amount>

Scenario 9:
<Amount>
<Amt amount="275" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="C" value="25" />
</Amount>

Scenario 10:
<Amount>
<Amt amount="350" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="B" value="75" />
<Tag name="C" value="25" />
</Amount>

Scenario 11:
<Amount>
<Amt amount="300" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="B" value="75" />
<Tag name="C" value="25" />

BBPS API SPECIFICATIONS | Version 14.0

104

</Amount>

Scenario 12:
<Amount>
<Amt amount="125" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="B" value="75" />
</Amount>

Scenario 13:
<Amount>
<Amt amount="75" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="C" value="25" />
</Amount>

Scenario 14:
<Amount>
<Amt amount="150" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="A" value="50" />
<Tag name="B" value="75" />
<Tag name="C" value="25" />
</Amount>

Scenario 15:
<Amount>
<Amt amount="100" currency="356" custConvFee="calculated as per config" COUcustConvFee="as charged by COU
from Customer" />
<Tag name="B" value="75" />
<Tag name="C" value="25" />
</Amount>

BBPS API SPECIFICATIONS | Version 14.0

105

19 Fee Configuration
Interchange Fee
Generally, it is proposed that Customer Operating Unit (Customer BBPOU) and the Biller Operating Unit (Biller
BBPOU) would share a fee that would either be charged to the Biller and / or to the customer for bill payment
transactions.

An interchange fee code needs to be configured for a Category or Category & Biller. The fee could be slab-based,
however, the amount ranges should not overlap and neither should there be any gap between a maximum amount
of one slab and a minimum amount of the next higher slab. A flat fee, percent fee or a combination of both may be
applicable while configuring these fee codes in a particular direction (C2B or B2C). An illustrative example is provided
below.

Biller Biller ID Fee Tran. Amount Tran. Amount Percentage Fee Flat Fee Fee
Category Code Range (Min) Range (Max) (in percentage) (in Paisa) Direction

Mobile VODA00000NAT01 CCF 1 1000 0 0 C2B

Postpaid

Mobile VODA00000NAT01 CCF 1001 9999999999 0 100 C2B

Postpaid
Mobile VODA00000NAT01 EBF 1 9999999999 1 0 B2C
Postpaid

Mobile VODA00000NAT01 PBF 1 9999999999 2 200 B2C

Postpaid

DTH CCF 1 9999999999 0 0 C2B

DTH EBF 1 9999999999 1.5 0 B2C
DTH PBF 1 9999999999 2.5 0 B2C

The Interchange Fee table comprises of the following major fields:

1. Biller Category: Category of the Biller.

2. Biller ID: The ID of the Biller in BBPS.
3. Fee Code: Code assigned by BBPCU as per fee program.
4. Fee Description: A brief description on type of fee which will be applicable.
5. Percentage Fee: Fee can be charged as a percentage per transaction amount (as applicable). It indicates if
percentage fee is applicable for that particular Fee Code / Fee Description.
6. Flat Fee: Fee can be charged as a fixed amount per transaction count (as applicable). It indicates if flat fee is
applicable for that particular Fee Code / Fee Description.
7. Fee Direction: The direction of flow of fee, C2B or B2C.

When flat fee or percent fee field value is zero for a particular fee code, the system will consider that particular
component to be zero while calculating fee.

BBPS API SPECIFICATIONS | Version 14.0

106

Interchange Fee Config

Interchange fee will be depending on the following parameters: Biller Category, Biller Id, Payment Channel, MTI,
Response Code and several other parameters.

For a particular Fee Code, system will ensure only one scenario to be applied to Biller Category, Biller, MTI, Response
Code and Channel combination in one direction, i.e., from Customer to Biller BBPOU or vice-versa, in the Interchange
Fee Config table. This implies that these fee combinations are mutually exclusive, i.e., only one of these combinations
can exist at a time. The table below illustrates the following:

Biller Category Biller ID MTI Payment Channel Response Code Fees Default Flag

Mobile Postpaid VODA00000NAT01 PAYMENT Bank Branch 000 CCF,PBF f

Mobile Postpaid VODA00000NAT01 PAYMENT Agent 000 CCF,PBF f

Mobile Postpaid VODA00000NAT01 PAYMENT Business Correspondent 000 CCF,PBF f
Mobile Postpaid VODA00000NAT01 PAYMENT 000 CCF,EBF t
DTH PAYMENT Bank Branch 000 CCF,PBF f

DTH PAYMENT Agent 000 CCF,PBF f

DTH PAYMENT Business Correspondent 000 CCF,PBF f
DTH PAYMENT 000 CCF,EBF t

 A combination of Biller Category, Response Code and MTI are mandatory fields while Biller ID and Channel are
optional fields.
 For a combination of Biller Category (Mobile Postpaid), Biller (VODA00000NAT01), Response Code (000), MTI
(PAYMENT), and Channels (Bank Branch, Agent & Business Correspondent) CCF and PBF are applicable. Ceteris
paribus, for any other Channel, CCF and EBF are applicable since the default indicator is true.
 If the system is not able to uniquely identify a combination of Biller Category, Biller, MTI, Response Code and
Channel, then it will perform computations based on the condition default flag = TRUE for the Biller Category,
Biller, Response Code and MTI combination.
 Duplicate configuration will not be allowed for any interchange fee.
 A Response Code ‘000’ identifies a successful transaction.
 The default flag is true only for one unique combination of Biller Category, Biller, MTI, Response Code and
Channel.

The Interchange Fee Config table comprises of the following major fields:

1. Biller Category: Category of the Biller.

2. Biller ID: The ID of the Biller in BBPS.
3. MTI: Message type indicator identifying the transaction type, i.e., FETCH or PAYMENT.
4. Payment Channel: Payment channel, i.e., Bank Branch, Mobile, etc.
5. Response code: Required to identify successful transactions (000).
6. Fees: The fee codes assigned to a combination of BBPOU and Biller.
7. Default Flag: Boolean field indicating if the particular combination is default or not.

BBPS API SPECIFICATIONS | Version 14.0

107

Interchange fee can be configured and authorized by the authorized BBPCU Admin / User. On the basis of these
parameters and the applicable fee rate table items, the interchange fee, along with the fee direction will be
computed for the respective BBPOUs. Front end configuration will be given to the authorized Canvas user for adding,
modifying or deleting interchange fee structure with maker / checker option. Maker can only configure the
interchange fee and once approved by the checker, relevant changes will be reflected in the respective tables.

Interchange fee that has been charged during the original transaction will be reversed when any action results in a
fund movement in the opposite direction. When a transaction reversal is done, the interchange fee will be taken
from the bill payment. This could mean that the interchange fee being reversed will not differ from the original
interchange fee charged. In case of disputed transactions, the interchange fee of the originating payment transaction
will be referred to and be applied in the opposite direction.

Note: In case of Refund Good Faith Partial, only percentage fee will be reversed, flat fee won’t be reversed.

BBPS API SPECIFICATIONS | Version 14.0

108

20 BBPS IDs
ID Generation Stages
Online & Offline (A) Online & Offline (A) Offline (B)
Identification Generator Bill Fetch Bill Fetch Payment Payment Payment Payment
Request Response Request Response Request Response
msgID Customer Populated Carried Populated Carried Populated Carried
BBPOU by Customer From Bill by Customer From Bill by Customer From Bill
BBPOU Fetch BBPOU Payment BBPOU Payment
Request Request Request

refId Customer Populated Carried Carried Carried Populated Carried

BBPOU by Customer From Bill From Bill From Bill by Customer From Bill
BBPOU Fetch Fetch Fetch BBPOU Payment
Request Request Request Request

origRefId Customer NA NA Populated Carried Populated Carried

BBPOU by Customer From Bill by Customer From Bill
BBPOU Payment BBPOU Payment
Request Request

txnRefId Customer NA NA Populated Carried Populated Carried

BBPOU by Customer From Bill by Customer From Bill
BBPOU Payment BBPOU Payment
Request Request

BBPOU ID BBPCU Populated Populated Carried Populated Populated Populated

by Customer by Biller From Bill by Biller by Customer by Biller
BBPOU BBPOU Fetch BBPOU BBPOU BBPOU
Request

AI ID BBPCU Populated NA Carried NA Populated NA

by Customer From Bill by Customer
BBPOU Fetch BBPOU
Request

Agent ID Customer Populated NA Carried NA Populated NA

BBPOU by Customer From Bill by Customer
BBPOU Fetch BBPOU
Request

Biller ID BBPCU Populated NA Carried NA Populated NA

by Customer From Bill by Customer
BBPOU Fetch BBPOU
Request

System User BBPCU NA NA NA NA NA NA

ID (BBPOU /
BBPCU)

BBPS API SPECIFICATIONS | Version 14.0

109

Generation Logic
Identification Messages Length Type Logic Example Applicable
to BBPOU
Message ID Unique ID assigned by 35 Alphanumeric Random Alpha Numeric – 27 AWPNSPV Y
the initiating BBPOU Julian Date of the BPVPWDA
for chaining a request Transaction Initiation Date LTOMJSNB
and response message (YDDD) – 4 FQNOS104
Time of the Transation 31207
Initiation (HHMM) – 4
Reference ID / Unique ID assigned by 35 Alphanumeric Random Alpha Numeric – 27 BWPNSPV Y
Original the initiating BBPOU to Julian Date of the BPVPWDA
Reference ID unambiguously identify Transaction Initiation Date LTOMJSNB
the transaction which (YDDD) – 4 FQNOS104
is passed on, Time of the Transation 31207
unchanged, Initiation (HHMM) – 4
throughout the entire
end-to-end chain
Transaction Unique ID for all BBPS 12 / 20 Alphanumeric Customer BBPOU code - 4; OU015678 Y
Reference ID payment transactions Random alphanumeric – 8 9123

Customer BBPOU code - 4; OU019047

Julian Date of the ABCD1234
Transaction Initiation Date 5678
(YDDD) – 4
Random alphanumeric - 12
BBPOU ID It is a unique code 4 Alphanumeric Alpha - 2; OU01 Y
allocated by BBPCU for Numeric – 2
identifying the
institution forwarding
a request to BBPCU
AI ID Unique ID associated 4 Alphanumeric Alpha - 2; OU02 Y
with Agent Institution Numeric – 2
Agent ID Unique number which 20 Alphanumeric Customer BBPOU ID - 4; OU01OU0 Y
identifies the Agent Agent Institution ID - 4; 2INT12345
Agent Payment Channel 6789
Code - 3;
Random number - 9
Biller ID Unique number which 14 Alphanumeric Short identifier of the biller - VODA0000 Y
identifies the Biller 14 0MUM03
System User ID Uniquely identifies the 16 Alphanumeric BBCU(4-character) + '_' + BBCU_Use NA
– BBPCU BBPCU user user ID provided by BBPCU r1
(Alphanumeric Must be 6 to
11 characters long)
System User ID Uniquely identifies the 16 Alphanumeric BBPOU ID (4-character) + '_' OU12_Use Y
– BBPOU BBPOU user +user ID provided by BBPOU r2
(Alphanumeric Must be 6 to
11 characters long)
Complaint ID Complaint ID 15 Alphanumeric 1st 4 characters of Tran Ref OP012104 NA
generated by BBPCU ID – 4 6567755
Julian Date of the Complaint
Registration Date (YYDDD)-5
Random Numeric – 6

BBPS API SPECIFICATIONS | Version 14.0

110

21 Payment Mode & Channel Details

Initiating Channel Vs Device Block Parameters
S. No. Initiating Channel Channel Channel Code Device Block Tags
Code in API in Agent ID
1 Bank Branch BNKBRNCH BNK IFSC, MOBILE, GEOCODE, POSTAL_CODE
2 Mobile (Pre-login) MOB MOB IP, IMEI, OS, APP
3 Mobile Banking (Post- MOBB MBB IP, IMEI, OS, APP
login)
4 Internet (Pre-login) INT INT IP, MAC
5 Internet Banking INTB INB IP, MAC
(Post-login)
6 ATM ATM ATM TERMINAL_ID
7 Kiosk KIOSK KSK TERMINAL_ID
8 Agent AGT AGT TERMINAL_ID, MOBILE, GEOCODE, POSTAL_CODE
9 Business BSC BSC TERMINAL_ID, MOBILE, GEOCODE, POSTAL_CODE
Correspondent

Payment Mode Vs Payment Info Parameters

The Customer BBPOU may not be able pass on the payment mode details under certain circumstances. Then it may
follow the below format while passing payment information:

 For card transaction:

value="<Last 4 digits or masked card number>|<Card>"
e.g. <Tag name="CardNum|AuthCode" value="8625|Card"/>

 For transaction through a payment gateway:

value="<PG reference number>|<PG>"
e.g. <Tag name="IFSC|AccountNo" value="SRAN0000341|PG"/>

BBPS API SPECIFICATIONS | Version 14.0

111

BBPS API SPECIFICATIONS | Version 14.0

112

22 Settlement File Transfer Mechanism

BBPS clearing and settlement system is a three party module consisting of BBPCOU (Customer BBPOU), BBPCU and
BBPBOU (Biller BBPOU). BBPCU clearing and settlement is operational throughout the year. It extracts or collects the
authorized transactions from the core application server (transaction server) transmitted by the BBPOUs and based
on that, processes the transactions in clearing and settlement module and prepares a settlement file which needs to
be uploaded to settlement bank.

The BBPCU system sends the following files to BBPOUs as part of every settlement cycle, which typically happens
multiple times on every working day:

1. RAW File – Will be generated for OU & Participating AI if transactions available for Settlement (XML format)
2. Daily Settlement Report – Will be generated for OU & Participating AI (CSV & PDF formats)
3. Daily GST Report – Will be generated for OU (CSV & PDF formats)
4. Participating AI wise Aggregated Daily Report – Will be generated for OU (CSV & PDF formats)
5. Pending Transactions Report – Will be generated for OU & Participating AI (CSV & PDF formats)

The BBPCU also shares Monthly reports once a month with the BBPOUs:

1. Account Ledger – Will be generated for OU (CSV & PDF formats)

2. Direct AI wise Aggregated Monthly Report – Will be generated for OU (CSV & PDF formats)
3. Monthly GST Report – Will be generated for OU (CSV & PDF formats)
4. Monthly Invoice Report – Will be generated for OU (CSV & PDF formats)
5. Monthly Invoice Report for FETCH – Will be generated for OU (CSV & PDF formats)
6. Fetch Summary Report for COU – Will be generated for COU (CSV & PDF formats)
7. Fetch Summary Report for BOU – Will be generated for BOU (CSV & PDF formats)

All files are securely shared over HTTPS. To be able to receive these files, BBPOU systems must expose the below
APIs. Assuming a BBPOU name as OU12, and base URL of BBPOU system as https://a.b.c.d/context
URL Files Received MIME Type Method
https://a.b.c.d/context/csv Settlement Report: multipart/for POST
Example: 07001OU122016080400.csv m-data
Account Ledger:
Example: 85201607OU122016080400.csv
https://a.b.c.d/context/pdf Settlement Report:
Example: 07001OU122016080400.pdf
Account Ledger:
Example: 85201607OU122016080400.pdf
https://a.b.c.d/context/txt Raw Data File:
Example: 00001OU132016080400.xml
This file contains all transactions for the settlement cycle in XML
format, and the XML is signed

All APIs are expected to return an OK (200) status on successfully receiving a file.

The example mentioned in the file transfer process mentions a nomenclature https://a.b.c.d/context (context is just
indicative) and this in its entirety is assumed to be the endpoint URL. This is the same endpoint URL which BBPOUs
provide for transmission of online messages but in the form https://<IP_Address>:<Port_No>. Also, it is the same
location where the BBPOUs have deployed their respective BBPOU application.

Note: Please refer to Appendix 22.2 for details on the file naming convention for settlement related files.

BBPS API SPECIFICATIONS | Version 14.0

113

23 Elements Description
Element: Root

Presence : Mandatory
Definition : XML root element representing each API.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Definition
BillFetchRequest The message is used for fetch request
BillFetchResponse The message is used for fetch response
BillPaymentRequest The message is used for payment request
BillPaymentResponse The message is used for payment response
TxnStatusRequest The message is used for transaction status request (for pending transactions)
TxnStatusResponse The message is used for transaction status response (for pending transactions)
BillValidationRequest The message is used for validation request
BillValidationResponse The message is used for validation response
ReqDiagnostic The message is used for diagnostic request
ResDiagnostic The message is used for diagnostic response
TxnStatusComplainRequest The message is used for transaction status and complaint related requests
TxnStatusComplainResponse The message is used for transaction status and complaint related responses
BillerFetchRequest The message is used for Biller MDM request
BillerFetchResponse The message is used for Biller MDM response
AgentFetchRequest The message is used for Agent MDM request
AgentFetchResponse The message is used for Agent MDM response
Ack The message is used for acknowledgement message
BBPSPlanMDMPush This message is used for Plan MDM Push
BBPSPlanMDMPull This message is used for Plan MDM Pull
BillerStatusUpdate This message is used for Biller Status Update
BillerActivationCheckRequest This message is used for Biller Activation Check Request from CU to BOU
BillerActivationCheckResponse This message is used for Biller Activation Check Response from BOU to CU
BillerStatusRequest This message is used for Biller Status Request
BillerStatusResponse This message is used for Biller Status Response

Attribute: xmlns

Presence : Mandatory
Definition : API Schema namespace.
Data Type : Alphanumeric
Format : Min Length – 1, Max Length – 255
Compliance : Namespace declaration used: xmlns:bbps="http://bbps.org/schema"

Element: <Head>

Presence : Mandatory
Definition : Header of the message.

Attribute: ver

BBPS API SPECIFICATIONS | Version 14.0

114

Presence : Mandatory
Definition : Version of the API. This is the API version. NPCI may host multiple versions for supporting gradual
migration.
Data Type : Alphanumeric
Format : Min Length – 3, Max Length – 4
Compliance : Data format and type.
Currently the default production version is 1.0 with subsequent versions being 2.0, 3.0, etc.

Attribute: ts

Presence : Mandatory
Definition : Header timestamp will be populated at the time of creating the message which will be updated at
each leg of the transaction.
Data Type : ISODateTime
Format : Fixed Length – 25 i.e., YYYY-MM-DDThh:mm:ss+hh:mm (e.g. 2017-02-14T13:10:15+05:30)
Where,
YYYY = four-digit year
MM = two-digit month number (01 indicates 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 (+05:30).
Compliance : Tolerance of +/- 299 seconds from the current BBPCU time for Bill Fetch and Bill Payment
messages. Since time stamp plays a critical role, it is highly recommended that BBPOU systems are
time synchronized with global NTP server.

Attribute: origInst

Presence : Mandatory
Definition : It is a unique code allocated by BBPCU for identifying the institution forwarding a message to
BBPCU. When BBPCU is the originator, the value is "BBCU".
Data Type : Alphanumeric
Format : Fixed Length – 4, e.g. OU12
Alpha – 2, Numeric – 2
Compliance : BBPOU ID allocated to the provider by BBPCU at the time of on-boarding.

Attribute: refId

Presence : Mandatory
Definition : Code generated by the BBPOU 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.
Data Type : Alphanumeric
Format : Fixed Length – 35 (Random Alpha Numeric – 27, Julian Date of the Transaction Date (YDDD) – 4,
Time of the Transation Initiation (HHMM) – 4)
Compliance : Unique identification assigned by the initiating BBPOU to unambiguously identify the transaction
which is passed on, unchanged, throughout the entire end-to-end chain.

BBPS API SPECIFICATIONS | Version 14.0

115

The reference ID should be same for fetch / validation and payment request as well as in response
for all transactions including reversals.

Attribute: siTxn

Presence : Conditional
Definition : Flad indicating Payment is for registered customers or not.
Data Type : Code Set
Format : Min Length – 2, Max Length – 3 (Yes / No)
Compliance : If Customer OUs intend to re-utilize the Fetch / Validaation, they need to pass siTxn attribute value
as 'Yes' in all the Payment requests.

Attribute: origRefId

Presence : Conditional
Definition : Code generated by the BBPOU that acquires the customer for a bill payment transaction initiated
in-case previous attempt was failed for a registered customer. UUID logic defined by ISO to be used
for generation of the reference number.
Data Type : Alphanumeric
Format : Fixed Length – 35 (Random Alpha Numeric – 27, Julian Date of the Transaction Date (YDDD) – 4,
Time of the Transation Initiation (HHMM) – 4)
Compliance : Unique identification assigned by the initiating BBPOU to unambiguously identify the transaction
which is passed on, unchanged, throughout the entire end-to-end chain.
For first payment request COUs will be required to pass only the refId along with siTxn value as 'Yes'.
In case the payment was failed in BBPS (not CU rejection), COUs can reutilize the fetch/validation
response, however, COUs will be required to pass origRefId (original Ref ID will be the refId of the
first attempt) along with unique reference ID for each subsequent payment request.

Element: <Analytics>

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

Element: <Analytics.Tag>

Presence : Conditional
Definition : The tag is defined in name value pairs to accommodate the MIS related parameters. It is mandatory
to have the following name-value pairs mentioned below.

Attribute: name

Presence : Conditional
Definition : The name attribute will have the values as defined in the code table.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Definition
FETCHREQUESTSTART The time at which the fetch request was initiated in the BBPOU system
FETCHREQUESTEND The time at which the fetch request was sent out from the BBPOU system
PAYREQUESTSTART The time at which the payment request was initiated in the BBPOU system

BBPS API SPECIFICATIONS | Version 14.0

116

PAYREQUESTEND The time at which the payment request was sent out from the BBPOU system

Attribute: value

Presence : Conditional
Definition : Details of transaction initiated time and end time in the BBPOU system.
Data Type : ISODateTime
Format : Fixed Length – 25, i.e., YYYY-MM-DDThh:mm:ss+hh:mm (e.g. 2017-02-14T13:10:15+05:30)
Where,
YYYY = four-digit year
MM = two-digit month number (01 indicates 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 (+05:30).
Compliance : Data format and type.

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: ts

Presence : Mandatory
Definition : Transaction timestamp created by the initiating BBPOU which will remain constant throughout all
legs of the transaction.
Data Type : ISODateTime
Format : Fixed Length – 25 i.e., YYYY-MM-DDThh:mm:ss+hh:mm (e.g. 2017-02-14T13:10:15+05:30)
Where,
YYYY = four-digit year
MM = two-digit month number (01 indicates 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 (+05:30).
Compliance : Tolerance of +/- 299 seconds from the current BBPCU time for Bill Fetch and Bill Payment
messages. Since time stamp plays a critical role, it is highly recommended that devices are time
synchronized with global NTP server.

Attribute: msgId

BBPS API SPECIFICATIONS | Version 14.0

117

Presence : Mandatory
Definition : Code generated by the BBPOU 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.
Data Type : Alphanumeric
Format : Fixed Length – 35 (Random Alpha Numeric – 27, Julian Date of the Transaction Date (YDDD) – 4,
Time of the Transation Initiation (HHMM) – 4)
Compliance : Unique identification assigned by the initiating BBPOU for chaining a request and response
message. The ID should be same for request and response message.

Attribute: txnReferenceId

Presence : Conditional
Definition : This data element will contain a unique reference ID for all BBPS payment transactions. This will be
used by the Customer for referring to a payment transaction.
Data Type : Alphanumeric
Format : Fixed Length – 12 or 20
i) Originating Institution ID (Customer OU Id or Participating AI Id) - 04, Random alphanumeric - 08
ii) Originating Institution ID (Customer OU Id or Participating AI Id) - 04, Julian Date - 04 and Random
alphanumeric - 12

Compliance : This field is applicable for all payment transactions. COUs are expected to ensure that the Julian
date used is of Current Date.

Attribute: paymentRefId

Presence : Optional
Definition : This data element will contain a unique reference ID generated at the time of customer account
debit at PG.
Data Type : Alphanumeric
Format : Min Length – 4 & Max Length – 80
Compliance : This field is applicable for payment transactions.

Attribute: directBillChannel

Presence : Conditional
Definition : This data element will contain channel through which transaction was initiated in case of
QR/PayLink.
Data Type : Code Set
Format : L1QR/L1PL/L2QR/L2PL/L3QR/L3PL
Compliance : This field is applicable for QR/PayLink type of transactions.

Attribute: directBillContentId

Presence : Conditional
Definition : This data element will contain the unique content id of the QR/PL, generated by Biller. This is
required in case of L3{QR/PL}
Data Type : Alpha Numeric
Format : Min length – 12, Max length – 17 and First 5 digits should be valid Julian date
Compliance : This field is applicable for L3 QR/PayLink type of transactions.

BBPS API SPECIFICATIONS | Version 14.0

118

Attribute: type

Presence : Conditional
Definition : This attribute describes the transaction type for a bill payment transaction.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Definition
FORWARD TYPE REQUEST Payment request transaction is in forward nature
REVERSAL TYPE REQUEST Payment request transaction is in reversal nature
FORWARD TYPE RESPONSE Response is sent to the forward type request
REVERSAL TYPE RESPONSE Response is sent to the reversal type response

Attribute: xchangeId

Presence : Conditional
Definition : Identification of the type of the request as listed in the following table.
Data Type : Code Set
Format : Fixed Length – 3
Compliance : Data format and type as follows:

Code Definition Currently Implemented

401 Transaction status (OU/AI to CU) Yes
402 Transaction status (CU to BOU) Yes
501 Complaint registration Yes
502 Complaint re-assignment Yes
503 Complaint re-open Yes
506 Complaint status Yes
507 Complaint closure Yes
508 Complaint Status Update (CU to OU)

Element: <Txn.RiskScores>

Presence : Mandatory
Definition : This element defines the risk evaluation associated with the transaction and the related 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 scores. This is the entity which evaluates the risk associated with the
transaction. When BBPCU is the provider, the value is "BBPS".
Data Type : Code Set
Format : Fixed Length – 4
Compliance : The provider ID should be same as the originating institution ID used for initiating the fetch or
payment request.

BBPS API SPECIFICATIONS | Version 14.0

119

Attribute: type

Presence : Mandatory
Definition : This attribute describes the type of risk.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Pre-defined values, e.g. TXNRISK

Attribute: value

Presence : Mandatory
Definition : Code Set
Data Type : Numeric
Format : Fixed Length – 3
Compliance : Value of risk evaluation ranging from "000" (No Risk) to "100" (Maximum Risk) with default score
being "030".

Element: <Customer>

Presence : Mandatory
Definition : Customer related details who initiate the transaction, i.e. details of the customer viewing / paying
the bill.

Attribute: mobile

Presence : Mandatory
Definition : Mobile number of customer who initiates the bill fetch / payment.
Data Type : Numeric
Format : Minimum Length – 6, Maximum Length - 20
Compliance : Data format and type should be for a valid mobile number.

Element: <Customer.Tag>

Presence : Conditional
Definition : The tag is defined in name value pairs to accommodate the parameters for the Customer initiating
the fetch / payment transaction. It is mandatory to have the following name-value pairs mentioned
below.

Attribute: name

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

BBPS API SPECIFICATIONS | Version 14.0

120

Attribute: value

Presence : Conditional
Definition : Valid values pertaining to Email, Aadhaar and PAN details provided by the customer initiating the
fetch / payment transaction.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Value
EMAIL manoj.chekuri@npci.org.in
AADHAAR 123123123200
PAN BXXPC4454Q

Element: <Agent>

Presence : Mandatory
Definition : Details pertaining to the Agent which initiates the transaction.

Attribute: id

Presence : Mandatory
Definition : Agent ID is the unique number which identifies the agent.
Data Type : Alphanumeric
Format : Fixed Length – 20, e.g. OU01OU02INT000000001
Where,
 Customer BBPOU ID – 4
 Agent Institution ID – 4
 Agent Payment Channel Code – 3
 Random number – 9
Compliance : The Agent ID should be active in BBPCU system. Agent Payment Channel Code is as follows:

Element: <Agent.Device>

Presence : Mandatory
Definition : Details of the device from which the transaction was initiated.

Element: <Agent.Device.Tag>

BBPS API SPECIFICATIONS | Version 14.0

121

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

Attribute: name

Code Definition Presence

INITIATING_CHANNEL Initiating channel of the transaction Mandatory
MOBILE Mobile number of the agent Conditional
GEOCODE Latitude and longitude of the device – Represented in Conditional
degrees with 4 digits after decimal
POSTAL_CODE Postal code of the agent Conditional
IP IP address of the device Conditional
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 in the device Conditional
APP Application used in the device Conditional

Attribute: value

Presence : Conditional
Definition : Specified value as defined
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Format Example

MOBILE nnnnnnnnnn 9505987798
Fixed Length – 10
GEOCODE nn.nnnn,nn.nnnn 12.9667,77.5667
Min Length – 13, Max Length – 15 9.1234,82.5643
IP Valid IP address format(v4,v6) 123.456.121.121
Max Length – 15
INITIATING_CHANNEL Initiating channel of the transaction  Bank Branch – BNKBRNCH
Code Set  Mobile (Pre-login) – MOB
Min Length – 1, Max Length – 20  Mobile Banking (Post-login) –
MOBB
 Internet (Pre-login) – INT
 Internet Banking (Post-login)
– INTB
 ATM – ATM
 Kiosk – KIOSK
 Agent – AGT
 Business Correspondent –
BSC

BBPS API SPECIFICATIONS | Version 14.0

122

TERMINAL_ID Terminal ID of the initiating transaction 123456

(numeric)
Min Length – 1, Max Length – 10
IMEI IMEI address of the device 1234567890ABCDE
Alpha Numeric If IMEI is not available, OUs can pass
Android ID or IOS Device ID
IFSC IFSC of the bank branch ABCD0001152
Fixed Length – 11
MAC MAC ID of the device 00-0D-60-07-2A-FO
Fixed Length – 17
OS Operating system used in the device iOS 8.1
Min Length – 1, Max Length – 20
APP Application used in the device SB 1.0
Min Length – 1, Max Length – 20

Element: <BillDetails>

Presence : Mandatory
Definition : This tag captures the Biller ID and bill related details to identify a Customer.

Element: <BillDetails.Biller>

Presence : Mandatory
Definition : Biller related details for which the transaction is initiated.

Attribute: id

Presence : Mandatory
Definition : Biller ID is the unique number which identifies the Biller.
Data Type : Alphanumeric
Format : Fixed Length – 14, e.g. TATAPWR00DEL01
Where,
 Short identifier of the biller (may be augmented with trailing zeroes) - 9
 Coverage - 3
 Random number - 2
Compliance : The Biller ID should be active in BBPCU system.

Element: <BillDetails.CustomerParams>

Presence : Mandatory
Definition : This tag captures the customer parameters.

Element: <BillDetails.CustomerParams.Tag>

Presence : Conditional
Definition : This tag captures the biller’s reference fields in name value pair.

Attribute: name

Presence : Conditional
Definition : Name of the reference field as configured for the Biller in BBPCU system. These data elements
would be conditional, i.e., they would be mandatory for specific billers only.

BBPS API SPECIFICATIONS | Version 14.0

123

Data Type : Code Set

Format : Min Length – 1, Max Length – 100
Compliance : Data format and type as follows:

Code Definition
RefFld1 Reference fields that may be customised according to the requirements of specific Billers at the time
RefFld2 of on-boarding a Biller.
RefFld3 Sample values include Consumer Number (Electricity billers), Subscriber ID (DTH operators), etc.

Attribute: value

Presence : Conditional
Definition : Value of the reference field which uniquely identifies the Customer for the Biller.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type as follows:

Code Format Example

RefFld1 As defined at the time of on-boarding by the  Consumer No: 210000055001
RefFld2 Biller BBPOU.  Mobile No: 9830098300
RefFld3

Element: <Reason>

Presence : Mandatory
Definition : This tag captures the response details of the transaction.

Attribute: approvalRefNum

Presence : Mandatory
Definition : Internal reference number which may be used by the Biller BBPOU for a transaction.
Data Type : Alphanumeric Special
Format : Min Length – 4, Max Length – 100
Compliance : Default value to be "AB123456".

Attribute: responseCode

Presence : Mandatory
Definition : Carries the response code indicating success or failure of the transaction.
Data Type : Code Set
Format : Fixed Length – 3
Compliance : Response code should be sent per the response code list shown below.

Scenario Response Code Response Reason

Forward Request / Response 000 Successful
Force Closed Transactions 100 Failure
Reversals 100 – 199 Failure
CU declines 001 – 099 Failure
BOU Declines 200 – 299 Failure
COU Declines 300 – 399 Failure

BBPS API SPECIFICATIONS | Version 14.0

124

Attribute: responseReason

Presence : Mandatory
Definition : Description of the response code sent by the Biller BBPOU.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Response reason should be sent per the response code list shown below.

Scenario Response Code Response Reason

Attribute: complianceRespCd

Presence : Conditional
Definition : The compliance response code for the compliance violation of the specific rule-set by BBPCU. It
indicates the reason for a failed transaction and is not required for a successful transaction.
Data Type : Code Set
Format : Fixed Length – 6, e.g. HED001
Alpha – 3, Numeric – 3
Compliance : Compliance code should be sent per the compliance code list. Data format and type as follows:

Compliance Code Compliance Reason Explanation

XXX111 Description of the error Where XXX are alpha characters and 111 are numeric
characters

Attribute: complianceReason

Presence : Conditional
Definition : The compliance response description for the compliance violation of the specific rule-set by BBPCU.
It indicates the reason for a failed transaction and is not required for a successful transaction.
Data Type : Code Set
Format : Min Length – 1, Max Length – 100
Compliance : Compliance reason should be sent per the compliance code list. Data format and type as follows:

Compliance Code Compliance Reason Explanation

XXX111 Description of the error Where XXX are alpha characters and 111 are numeric
characters

Element: <BillerResponse>

Presence : Conditional
Definition : This tag captures the bill responses provided by the biller for a successful transaction, i.e., response
code is '000'.

BBPS API SPECIFICATIONS | Version 14.0

125

Attribute: customerName

Presence : Conditional
Definition : Customer name as registered with the Biller.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type.
i) To be populated as "NA" where customer name is unavailable
ii) For a payment transaction without a fetch, the customer name value should be "NA".
iii) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid
and Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

Attribute: amount

Presence : Conditional
Definition : Actual bill amount inclusive of all charges (in paise).
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.
For a payment transaction without a fetch, the amount value should be same as the amount passed
as payment request.
For a reversal transaction, the amount should be same as per the original request.

Attribute: dueDate

Presence : Conditional
Definition : This field denotes due date of the bill.
Data Type : ISO Date
Format : Fixed Length – 10, e.g. 2016-01-01
Compliance : Data format and type.
i) To be populated as "9999-01-01" where due date is unavailable.
ii) For a payment transaction without a fetch, the due date value should be current date.
iii) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid
and Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

Attribute: billDate

Presence : Conditional
Definition : This field denotes generation date of the bill.
Data Type : ISO Date
Format : Fixed Length – 10, e.g. 2016-01-01
Compliance : Data format and type.
i) To be populated as "0001-01-01" where bill generation date is unavailable.
ii) For a payment transaction without a fetch, the bill date value should be current date.
iii) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid
and Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

BBPS API SPECIFICATIONS | Version 14.0

126

Attribute: billNumber

Presence : Conditional
Definition : This field denotes the bill number of the bill fetch / payment message requested.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type.
i) To be populated as "NA" where bill number is unavailable
ii) For a payment transaction without a fetch, the bill number value should be "NA".
iii) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid
and Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

Attribute: billPeriod

Presence : Conditional
Definition : The bill period of the bill fetch / payment requested.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type.
i) Possible values are: ONETIME, DAILY, WEEKLY, BIMONTHLY, MONTHLY, QUARTERLY,
HALFYEARLY, YEARLY and ASPRESENTED.
ii) To be populated as "NA" where bill period is unavailable
iii) For a payment transaction without a fetch, the bill period value should be "NA".
iv) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid
and Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

Attribute: custConvFee

Presence : Conditional
Definition : Customer convenience fee (CCF1) paid by the Customer BBPOU to Biller BBPOU. This value is
copied from the convenience fee attribute in the amount tag for the payment transaction.
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.
i) For Biller Categories Mobile Postpaid, Gas, Water, Landline Postpaid, DTH, Broadband Postpaid and
Electricity all the attributes are MANDATORY, for others only "amount" is MANDATORY

Element: <BillerResponse.Tag>

Presence : Conditional
Definition : This tag captures the biller’s amount fields in name value pair. It indicates the various amount
options provided by the Biller.

Attribute: name

Presence : Conditional
Definition : Name of the amount field as configured for the Biller in BBPCU system. These data elements would
be conditional, i.e., they would be mandatory for specific billers only.
Data Type : Code Set
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type as follows:

BBPS API SPECIFICATIONS | Version 14.0

127

Code Definition
Amount 1 Amount fields that may be customised according to the requirements of specific Billers at the time of
Amount 2 on-boarding a Biller.
Amount 3 Sample values include Late Fee, Discount, etc.

Attribute: value

Presence : Conditional
Definition : Specified value as defined (in paise).
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type as follows:

Code Format Example

Amount 1 As provided by the Biller BBPOU while giving  Late Fee: 32000
Amount 2 the response.  Discount: 2000
Amount 3

Element: <AdditionalInfo>

Presence : Conditional
Definition : This tag captures the additional information provided by the Biller as part of response for a
successful transaction, i.e., response code is ‘000’.

Element: <AdditionalInfo.Tag>

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

Attribute: name

Presence : Conditional
Definition : Name of the additional information field as configured for the Biller in BBPCU system. These data
elements would be conditional, i.e., they would be mandatory for specific billers only.
Data Type : Code Set
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type as follows:

Code Definition
BlRspFld1 Additional information fields that may be customised according to the requirements of
BlRspFld2 specific Billers at the time of on-boarding a Biller.
PaymentBlRspFld1 Sample values include Early Payment Date, Status, etc.
PaymentBlRspFld2

Attribute: value

Presence : Conditional
Definition : Specified value as defined.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 255

BBPS API SPECIFICATIONS | Version 14.0

128

Compliance : Data format and type as follows:

Code Format Example

BlRspFld1 As provided by the Biller BBPOU  Early Payment Date: 2016-05-01
BlRspFld2 while giving the response.  Status: Active
PaymentBlRspFld1
PaymentBlRspFld2

Element: <PaymentMethod>

Presence : Mandatory
Definition : This tag captures the payment method used for the transaction.

Attribute: quickPay

Presence : Mandatory
Definition : Flag indicating if the payment is initiated without a fetch or not.
Data Type : Code Set
Format : Min Length – 2, Max Length – 3
Compliance : Accepted values are "Yes" or "No".

Attribute: splitPay

Presence : Mandatory
Definition : Flag indicating if the bill is paid using two different payment modes.
Data Type : Code Set
Format : Min Length – 2, Max Length – 3
Compliance : Accepted values are "Yes" or "No".

Attribute: OFFUSPay

Presence : Optional
Definition : Flag indicating if it is an electronic ON-US or OFF-US transaction.
Data Type : Code Set
Format : Min Length – 2, Max Length – 3
Compliance : Accepted values are "Yes" or "No".

Attribute: paymentMode

Presence : Mandatory
Definition : Defines the payment mode which is used for the bill payment transaction
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Payment Mode Code

Internet Banking Internet_Banking
Debit Card Debit_Card
Credit Card Credit_Card
IMPS IMPS
Cash Cash
UPI UPI

BBPS API SPECIFICATIONS | Version 14.0

129

Wallet Wallet
NEFT NEFT
Prepaid Card Prepaid_Card
AEPS AEPS
Account Transfer Account_Transfer
Bharat QR Bharat_QR
USSD USSD

Element: <Amount>

Presence : Mandatory
Definition : Block containing different amount related details for the payment transaction.

Element: <Amount.Amt>

Presence : Mandatory
Definition : Details of the bill payment amount made by the Customer.

Attribute: amount

Presence : Mandatory
Definition : Actual amount paid by the Customer for the transaction (in paise).
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.

Attribute: custConvFee

Presence : Mandatory
Definition : Customer convenience fee (CCF1) paid by the Customer BBPOU to Biller BBPOU. This flows from the
Customer BBPOU to the Biller BBPOU.
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.

Attribute: COUcustConvFee

Presence : Optional
Definition : Customer convenience fee (CCF2), paid by the Customer to Customer BBPOU. This value should be
within the prescribed limits set for a Biller and the transaction amount and will flow from Customer
BBPOU to BBPCU but will not be forwarded to Biller BBPOU.
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.

Attribute: currency

Presence : Mandatory
Definition : Defines the currency in which the payment is initiated.
Data Type : Code set (ISO 4217)
Format : Fixed Length – 3

BBPS API SPECIFICATIONS | Version 14.0

130

Compliance : Data format and type. (Accepted value is "356").

Element: <Amount.SplitPayAmount>

Presence : Conditional
Definition : This data element will carry the bill payment amount which is paid in the mode other than the
primary mode of payment (in paise).
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.

Element: <Amount.Tag>

Presence : Conditional
Definition : It indicates the amount paid by the customer for any amount other than the base bill amount. This
is applicable only when all the conditions below hold true for a Biller:
 Fetch is Mandatory
 Biller does not accept ad-hoc payment
 Biller accepts exact payment

Attribute: name

Presence : Conditional
Definition : Name of the amount field other than the base bill amount as configured for the Biller in BBPCU
system.
Data Type : Code Set
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type as follows:

Code Definition
Amount 1 Valid amount combination(s) selected from the Biller response other than the base bill amount.
Amount 2 Sample values include Late Fee, Discount, etc.
Amount 3

Attribute: value

Presence : Conditional
Definition : Specified value as defined (in paise).
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type as follows:

Code Format Example

Amount 1 Selected from the Biller response other than  Late Fee: 32000
Amount 2 the base bill amount.  Discount: 2000
Amount 3

BBPS API SPECIFICATIONS | Version 14.0

131

Element: <PaymentInformation>

Presence : Conditional
Definition : Details of the payment instrument used for the payment. This tag will flow from Customer BBPOU
to BBPCU but will not be forwarded to Biller BBPOU.

Element: <PaymentInformation.Tag>

Presence : Conditional
Definition : Payment instrument details which is used for the bill payment transaction.

Attribute: name

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
Aadhaar|IIN Aadhaar number and IIN used for the payment

Attribute: value

Presence : Conditional
Definition : Specified value as defined.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

Code Format Example

Remarks Alphanumeric Special UNI000
Min Length – 1, Max Length – 50
CardNum|AuthCode Alphanumeric with characters on either side of ‘|’ separator 1234567890123456|123456
Min Length – 3, Max Length – 50
IFSC|AccountNo Alphanumeric with characters on either side of ‘|’ separator SRAN0000341|0123456
Min Length – 3, Max Length – 50
MMID|MobileNo Numeric with characters on either side of ‘|’ separator 9240111|9004644121
Fixed Length – 18
WalletName|MobileNo Alphanumeric with characters on either side of ‘|’ separator TA Wallet|9004644121
Min Length – 12, Max Length – 50
VPA Alphanumeric Special manoj@icici
Min Length – 3, Max Length – 50
Aadhaar|IIN Alphanumeric with characters on either side of ‘|’ separator 123456789012|1234567
Min Length – 3, Max Length – 50

BBPS API SPECIFICATIONS | Version 14.0

132

Element: <errorMessages>

Presence : Conditional
Definition : Error messages in the API message.

Element: <errorMessages.errorCd>

Presence : Conditional
Definition : Error Code for API message.

Element: <errorMessages.errorDtl>

Presence : Conditional
Definition : Error Reason for the API message.

Attribute: api

Presence : Mandatory
Definition : Name of the API for which acknowledgement is given out.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type as follows:

API Name Code

BillFetchRequest FETCH_REQUEST
BillFetchResponse FETCH _RESPONSE
BillPaymentRequest PAYMENT_REQUEST
BillPaymentResponse PAYMENT_RESPONSE
TxnStatusRequest FOUR_ZERO_TWO_REQUEST
TxnStatusResponse FOUR_ZERO_TWO_RESPONSE
BillValidationRequest VALIDATION_REQUEST
BillValidationResponse VALIDATION_RESPONSE
TxnStatusComplainRequest CMS_REQUEST
TxnStatusComplainResponse CMS_RESPONSE
BillerFetchRequest BILLER_REQUEST
BillerFetchResponse BILLER_RESPONSE
AgentFetchRequest AGENT_REQUEST
AgentFetchResponse AGENT_RESPONSE
BBPSPlanMDMPush (BOU to CU) PLAN_MDM_PUSH_BOU_TO_CU
BBPSPlanMDMPush (CU to COU/AI) PLAN_MDM_PUSH_CU_TO_COU
BBPSPlanMDMPull (COU/AI to CU) PLAN_MDM_PULL_COU_TO_CU
BBPSPlanMDMPull (CU to BOU) PLAN_MDM_PULL_CU_TO_BOU
BillerStatusUpdate BILLER_STATUS_UPDATE
BillerActivationCheckRequest BILLER_ACTIVATION_CHECK_REQUEST
BillerActivationCheckResponse BILLER_ACTIVATION_CHECK_RESPONSE
BillerStatus BILLER_STATUS

Attribute: RspCd

Presence : Mandatory
Definition : Denotes success or failure in receiving the original request message.
Data Type : Code Set

BBPS API SPECIFICATIONS | Version 14.0

133

Format : Min Length – 1, Max Length – 50

Compliance : Data format and type.
Possible values are Successful, VALIDATION_ERR, DUPLICATE_REQ, etc.

Attribute: ts

Presence : Mandatory
Definition : Transmission date and time of the transaction.
Data Type : ISODateTime
Format : Fixed Length – 25 i.e., YYYY-MM-DDThh:mm:ss+hh:mm (e.g. 2017-02-14T13:10:15+05:30)
Where,
YYYY = four-digit year
MM = two-digit month number (01 indicates 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 (+05:30).
Compliance : Data format and type.

Element: <TxnStatusComplainReq>

Presence : Mandatory
Definition : Information pertaining to transaction status and complaint related requests.

Attribute: complaintType

Presence : Mandatory
Definition : Type of complaint – Transaction or Service based complaint.
Data Type : Code Set
Format : Min Length – 1, Max Length – 11
Compliance : Accepted value is "Transaction".

Attribute: mobile

Presence : Conditional
Definition : Mobile number against which the transaction status is to be searched.
Data Type : Numeric
Format : Fixed Length – 10
Compliance : Data format and type.

Attribute: complaintId

Presence : Conditional
Definition : Complaint ID generated by BBPCU to check the complaint status, re-assign or close a complaint
subsequently.
Data Type : Alphanumeric
Format : Fixed Length – 15; 1st 4 characters of Tran Ref ID – 4, Julian Date of the Complaint Registration Date
(YYDDD) - 5, Random Numeric – 6

BBPS API SPECIFICATIONS | Version 14.0

134

Compliance : Data format and type.

Attribute: disposition

Presence : Conditional
Definition : Disposition for transaction based complaints.
Data Type : Code Set
Format : Min Length – 1, Max Length – 100
Compliance : Disposition details should be sent per the list shown below.

Issue Related To Master Disposition List

Transaction Transaction Successful, account not updated
Transaction Amount deducted, biller account credited but transaction ID not received
Transaction Amount deducted, biller account not credited & transaction ID not received
Transaction Amount deducted multiple times
Transaction Double payment updated
Transaction Erroneously paid in wrong account
Transaction Others, provide details in description

Attribute: description

Presence : Conditional
Definition : Description of the complaint where the customer may provide some additional information on the
reason for raising the complaint.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100
Compliance : Data format and type.

Element: <TxnSearchDateCriteria>

Presence : Conditional
Definition : Searching the transaction details on the basis of date range.

Attribute: fromDate

Presence : Conditional
Definition : This field denotes the start date for transaction search.
Data Type : ISO Date
Format : Fixed Length – 10, e.g. 2016-01-01
Compliance : Data format and type.

Attribute: toDate

Presence : Conditional
Definition : This field denotes the end date for transaction search.
Data Type : ISO Date
Format : Fixed Length – 10, e.g. 2016-01-01
Compliance : Data format and type.

BBPS API SPECIFICATIONS | Version 14.0

135

TxnStatusComplainReq attribute details:

Attribute Presence Required in Xchange ID

msgId Mandatory 401, 501, 502, 503, 506, 507 and 508 Requests
complaintType Mandatory 401, 501, 502, 503, 506, 507 and 508 Requests
mobile Conditional 401 Request
fromDate Conditional 401 Request
toDate Conditional 401 Request
txnReferenceId Conditional 401 and 501 Requests
complaintId Conditional 502, 503, 506, 507 and 508 Requests
disposition Conditional 501 Request
description Conditional 501, 502, 503 and 507 Requests

Element: <TxnStatusComplainResp>

Presence : Mandatory
Definition : Information pertaining to transaction status and complaint related responses.

Attribute: responseCode

Presence : Mandatory
Definition : Carries the response code indicating success or failure of CMS API request.
Data Type : Code Set
Format : Fixed Length – 3
Compliance : Response code should be sent per the response code list shown below.

Response Code Response Reason

000 SUCCESS
001 No Transaction found / Complaint not found

Attribute: responseReason

Response Code Response Reason

000 SUCCESS
001 No Transaction found / Complaint not found

Attribute: complaintId

Presence : Conditional
Definition : Complaint ID generated by BBPCU to check the complaint status, re-assign or close a complaint
subsequently.
Data Type : Alphanumeric

BBPS API SPECIFICATIONS | Version 14.0

136

Format : Fixed Length – 15; 1st 4 characters of Tran Ref ID – 4, Julian Date of the Complaint Registration Date
(YYDDD) - 5, Random Numeric – 6
Compliance : Data format and type.

Attribute: assigned

Presence : Conditional
Definition : Name of BBPOU to which the complaint is assigned.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100
Compliance : The BBPOU should present in the BBPCU system.

Attribute: openComplaint

Presence : Conditional
Definition : Flag indicating if the transaction based complaint being raised is currently open in the system or not
– "Y" will show the details for the complaint raised earlier.
Data Type : Code Set
Format : Fixed Length – 1
Compliance : Accepted values are "Y" or "N".

Attribute: complaintStatus

Presence : Conditional
Definition : It denotes the complaint status of the transaction.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
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
Complaint ID has been assigned to it.
By default, it is assigned to the Customer BBPOU. At this stage, the Customer BBPOU
may assign the complaint to the Biller BBPOU depending on the details of the complaint.
Escalated If the BBPOU does not respond to the complaint within the specified TAT, the complaint
gets escalated.
Re Assigned When Customer BBPOU re assigned the complaint to the Biller BBPOU.
Assigned to COU / When BBPCU assign the complaint to BBPOU.
Assigned to BOU / If the COU and BOU are same for a transaction, then the status of complaint will be
Assigned to OU changed to Assigned to OU.
Resolved Once the BBPOU resolves the customer related complaint, the BBPOU updates the
system.
Unresolved If the BBPOU does not respond to the complaint within the specified TAT (Super
escalation), the complaint status changed to unresolved.

Attribute: remarks

Presence : Conditional
Definition : Last updated additional information provided by the BBPOU pertaining to the complaint and
fetched in the complaint status check (506) response.
Data Type : Alphanumeric Special
Format : Min Length – 1, Max Length – 100

BBPS API SPECIFICATIONS | Version 14.0

137

Compliance : Data format and type.

Element: <TxnStatusComplainResp.TxnList>

Presence : Conditional
Definition : List of transactions containing the details of transactions linked to a mobile number and date range
combination.

Element: <TxnStatusComplainResp.TxnList.TxnDetail>

Presence : Conditional
Definition : Record containing the details of a single transaction.

Attribute: txnReferenceId

Presence : Conditional
Definition : Transaction reference number used by the Customer for referring to a payment transaction.
Data Type : Alphanumeric
Format : Fixed Length – 12 or 20
i) Originating Institution ID (Customer OU Id or Participating AI Id) - 04, Random alphanumeric - 08
ii) Originating Institution ID (Customer OU Id or Participating AI Id) - 04, Julian Date - 04 and Random
alphanumeric - 12
Compliance : Data format and type.

Attribute: amount

Presence : Conditional
Definition : Amount (in paise) involved in the payment transaction.
Data Type : Numeric
Format : Min Length – 1, Max Length – 18
Compliance : Data format and type.

Attribute: txnDate

Presence : Conditional
Definition : Date of the bill payment transaction.
Data Type : ISODateTime
Format : Fixed Length – 25 i.e., YYYY-MM-DDThh:mm:ss+hh:mm (e.g. 2017-02-14T13:10:15+05:30)
Where,
YYYY = four-digit year
MM = two-digit month number (01 indicates 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 (+05:30).
Compliance : Data format and type.

BBPS API SPECIFICATIONS | Version 14.0

138

Attribute: agentId

Presence : Conditional
Definition : Agent ID of the Agent involved in the transaction.
Data Type : Alphanumeric
Format : Fixed Length – 20, e.g. OU01OU02INT000000001
Where,
 Customer BBPOU ID – 4
 Agent Institution ID – 4
 Agent Payment Channel Code – 3
 Random number – 9
Compliance : Data format and type.

Attribute: billerId

Presence : Conditional
Definition : Biller ID of the Biller involved in the transaction.
Data Type : Alphanumeric
Format : Fixed Length – 14, e.g. TATAPWR00DEL01
Where,
 Short identifier of the biller (may be augmented with trailing zeroes) - 9
 Coverage - 3
 Random number - 2
Compliance : Data format and type.

Attribute: txnStatus

Presence : Conditional
Definition : Status of the transaction – successful or failure.
Data Type : Code Set
Format : Min Length – 1, Max Length – 50
Compliance : Data format and type.

Element: <TxnStatusComplainResp.CustomerDetails>

Presence : Conditional
Definition : Details of the customer for a successful transaction search (401) response.

Attribute: mobile

Presence : Conditional
Definition : Mobile number linked to the transaction(s).
Data Type : Numeric
Format : Minimum Length – 6, Maximum Length - 20
Compliance : Data format and type.

Element: <SearchMyBiller>

Presence : Optional
Definition : Search the Biller details associated or non-associated with the BBPOU initiating the request.

BBPS API SPECIFICATIONS | Version 14.0

139

Attribute: mybiller

Presence : Conditional
Definition : Flag indicating request for the Biller details associated or non-associated with the BBPOU initiating
the request.
Data Type : Code Set
Format : Min Length – 2, Max Length – 3
Compliance : Accepted values are "Yes" or "No".

Element: <Search>

Presence : Optional
Definition : Search the Biller or Agent details based on certain parameters.

Element: <Search.billerId>

Presence : Conditional
Definition : Biller ID for which the Biller details are requested.

Element: <Search.billerCategory>

Presence : Conditional
Definition : Biller Category for which the Biller details are requested.

Element: <Search.agentId>

Presence : Conditional
Definition : Agent ID for which the Agent details are requested.

Element: <SearchByTime>

Presence : Optional
Definition : Searching the Biller or Agent details based on time parameter.

Element: <SearchByTime.time>

Presence : Conditional
Definition : Request for Biller or Agent details for all the Billers or Agents updated in the system after the time
provided.

Element: <biller>

Presence : Conditional
Definition : MDM details of the Biller.

Element: <biller.billerId>

Presence : Mandatory
Definition : Identifier of the Biller.

BBPS API SPECIFICATIONS | Version 14.0

140

Element: <biller.billerName>

Presence : Mandatory
Definition : Name of the Biller.

Element: <biller.billerAliasName>

Presence : Mandatory
Definition : Alias name of the Biller.

Element: <biller.billerCategoryName>

Presence : Mandatory
Definition : Biller category.

Element: <biller.billerMode>

Presence : Mandatory
Definition : Biller mode, i.e., Online, Offline A, Offline B.

Element: <biller.billerAcceptsAdhoc>

Presence : Mandatory
Definition : Flag indicating if the Biller accepts adhoc payment.

Element: <biller.parentBiller>

Presence : Mandatory
Definition : Flag indicating if the Biller is a parent Biller.

Element: <biller.parentBillerId>

Presence : Conditional
Definition : Identifier of the parent Biller.

Element: <biller.billerOwnerShp>

Presence : Mandatory
Definition : Biller ownership, i.e., Government, PSU, Private.

Element: <biller.billerCoverage>

Presence : Mandatory
Definition : Coverage of the Biller, i.e., National, State/UT, City/District.

Element: <biller.fetchRequirement>

Presence : Mandatory
Definition : Indicates if the Biller allows Bill Fetch or not – possible values are MANDATORY, OPTIONAL,
NOT_SUPPORTED.

BBPS API SPECIFICATIONS | Version 14.0

141

Element: <biller.supportBillValidation>

Presence : Mandatory
Definition : Indicates if the Biller allows Bill Validation or not – possible values are MANDATORY, OPTIONAL,
NOT_SUPPORTED.

Element: <biller.paymentAmountExactness>

Presence : Conditional
Definition : Indicates if the Biller (having Mandatory Bill Fetch) allows exact payment or not – possible values
are Exact, Exact and above, Exact and below.

Element: <biller.billerEffctvFrom>

Presence : Mandatory
Definition : Effective from date of the Biller.

Element: <biller.billerEffctvTo>

Presence : Mandatory
Definition : Effective to date of the Biller.

Element: <biller.billerTempDeactivationStart>

Presence : Mandatory
Definition : Temporary deactivation start date of the Biller.

Element: <biller.billerTempDeactivationEnd>

Presence : Mandatory
Definition : Temporary deactivation end date of the Biller.

Element: <biller.billerPaymentModes>

Presence : Mandatory
Definition : Payment mode details of the Biller.

Element: <biller.billerPaymentModes.paymentMode>

Presence : Mandatory
Definition : Payment modes supported by the Biller.

Element: <biller.billerPaymentModes.maxLimit>

Presence : Conditional
Definition : Maximum limit accepted by a Biller for a particular payment mode.

Element: <biller.billerPaymentModes.minLimit>

Presence : Mandatory
Definition : Minimum limit accepted by a Biller for a particular payment mode.

BBPS API SPECIFICATIONS | Version 14.0

142

Element: <biller.billerPaymentModes.supportPendingStatus>

Presence : Conditional
Definition : Flag indicating whether Pending Status is applicable for the payment mode or not – Yes/No.

Element: <biller.billerPaymentChannels>

Presence : Mandatory
Definition : Payment channel details of the Biller.

Element: <biller.billerPaymentChannels.paymentChannel>

Presence : Mandatory
Definition : Payment channels supported by the Biller.

Element: <biller.billerPaymentChannels.maxLimit>

Presence : Conditional
Definition : Maximum limit accepted by a Biller for a particular payment channel.

Element: <biller.billerPaymentChannels.minLimit>

Presence : Mandatory
Definition : Minimum limit accepted by a Biller for a particular payment channel.

Element: <biller.billerPaymentChannels.supportPendingStatus>

Presence : Conditional
Definition : Flag indicating whether Pending Status is applicable for the payment channel or not – Yes/No.

Element: <biller.billerCustomerParams>

Presence : Mandatory
Definition : Customer parameter details of the Biller.
Element: <biller.billerCustomerParams.paramName>

Presence : Mandatory
Definition : Customer parameter name.

Element: <biller.billerCustomerParams.dataType>

Presence : Mandatory
Definition : Customer parameter data type.

Element: <biller.billerCustomerParams.optional>

Presence : Mandatory
Definition : Flag indicating if the Customer parameter is optional.

BBPS API SPECIFICATIONS | Version 14.0

143

Element: <biller.billerCustomerParams.minLength>

Presence : Conditional
Definition : Minimum length of the Customer parameter.

Element: <biller.billerCustomerParams.maxLength>

Presence : Conditional
Definition : Maximum length of the Customer parameter.

Element: <biller.billerCustomerParams.regex>

Presence : Conditional
Definition : Regular expression (RegEx) is a string of characters representing permissible values of the customer
parameters for a biller.

Element: <biller.billerCustomerParams.values>

Presence : Conditional
Definition : Default (possible) values list against a Customer Parameter.

Element: <biller.billerCustomerParams.visibility>

Presence : Mandatory
Definition : Visibility of the customer parameter in COU/AIs front-end screen. Possible values "true/false".

Element: < biller.customerParamGroups>

Presence : Conditional
Definition : Customer Parameter Groups with respect to the various combinations supported.

Element: < biller.customerParamGroups.group>

Presence : Conditional
Definition : Customer Parameter Group.

Element: < biller.customerParamGroups.group.name>

Presence : Conditional
Definition : Name of the Parent/Sub-Group.

Element: < biller.customerParamGroups.group.input>

Presence : Conditional
Definition : Flag indicating the required number of tags from the group.

Element: < biller.customerParamGroups.group.param>

Presence : Conditional
Definition : Customer parameter name.

BBPS API SPECIFICATIONS | Version 14.0

144

Element: <biller.billerResponseParams>

Presence : Mandatory
Definition : Biller Responses with respect to the various amount combinations supported.

Element: <biller.billerResponseParams.amountOptions>

Presence : Mandatory
Definition : Amount options supported by the Biller.

Element: <biller.billerResponseParams.amountOptions.amountBreakupSet>

Presence : Mandatory
Definition : Amount combination for a particular amount option.

Element: <biller.billerAdditionalInfo>

Presence : Conditional
Definition : Additional information details provided by the Biller.

Element: <biller.billerAdditionalInfo.paramName>

Presence : Conditional
Definition : Additional information parameter name.

Element: <biller.billerAdditionalInfo.dataType>

Presence : Conditional
Definition : Additional information parameter data type.

Element: <biller.billerAdditionalInfo.optional>

Presence : Conditional
Definition : Flag indicating if the additional information parameter is optional.

Element: <biller.billerAdditionalInfoPayment>

Presence : Conditional
Definition : Additional information details provided by the Biller.

Element: <biller.billerAdditionalInfoPayment.paramName>

Presence : Conditional
Definition : Additional information parameter name.

Element: <biller.billerAdditionalInfoPayment.dataType>

Presence : Conditional
Definition : Additional information parameter data type.

BBPS API SPECIFICATIONS | Version 14.0

145

Element: <biller.billerAdditionalInfoPayment.optional>

Presence : Conditional
Definition : Flag indicating if the additional information parameter is optional.

Element: <biller.interchangeFeeConf>

Presence : Mandatory
Definition : Interchange fee configuration details of the Biller.

Element: <biller.interchangeFeeConf.mti>

Presence : Mandatory
Definition : Message Type Indicator for the fee, i.e., fetch, payment, etc.

Element: <biller.interchangeFeeConf.responseCode>

Presence : Mandatory
Definition : Response code associated with the fee.

Element: <biller.interchangeFeeConf.paymentMode>

Presence : Conditional
Definition : Payment mode associated with the fee.

Element: <biller.interchangeFeeConf.paymentChannel>

Presence : Conditional
Definition : Payment channel associated with the fee.

Element: <biller.interchangeFeeConf.fees>

Presence : Mandatory
Definition : Fee codes for applicable interchange fee.

Element: <biller.interchangeFeeConf.defaultFee>

Presence : Mandatory
Definition : Flag indicating if it is a default fee or not.

Element: <biller.interchangeFeeConf.effctvFrom>

Presence : Mandatory
Definition : Effective from date for the fee.

Element: <biller.interchangeFeeConf.effctvTo>

Presence : Mandatory
Definition : Effective to date for the fee.

BBPS API SPECIFICATIONS | Version 14.0

146

Element: <biller.interchangeFee>

Presence : Mandatory
Definition : Interchange fee details of the Biller.

Element: <biller.interchangeFee.feeCode>

Presence : Mandatory
Definition : Fee code associated with the Biller.

Element: <biller.interchangeFee.feeDesc>

Presence : Mandatory
Definition : Description of the corresponding fee code.

Element: <biller.interchangeFee.feeDirection>

Presence : Mandatory
Definition : Direction of fee movement, i.e., Customer BBPOU to Biller BBPOU or vice-versa.

Element: <biller.interchangeFee.interchangeFeeDetails>

Presence : Mandatory
Definition : Interchange fee details pertaining to range, type and validity.

Element: <biller.interchangeFee.interchangeFeeDetails.tranAmtRangeMax>

Presence : Mandatory
Definition : Maximum range for a particular fee configuration.

Element: <biller.interchangeFee.interchangeFeeDetails.tranAmtRangeMin>

Presence : Mandatory
Definition : Minimum range for a particular fee configuration.

Element: <biller.interchangeFee.interchangeFeeDetails.percentFee>

Presence : Mandatory
Definition : Percentage fee details.

Element: <biller.interchangeFee.interchangeFeeDetails.flatFee>

Presence : Mandatory
Definition : Flat fee details.

Element: <biller.interchangeFee.interchangeFeeDetails.effctvFrom>

Presence : Mandatory
Definition : Effective from date for the fee configuration.

BBPS API SPECIFICATIONS | Version 14.0

147

Element: <biller.interchangeFee.interchangeFeeDetails.effctvTo>

Presence : Mandatory
Definition : Effective to date for the fee configuration.

Element: <biller.Status>

Presence : Mandatory
Definition : Status of the Biller, i.e., active, deactivated, etc.

Element: <biller.billerDescription>

Presence : Optional
Definition : Additional information related to Billers.

Element: <biller.supportDeemed>

Presence : Optional
Definition : Flag indicating whether deemed success is applicable for the biller or not – Yes/No.

Element: <biller.supportPendingStatus>

Presence : Optional
Definition : Flag indicating whether pending status is applicable for the biller or not – Yes/No.

Element: <biller.billerTimeOut>

Presence : Conditional
Definition : Final Timeout of the Biller in minutes, which supports Pending Status.

Element: <biller.planMdmRequirement>

Presence : Optional
Definition : Flag indicating whether Plan MDM is applicable for the biller or not –
MANDATORY/OPTIONAL/NOT_SUPPORTED.

Element: <biller.planAdditionalInfo>

Presence : Conditional
Definition : Plan Additional information details provided by the Biller.

Element: <biller.planAdditionalInfo.paramName>

Presence : Conditional
Definition : Plan Additional information parameter name.

Element: <biller.planAdditionalInfo.dataType>

Presence : Conditional
Definition : Plan Additional information parameter data type.

BBPS API SPECIFICATIONS | Version 14.0

148

Element: <biller.planAdditionalInfo.optional>

Presence : Conditional
Definition : Flag indicating if the additional information parameter is optional.

Element: <Agent>

Presence : Conditional
Definition : MDM details of the Agent.

Element: <Agent.agentId>

Presence : Mandatory
Definition : Identifier of the Agent.

Element: <Agent.agentBusnsType>

Presence : Mandatory
Definition : Business type of the Agent.

Element: <Agent.agentName>

Presence : Mandatory
Definition : Name of the Agent.

Element: <Agent.agentAliasName>

Presence : Mandatory
Definition : Alias name of the Agent.

Element: <Agent.agentLinkedAgentInst>

Presence : Mandatory
Definition : Code of the Agent Institution associated with the Agent.

Element: <Agent.agentGeoCode>

Presence : Mandatory
Definition : Agent geo-location.

Element: <Agent.agent_shop_name>

Presence : Mandatory
Definition : Shop name of the Agent.

Element: <Agent.agent_mobile_no>

Presence : Mandatory
Definition : Mobile number of the Agent.

BBPS API SPECIFICATIONS | Version 14.0

149

Element: <Agent.agentDummy>

Presence : Mandatory
Definition : Flag indicating if the Agent represents an electronic or physical channel.

Element: <Agent.agentPaymentModes>

Presence : Mandatory
Definition : Payment mode details of the Agent.

Element: <Agent.agentPaymentModes.paymentMode>

Presence : Mandatory
Definition : Payment modes supported by the Agent.

Element: <Agent.agentPaymentModes.maxLimit>

Presence : Conditional
Definition : Maximum limit accepted by an Agent for a particular payment mode.

Element: <Agent.agentPaymentModes.minLimit>

Presence : Mandatory
Definition : Minimum limit accepted by an Agent for a particular payment mode.

Element: <Agent.agentPaymentChannels>

Presence : Mandatory
Definition : Payment channel details of the Agent.

Element: <Agent.agentPaymentChannels.paymentChannel>

Presence : Mandatory
Definition : Payment channels supported by the Agent.

Element: <Agent.agentPaymentChannels.maxLimit>

Presence : Conditional
Definition : Maximum limit accepted by an Agent for a particular payment channel.

Element: <Agent.agentPaymentChannels.minLimit>

Presence : Mandatory
Definition : Minimum limit accepted by an Agent for a particular payment channel.

Element: <Agent.agentBulk>

Presence : Mandatory
Definition : Flag indicating if the Agent is configured through bulk upload feature in BBPS Canvas (intranet
portal).

BBPS API SPECIFICATIONS | Version 14.0

150

Element: <Agent.agentRefId>

Presence : Mandatory
Definition : ID used by a BBPOU / Agent Institution to internally identify an Agent.

Element: <Agent.agentPinCode>

Presence : Mandatory
Definition : PIN Code of the Agent.

Element: <Agent.agentRegisteredCity>

Presence : Mandatory
Definition : Registered city of the Agent.

Element: <Agent.agentRegisteredState>

Presence : Mandatory
Definition : Registered state of the Agent.

Element: <Agent.agentRegisteredAddress>

Presence : Mandatory
Definition : Registered address of the Agent.

Element: <Agent.agentRegisteredCountry>

Presence : Mandatory
Definition : Registered country of the Agent.

Element: <Agent.agentEffctvFrom>

Presence : Mandatory
Definition : Effective from date of the Agent.

Element: <Agent.agentEffctvTo>

Presence : Mandatory
Definition : Effective to date of the Agent.

Element: <Agent.agentTempDeactivationStart>

Presence : Mandatory
Definition : Temporary Deactivation Start date of the Agent.

Element: <Agent.agentTempDeactivationEnd>

Presence : Mandatory
Definition : Temporary deactivation end date of the Agent.

BBPS API SPECIFICATIONS | Version 14.0

151

Element: <Agent.agentStatus>

Presence : Mandatory
Definition : Status of the Agent, i.e., active, deactivated, etc.

API: BBPSPlanMDMPush

Attribute: type

Presence : Mandatory
Definition : Type of the Plan MDM Push – "REQUEST/RESPONSE".

Element: <PlanDetails>

Presence : Mandatory
Definition : Plan Details of the specific biller.

Element: <PlanDetails.Id>

Presence : Mandatory
Definition : Plan ID as defined by the Biller.
Data Type : Alpha Numeric
Format : Minimum Length – 1, Maximum Length - 32
Compliance : Plan ID has to share with BBPCU as defined by the Biller.

Element: <PlanDetails.billerId>

Presence : Mandatory
Definition : Biller ID for which Plan Details are available.

Element: <PlanDetails.categoryType>

Presence : Mandatory
Definition : Plan Category.
Data Type : Alpha Numeric
Format : Minimum Length – 1, Maximum Length - 100
Compliance : Plan category as defined by the Biller.

Element: <PlanDetails.categorySubType>

Presence : Optional
Definition : Plan Sub Category.
Data Type : Alpha Numeric
Compliance : Plan sub category as defined by the Biller.

Element: <PlanDetails.amountInRupees>

Presence : Mandatory
Definition : Denomination of the Plan Amount in Rupees.
Data Type : Numeric/Decimal
Format : Minimum Length – 1, Maximum Length - 10

BBPS API SPECIFICATIONS | Version 14.0

152

Compliance : Plan amount as defined by the Biller.

Element: <PlanDetails.planDescription>

Presence : Mandatory
Definition : Plan Description.
Data Type : Alpha Numeric Special
Format : Text
Compliance : Plan description as defined by the Biller.

Element: <PlanDetails.planAdditionalInfo>

Presence : Conditional
Definition : Plan Additional information details provided by the Biller.

Element: <PlanDetails.planAdditionalInfo.paramName>

Presence : Conditional
Definition : Plan Additional information parameter name.

Element: <PlanDetails.planAdditionalInfo.paramValue>

Presence : Conditional
Definition : Plan Additional information parameter value.

Element: <PlanDetails.effctvFrom>

Presence : Mandatory
Format : ISO Date Format
Definition : Effective from date of corresponding Plan.

Element: <PlanDetails.effctvTo>

Presence : Mandatory
Format : ISO Date Format
Definition : Effective to date of corresponding Plan.

Element: <PlanDetails.Status>

Presence : Mandatory
Definition : Status of the Plan. Possible Values "ACTIVE" / "DEACTIVATED".

API: BBPSPlanMDMPull

Attribute: type

Presence : Mandatory
Definition : Type of the Plan MDM Push – "REQUEST ".

BBPS API SPECIFICATIONS | Version 14.0

153

Element: <Search>

Presence : Optional
Definition : Search the Plan details based on certain parameters.

Element: <Search.billerId>

Presence : Conditional
Definition : Biller ID for which the Plan details are requested.

Element: <SearchByTime>

Presence : Optional
Definition : Searching the Plan details based on time parameter.

Element: <SearchByTime.time>

Presence : Conditional
Definition : Request for Plan details for all the Plans updated in the system after the time provided.

BBPS API SPECIFICATIONS | Version 14.0

154

24 Appendix
List of Error Messages

ErrorCodeWithMessa
ges v6.0.xlsx

File Naming Convention for Settlement Files

Naming Convention
for BBPS Settlement Files v3.0.docx

BBPS API SPECIFICATIONS | Version 14.0

BBPS API Specifications v13.0
No ratings yet
BBPS API Specifications v13.0
134 pages
BBPS Agent Integration v2.6
No ratings yet
BBPS Agent Integration v2.6
113 pages
Corporate
No ratings yet
Corporate
30 pages
Bharat Bill Payment System - Version - 2.4
No ratings yet
Bharat Bill Payment System - Version - 2.4
88 pages
Collect API
No ratings yet
Collect API
20 pages
BillDesk - BBPS Product Presentation
No ratings yet
BillDesk - BBPS Product Presentation
23 pages
ICICI API Specification V1.2
No ratings yet
ICICI API Specification V1.2
42 pages
M-PESA B2C API Specification
No ratings yet
M-PESA B2C API Specification
41 pages
Documentation Maja Integration Api Original
No ratings yet
Documentation Maja Integration Api Original
12 pages
SV Epg-202306.1-Api-Spec en Core 20230914
No ratings yet
SV Epg-202306.1-Api-Spec en Core 20230914
541 pages
Napas - TechSpec For QR Payment - API - Bank - v0.8
No ratings yet
Napas - TechSpec For QR Payment - API - Bank - v0.8
102 pages
BBPS Guidelines For Biller Integration
No ratings yet
BBPS Guidelines For Biller Integration
29 pages
QR Api
No ratings yet
QR Api
19 pages
Composite Pay Api - 1.18
No ratings yet
Composite Pay Api - 1.18
60 pages
Web Payment Integration Guide
No ratings yet
Web Payment Integration Guide
8 pages
SDP Solution API Reference (MobileMoney)
100% (1)
SDP Solution API Reference (MobileMoney)
222 pages
PP API Reference
No ratings yet
PP API Reference
272 pages
Refund API Documentation Guide
No ratings yet
Refund API Documentation Guide
12 pages
Payment Gateway Integration Guide
No ratings yet
Payment Gateway Integration Guide
69 pages
Pocket PGW API Doc v2 0 1
No ratings yet
Pocket PGW API Doc v2 0 1
8 pages
Service Contracts Public API-1
100% (1)
Service Contracts Public API-1
65 pages
2C2P-Airline Payment v1 5 6
No ratings yet
2C2P-Airline Payment v1 5 6
43 pages
Merchant API Documentation-4
No ratings yet
Merchant API Documentation-4
7 pages
Web Service API: Integration Guide
No ratings yet
Web Service API: Integration Guide
124 pages
Documentation Paymob
No ratings yet
Documentation Paymob
58 pages
BBPS Product Deck - Worldline
No ratings yet
BBPS Product Deck - Worldline
14 pages
Middleware API Documentaion 2.0
No ratings yet
Middleware API Documentaion 2.0
6 pages
Bkash Parameter - Requirement-9-10-2019
No ratings yet
Bkash Parameter - Requirement-9-10-2019
4 pages
HDFC API Doc v1.3
No ratings yet
HDFC API Doc v1.3
172 pages
HDFC API Document
100% (1)
HDFC API Document
160 pages
NSN in CORBA Payment Plugin - Interface - New
No ratings yet
NSN in CORBA Payment Plugin - Interface - New
91 pages
TechnicalSpecifications - Domestic Payments API V1.3.13
No ratings yet
TechnicalSpecifications - Domestic Payments API V1.3.13
69 pages
M-PESA B2C Development Guide
No ratings yet
M-PESA B2C Development Guide
52 pages
OnboardingManual - UPI - API v1
No ratings yet
OnboardingManual - UPI - API v1
12 pages
Generic Online Message Rest Based Specifications
No ratings yet
Generic Online Message Rest Based Specifications
17 pages
EazyPay API Guide for Merchants
No ratings yet
EazyPay API Guide for Merchants
24 pages
IPG IntegrationGuide API 2023-1
No ratings yet
IPG IntegrationGuide API 2023-1
162 pages
Credit Card Payment Guide BPE 3.0
No ratings yet
Credit Card Payment Guide BPE 3.0
12 pages
ARB Payment Gateway 3.3.0.ARB - REST API Integration Guide - V1.10
No ratings yet
ARB Payment Gateway 3.3.0.ARB - REST API Integration Guide - V1.10
58 pages
Billpocket Stored Card API Guide
No ratings yet
Billpocket Stored Card API Guide
10 pages
V1.5 - PlainAPI 1
No ratings yet
V1.5 - PlainAPI 1
6 pages
MG Notifications Document
No ratings yet
MG Notifications Document
7 pages
Oracle® Receivables: API User Notes Release 11i
No ratings yet
Oracle® Receivables: API User Notes Release 11i
248 pages
Icici API Process
No ratings yet
Icici API Process
52 pages
Banking Integration Guide
No ratings yet
Banking Integration Guide
3 pages
PayPal API Reference
No ratings yet
PayPal API Reference
350 pages
Bse-Starmfv2-Api - V0 9 12
No ratings yet
Bse-Starmfv2-Api - V0 9 12
283 pages
Marx IPG Integration Guide
No ratings yet
Marx IPG Integration Guide
13 pages
PayU Webhooks & Tokenization Guide
No ratings yet
PayU Webhooks & Tokenization Guide
3 pages
IPG IntegrationGuide API NBD
No ratings yet
IPG IntegrationGuide API NBD
103 pages
BBPS Technical Standards v4.0
No ratings yet
BBPS Technical Standards v4.0
19 pages
Create Payment Using REST API
No ratings yet
Create Payment Using REST API
6 pages
RestAPI MonCash Doc
No ratings yet
RestAPI MonCash Doc
9 pages
Transaction Status API
No ratings yet
Transaction Status API
12 pages
IPG - Integration Guide - API - 2024-1
No ratings yet
IPG - Integration Guide - API - 2024-1
177 pages
API Pix Payment
No ratings yet
API Pix Payment
28 pages
Payment Gateway Integration Guide For Merchants-V4.6
100% (1)
Payment Gateway Integration Guide For Merchants-V4.6
98 pages
ARB Payment Gateway REST API Integration Doc - V1.26
No ratings yet
ARB Payment Gateway REST API Integration Doc - V1.26
288 pages
Outro Arquivooo
No ratings yet
Outro Arquivooo
140 pages
Product Casebooks
No ratings yet
Product Casebooks
32 pages
1 s2.0 S2314728816300034 Main
No ratings yet
1 s2.0 S2314728816300034 Main
6 pages
Constant Ground Via Stitching: PCB From The Load Devices To The Power Source. Thus, It Maintains A Healthy
No ratings yet
Constant Ground Via Stitching: PCB From The Load Devices To The Power Source. Thus, It Maintains A Healthy
5 pages
AMTI - 2025 Practice Paper (Class - 08) - II
No ratings yet
AMTI - 2025 Practice Paper (Class - 08) - II
3 pages
Mitsubishi: 7 VCC VCC
No ratings yet
Mitsubishi: 7 VCC VCC
6 pages
Dead Zones: Graphical Analysis: Objectives
No ratings yet
Dead Zones: Graphical Analysis: Objectives
2 pages
Augmented Reality and Night Vision Fusion
No ratings yet
Augmented Reality and Night Vision Fusion
192 pages
Power Supplies Using SCR's
No ratings yet
Power Supplies Using SCR's
11 pages
DAV-S500+BR++Ver+1 3
0% (1)
DAV-S500+BR++Ver+1 3
101 pages
Relnote Erpehp7 en
No ratings yet
Relnote Erpehp7 en
128 pages
Online Job Portal System: Microroot Poc Technology Pvt. LTD
No ratings yet
Online Job Portal System: Microroot Poc Technology Pvt. LTD
29 pages
Central Bank PDF
No ratings yet
Central Bank PDF
2 pages
Metal-Oxide-Semiconductor (MOS) Fundamentals
No ratings yet
Metal-Oxide-Semiconductor (MOS) Fundamentals
5 pages
Apple Mac Boot Key Shortcuts Guide
100% (1)
Apple Mac Boot Key Shortcuts Guide
5 pages
5.Sc 900 Master Cheat Sheet
No ratings yet
5.Sc 900 Master Cheat Sheet
48 pages
DCIT 22 2020 Practice
No ratings yet
DCIT 22 2020 Practice
4 pages
Part 1 Programming Languages C, C++, Python
No ratings yet
Part 1 Programming Languages C, C++, Python
31 pages
Toxic Comment Classification
No ratings yet
Toxic Comment Classification
11 pages
Simcenter Nastran 2019.1 Quick Reference Guide
100% (1)
Simcenter Nastran 2019.1 Quick Reference Guide
2,396 pages
ModarisReleaseNotes en
No ratings yet
ModarisReleaseNotes en
5 pages
Scheme of Work: Cambridge O Level Computer Science 2210
No ratings yet
Scheme of Work: Cambridge O Level Computer Science 2210
41 pages
Ziehm Vision FD
No ratings yet
Ziehm Vision FD
10 pages
Screenshot 2023-03-31 at 3.17.45 PM
No ratings yet
Screenshot 2023-03-31 at 3.17.45 PM
1 page
Tyler Utt
No ratings yet
Tyler Utt
2 pages
Algebra Worksheet
No ratings yet
Algebra Worksheet
3 pages
SAMRA Resume
No ratings yet
SAMRA Resume
2 pages
Managerial Economics Theory Applications and Cases 8th Edition Allen Digital Access
No ratings yet
Managerial Economics Theory Applications and Cases 8th Edition Allen Digital Access
406 pages
ECE 101 Laboratory 1 Basics
No ratings yet
ECE 101 Laboratory 1 Basics
15 pages
HCSP Presales IP+Network 2022 V2.0+Training+Material+
No ratings yet
HCSP Presales IP+Network 2022 V2.0+Training+Material+
527 pages
M A R K E T E R P E O P L E: MCRM / Data Management Agencies Agency Trading Desks
No ratings yet
M A R K E T E R P E O P L E: MCRM / Data Management Agencies Agency Trading Desks
1 page