Unified Presentment
Management System

UPMS stands for Unified Presentment & Management System. It is a product created by NBBL to solve the following challenges:

i. Billers and BOUs faced bandwidth and infrastructure capacity challenges caused by excessive fetch requests. UPMS fetches the bills efficiently from the Billers and shares them with the COUs live on UPMS based on the customer’s consent.

ii. Once a customer’s UPMS registered bill is paid via a supported COU, other COU channels where the customer has registered for the same Biller would get a skip notification to avoid duplicate payments.

UPMS is category agnostic; however, we are enabling it category-wise in phases for all Billers/merchants which support bill payments. The following two flows are supported:

i. Proactive fetch/Presentment: UPMS fetches bills based on the Biller's billing cycle and presents them to COUs.

ii. Bill push: Merchants push bills as & when generated.

A. For COUs: COUs need to undergo certification and consume UPMS APIs.

B. For BOU: i. Proactive fetch flow: No integration efforts are required. Additionally, a flag can be consumed to identify the origin of the fetch.

ii. Bill push flow: BOUs need to establish a mechanism to receive ad-hoc bills from Billers, and consume UPMS APIs to send these bills to UPMS.

The customer will continue to register via any of the front-end channels (COU/AI) live on UPMS. UPMS will enable the COUs to receive the bills on time via the proactive or bill push flow.

i. AutoPay: The COU will debit the customer’s account as per the bill amount. A pre-debit notification will be sent by the front-end platform.

ii. View & Pay: This will act as a reminder to the customer for bill payments, the customer can then choose to pay by authenticating the payment.

Any front-end channel, be it a COU or an AI, will need to consume UPMS APIs and make necessary developments at their end to receive customer registrations.

No. COUs need to register each Biller separately for each customer as per the customer’s consent.

This is specific to category/Biller configurations. A customer can make multiple registrations on different COU/Agent Institution platforms for the same bill. There are three different modes under which a Biller can be configured:

i. Single: The customer is allowed to register once for a particular bill across platforms.

ii. Multiple: The customer can register multiple mandates/standing instructions across platforms, one on each platform.

iii. Special: The customer can be allowed to register the same mandate multiple times on the same platform.

On successful registration, Bharat Connect Central Unit provides a Customer Presentment Registration Number i.e. CPRN to the COU and a corresponding Biller Presentment Registration Number i.e. BPRN to the BOU.

When a customer creates a registration for a bill through any COU channel live with UPMS, a unique CPRN is created and given to COUs by UPMS. A single BPRN is maintained for a bill corresponding to multiple CPRNs.

Bharat Connect/UPMS supports all payment modes across distinct categories as per Biller configurations. The final control lies with the COU as per the modes supported by them.

The COU shares the necessary details with NBBL, which passes it on to the BOU while following necessary data security compliance.

Yes, COUs can migrate existing standing instructions data available with them via presentment registration APIs/Canvas/SFTP.

The payment request first received at UPMS will be accepted (depending on the Biller configuration). COUs will handle the SI/mandates as per existing payment mode-specific guidelines.

No, in the scenario where a customer registers via multiple AIs under a single COU, it will pass the first registration instance (single registration request) to the CU. Following registrations from other AIs shall be internally mapped by the COU to the CPRN provided with the first registration.

The customer will have to provide the following details:

i. Maximum amount for auto debit

ii. Validity of the mandate

iii. Payment mode details as per guidelines

To avoid missed payments while registering close to the due date, the customer must pay the current bill due and only then register for Autopay effective from the next cycle. COUs/AIs should provide this clarity to the customer at the time of registration.

Based on the option selected, details are shared/not shared with Billers:

Bill push flow: Registration details will be passed to the BOUs.

Pro-active fetch flow: Registration details will not be passed to BOUs.

However, 2 optional tags can be consumed by the BOUs & passed to the Billers at the time of UPMS-initiated fetches: UPMS Flag and CPRN.

There is no amount limit set by UPMS for Autopay registrations. However, the amount limit for the respective payment modes and COUs will apply.

Registration request: It will be passed to BOUs via a round-robin mechanism, the same way as it works on Bharat Connect.

Bill push: The Biller will be able to push bills to UPMS via any BOU, and not just the one associated with registration.

Bill payment: It will be routed through the BOU mapped with the presentment request.

Yes, Bharat Connect recommends COUs to facilitate the cancellation/modification of an existing registration at any time from their original point of registration (refer to Bharat Connect approach note).

COU only sends modification details to CU for changes in registration type (Autopay to View-and-Pay or vice versa) and validity date for the mandate.

The COU will share registration cancellation with the CU only when a customer cancels the registration for the applicable categories from all AIs under the COU, thus if the customer has an active registration with at least one AI, their registration is live on COU.

The CU will share registration cancellation with the BOU only when the customer cancels registration from all COUs, thus if the customer has an active registration with at least one AI, their registration is live on CU.

No, the Biller cannot have both flows configured.

For Proactive Bill Fetch Billers, CU will configure a bill cycle logic based on the Biller’s billing cycle, and trigger fetch API daily accordingly. In Bill Push flow, no fetch is initiated by UPMS, the bills are pushed to UPMS, by BOU/Biller, when ready.

Once available, new bills will be presented from CU to COUs via callback APIs. COUs registered with UPMS are not expected to fetch any bills from CU.

For both Pro-active Fetch & Bill Push flow, as soon as new bills are available, CU will initiate bill presentment callback to all COUs where the customer has registered for that bill. Only one successful presentation per billing cycle will be made to the COU.

There is a bill presentation enquiry API to fetch data of callbacks missed in the last 24 hours. For missed callbacks older than 24 hours, COU can use the Bill Fetch APIs under Bharat Connect.

There is a provision for bill presentment enquiry API to fetch data of callbacks missed in the last 24 hours. COUs will need to initiate an enquiry API request or schedule this hourly to check on missed callbacks.

COUs are expected to pass CPRN and the ‘refId’ passed at the time of bill presentation in the ‘origRefId’ tag in Bill Payment API.

Once payment for a particular bill cycle is completed from a certain COU, the UPMS has the functionality to send a ‘Skip Payment’ notification API to the remaining COUs where the customer has registered. UPMS also performs duplication checks for values passed in the ‘origRefId’ tag in the Bill Payment API.

In the scenario where a customer completes a payment from a channel outside of UPMS, UPMS would rely on the Biller to reject the payment in that cycle or adjust the amount of additional payment received in the next bill cycle.

Yes, the customer will have to authorise payments in the scenarios mentioned below:

i. All view & pay registrations.

ii. For Autopay registrations where the bill amount is higher than the limit set by the customer during registration.

If the payment is within the limit set by the customer & under the recurring amount limit as per the regulator (RBI) for that payment mode, authentication is not required at the time of payment.

In this scenario, the COU can follow a retry mechanism; it lies at the discretion of the COU.

The COU is expected to treat the registration as ‘View and Pay’ for that billing cycle. The COU should send a communication to the customer with a reminder to authorise & pay the current bill, highlighting that the bill amount exceeds the maximum SI/mandate/Autopay amount set up by the customer.

UPMS will send skip notification APIs to all COUs where a customer has registered for either Autopay or View-and-Pay for a bill, except the COU from where the payment was completed.

UPMS will initiate a skip payment notification after a successful payment response is received.

This is completed in near real-time.

This can be handled in the following ways:

i. For Billers where late bill payment details such as revised amount, additional fee etc. are shared in the bill presentment request API, COUs are expected to calculate and update the amount which the customer will need to authorise before making a payment (View and Pay flow).

ii. In case late bill payment details are not available in the bill presentment request, COUs should initiate Bharat Connect Bill Fetch API to get revised details.

UPMS leverages existing Bharat Connect payment APIs for payment.

UPMS payments will follow standard Bharat Connect payment settlement cycles. There is no separate settlement cycle for UPMS.

There is a provision for skip payment notification enquiry API to fetch data of notifications missed in the last 24 hours. COUs will need to initiate enquiry API requests in case they miss the skip payment notification due to any reason. They can schedule this enquiry API on an hourly basis to check on any missed notifications.

UPMS APIs are asynchronous and have a configurable timeout parameter with a maximum of 120 seconds for response and 5 seconds for acknowledgement.

UPMS APIs are supported in XML & JSON format.