> For the complete documentation index, see [llms.txt](https://specs.govstack.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://specs.govstack.global/payments/9-internal-workflows/9.3-p2g-bill-payments.md). # 9.3 P2G Bill Payments The following types of P2G payments are considered. * Bill payments such as utilities * Payments for government services (for example application for a birth certificate) The following is assumed for bill payment with the Payments BB * The Bill ID generation or distribution scenario of a jurisdiction is already decided and in place. * Depending upon the applicable scenario all relevant billers, aggregators or bill payment systems responsible for distributing the Bill IDs to consumers, are also registered with the Payments BB. * The Settlement of bill amounts is carried out by the relevant payers and payee FSPs. * The Payments BB will generate a report or allow a data extract that would contain the log of transactions that would be used for settlement of the transactions between the Payer FSP and the Billers or Aggregators FSPs In order to support multicurrency payments, currency is an important consideration to ensure that bills are paid in the currency raised, as such currency would need to be indicated on bills and payments as indicated in the diagram in section 9.3.3. The following processes are involved in government bill payments: ### **9.3.1 Biller onboarding** The biller onboarding would be a one–time prerequisite activity required to be carried out before consumers could pay bills to them. The main function of Payment BB in this case is allocating unique IDs to the registering entity and ensuring that all Bill Payment related queries are routed to these registered entities. The relationship between billers and aggregators and how they identify specific bills from the consumers numbers is their responsibility, and is out-of-scope for Payments BB.

Biller/Aggregator Onboarding

#### Pre-conditions: * The structure of the unique ID is defined including, the length of the unique ID and whether the ID is simply a sequential number or if each digit of the ID identifies any unique entity/actions. The incoming biller/ aggregator has the required infra to support continuous requests and updates. #### Flow description: * Onboarding Request: This step could be a manual process where a representative gathers all the required information from the billers and aggregators and enters it into the system via a UI-based form/ table. (This process may go through the make checker process) * Unique IDs and Prefixes are generated by the system for each direct biller or aggregator (depending upon the billing ecosystem model). The entire information is saved in the system in the ‘Billers Table’. * The billers and aggregators are returned a unique ID and prefix allocated to them. * The billers and aggregators concatenate the unique ID and prefix before the Bill IDs that they generate and share with their consumers. ### **9.3.2 Payer Financial Institution – PBB Linking for Bill Payments** The Payer FI – PBB linking is a one–time prerequisite activity required before consumers can request bill payment over the Payments BB. Setting up of the front end, UI to take the requests from the consumers would fall under the responsibility of the Payer FI only and would be out of the scope of payments BB #### Pre-conditions: * The Payer FSP is enabled for Interbank Funds Transfer (for settlement) – Out of Scope of PBB * The Payer FSP is equipped with the right infrastructure to communicate with the PBB #### Flow description: Payer FSP – PBB Linking would be an offline process comprising formal agreements and the following activities to ensure proper functioning: * PBB shares the list of Billers and the unique IDs allotted to them with the Payer FSP * PBB shares its endpoints and required API contracts that need to be setup at the FSP; * PBB shares the *required* Bank and Account Details of each registered Biller with the FSP for carrying out financial transactions and settlement activities. The biller details could be either manually configured by the Payer FSP at their end or Payments BB could prepare a file and keep it at a central location for Payer FSP to download/ upload it (as decided). #### Post-conditions: Once the Payer FSP is setup with PBB for Bill Payment Services then it is expected that it: * Would be able to accept from its customers Bill IDs of different Billers. * Would be able to differentiate at its end the exact biller/ aggregator for which the customer has entered the Bill ID. * Would be able to credit the respective account of the biller based on the account information shared by PBB at the time of linking. * Would duly notify the PBB of the final status of the Bill Payment Request (successful debit/ Failed debit) ### **9**.3.3 Bill Inquiry & Bill Payment Update via Payment BB After the completion of the prerequisite setups, the Payment BB is ready to accept requests from the Payer FSPs and retrieve information from and communicate with the Billers, Aggregators, and Government Entities. #### Main responsibilities of Payment BB in the flow: 1. The PBB would receive the Bill Inquiry as a result of Pay Bill request at a Payer FI – Payer end. 2. PBB would validate the sender of request and send it on to the respective Biller or Govt. Entity to fetch bill. 3. The Payer FSP would then either perform payment confirmation or abort the transaction – in either case it would notify the PBB of the Payment Status 4. Receiving the Payment Status Update the PBB would forward the Payment confirmation to Biller or Govt. Entity 5. PBB sends Mark Bill Paid Advice to the Biller or Govt Entity until a response is received from that site. 6. Upon receiving a response from the Biller or Aggregator, the PBB would notify the Payer FSP of the response. 7. The Government Agency sends an invoice to the payer, detailing the amount owed. 8. The Government Agency also sends a copy of the invoice to the designated Bill Aggregator. 9. The Bill Aggregator then sends the invoice reference number to the Payments Building Block . 10. The payer, upon receiving the invoice, provides the invoice reference number to their preferred Collection Financial Service Provider (Collection Financial Services Provider). 11. The Collection Financial Services Provider (FSP) requests transaction details, including the amount to be paid, currency (for multicurrency) from the Payments Building Block using the invoice reference number. 12. The Payments Building Block, in turn, requests the transaction details from the Bill Aggregator. 13. The Bill Aggregator provides the requested transaction details to the Payments Building Block. 14. The Payments Building Block forwards the transaction details to the Collection FSP. 15. The Collection FSP executes the payment based on the transaction details provided. 16. After completing the payment, the Collection FSP sends the payment reference to the Payments Building Block. 17. The Payments Building Block forwards the payment reference to the Bill Aggregator. 18. Finally, the Bill Aggregator sends the payment reference to the Government Agency, confirming the completion of the payment. {% @mermaid/diagram content="sequenceDiagram title Push Payment Flow with Bill Inquiry title P2G Bill Payment via RTP participant "Payer FI" as PayerFI participant PaymentsBB participant ALS participant "Bill Aggregator GovtEntity" as BillAggregator ``` BillAggregator->>PaymentsBB: 1. billerRtpReq (txnID, rtpId, billId, requestType, aliasID (C)) PaymentsBB-->>BillAggregator: billerRtpReq (Ack) alt RTP Type = 00 note over PaymentsBB: Jump to "SEND RTP TO PAYER FI" Step else RTP Type = 01 PaymentsBB->>* ALS: Bill ID is routed to lookup service. ALS->>PaymentsBB: Returns back with Payer FI details. note over PaymentsBB: Jump to "SEND RTP TO PAYER FI" Step end note over PaymentsBB, PayerFI: SEND RTP TO PAYER FI PaymentsBB->>PayerFI: 2. payerRtpReq (txnId, billId, [Bill Details]) PayerFI-->>PaymentsBB: payerRtpResp (Ack) note over PayerFI: Initiate "RTP Notification Sequence - Customer<->FSP" PayerFI->>PaymentsBB: 3. payerRtpResp(txnId, referenceId) PaymentsBB-->>PayerFI: payerRtpResp (Ack) PaymentsBB->>BillAggregator: 4. billerRtpResp (txnId, paymentStatus, referenceId) BillAggregator-->>PaymentsBB: billerRtpResp (Ack) opt If BillAggregator requires status update BillAggregator->>PaymentsBB: rtpStatusUpdate (txnId, rtpID)_Req PaymentsBB-->>BillAggregator: rtpStatusUpdate (Status Code)_Resp end note over PayerFI, BillAggregator: BILL PAYMENT STATUS STAGE note over PayerFI: Initiate "LEG2:PayBill Sequence - Customer/FSP" PayerFI->>PaymentsBB: paymentStatusUpdate(Payment Status, Txn ID, RespCode)_Req PaymentsBB-->>PayerFI: paymentStatusUpdate(Ack) note over PaymentsBB, BillAggregator: Mark Bill == "PAID" Req Sequence loop Mark Bill Payment Advice via SAF PaymentsBB->>BillAggregator: markBillPaid(Bill ID, ReceiptNum, PaymentStatus)_Req note right of PaymentsBB: Payments BB
keeps sending Bill Payment Advice to BillAggregator
until Response received from BillAggregator end BillAggregator-->>PaymentsBB: markBillPaid (Ack) BillAggregator->>PaymentsBB: markBillPaid(MarkStatus, RespCode(C))_Resp PaymentsBB->>PayerFI: paymentStatusUpdate(Payment Status, Txn ID, RespCode)_Resp PayerFI-->>PaymentsBB: paymentStatusUpdate(Ack)" fullWidth="false" %} ``` #### 1. Bill inquiry stage * **Payer FI** initiates the process by querying bill details. * **Payer FI** requests bill inquiry using `billInq(Txn ID, Bill ID)_Req`. * **PaymentsBB** validates the request, performing security checks and registration status verification. * If validations fail, **PaymentsBB** sends an error response to **Payer FI**. * If validations succeed, **PaymentsBB** identifies the biller and moves to the next step. #### 2. Biller discovery * **PaymentsBB** identifies the biller by querying the **Billers Table** using `IdentifyBiller(Prefix)`. * **Billers Table** provides **PaymentsBB** with the Biller's endpoint information. * **PaymentsBB** then proceeds to fetch the bill from the **Bill Aggregator/Government Entity**. #### 3. Fetch Bill * **PaymentsBB** requests bill details from **Bill Aggregator or Government Entity** using `billInqBiller(Bill ID)`. * **Bill Aggregator or Government Entity** performs internal checks (e.g., payment status, expiry) and responds with bill details. * **PaymentsBB** forwards bill details to **Payer FI** for review. #### 4. Bill Payment Status * **Payer FI** reviews the bill details and initiates the payment sequence. * **Payer FI** updates the payment status using `paymentStatusUpdate(Payment Status, Txn ID, RespCode)`. * **PaymentsBB** acknowledges the update and marks the bill as "PAID" in the request sequence. * **PaymentsBB** sends payment advice to **Bill Aggregator or Government Entity** until a response is received. * Once confirmed, **Bill Aggregator or Government Entity** acknowledges the payment and updates the status. * Finally, **PaymentsBB** notifies **Payer FI** of the successful payment update ### 9.3.4 Payer FI – Customer Bill Payment Flow {% @mermaid/diagram content="sequenceDiagram title PayBill Sequence - Customer/FSP participant Payer as Payer participant PayerFI as Payer FI ``` note over Payer, PayerFI: LEG 1: BILL PAYMENT REQUEST Payer->>PayerFI: Pay_Bill_Req (Bill ID) note right of PayerFI: Forwards billInquiry (Bill ID)_Req to PBB note left of PayerFI: Receives billInquiry_Resp from PBB PayerFI->>Payer: Pay_Bill_Resp (Biller Name, Due Date Amount, Currency, Bill Status ) note over Payer, PayerFI: LEG 2: BILL PAYMENT CONFIRMATION Payer-->>PayerFI: Confirms Bill Payment PayerFI->>PayerFI: Performs Account Validations
Identifies the Biller Account note over PayerFI: Logs Txn_Success_Ref ID OR Txn_Fail_Ref ID alt If Validations OK PayerFI->>PayerFI: Debits Payer's Account PayerFI->>Payer: Sends Payment Receipt (Txn_Success_Ref ID) PayerFI->>Payer: Account/Wallet Debited - Bill Paid (Txn_Success_Ref ID) Note right of PayerFI: Initiates: "(PBB) BILL PAYMENT STATUS STAGE"
Calls PAYER BB API -> paymentStatusUpdate else If Validations KO PayerFI->>PayerFI: No Debit PayerFI->>Payer: Sends Txn Failure Message (Txn_Fail_Ref ID) note right of PayerFI: Bill Paid Status (Txn_Fail_Ref ID) ``` end" fullWidth="false" %} ### 9.3.5 P2G bill payment via request to pay flow {% @mermaid/diagram content="sequenceDiagram title P2G Bill Payment via RTP participant PayerFI as Payer FI participant PaymentsBB as PaymentsBB participant ALS as ALS participant BillAggregator as Bill Aggregator GovtEntity BillAggregator->>PaymentsBB: 1. billerRtpReq (txnID, rtpId, billId, requestType, aliasID (C)) PaymentsBB-->>BillAggregator: billerRtpReq (Ack) alt RTP Type = 00 PaymentsBB->>PayerFI: Jump to "SEND RTP TO PAYER FI" Step else RTP Type = 01 PaymentsBB->>+ALS: Bill ID is routed to lookup service. ALS->>PaymentsBB: Returns back with Payer FI details. PaymentsBB->>PayerFI: Jump to "SEND RTP TO PAYER FI" Step end Note over PaymentsBB, PayerFI: SEND RTP TO PAYER FI PaymentsBB->>PayerFI: 2. payerRtpReq (txnId, billId, \[Bill Details]) PayerFI-->>PaymentsBB: payerRtpResp (Ack) Note over PayerFI: Initiate "RTP Notification Sequence - Customer<->FSP" PayerFI->>PaymentsBB: 3. payerRtpResp (txnId, referenceId) PaymentsBB-->>PayerFI: payerRtpResp (Ack) ``` PaymentsBB->>BillAggregator: 4.billerRtpResp (txnId, paymentStatus, referenceId) BillAggregator-->>PaymentsBB: billerRtpResp (Ack) opt If BillAggregator requires status update BillAggregator->>PaymentsBB: rtpStatusUpdate (txnId, rtpID)_Req PaymentsBB-->>BillAggregator: rtpStatusUpdate (Status Code)_Resp end Note over PayerFI, BillAggregator: BILL PAYMENT STATUS STAGE Note over PayerFI: Initiate "LEG2:PayBill Sequence - Customer FSP" PayerFI->>PaymentsBB: paymentStatusUpdate(Payment Status, Txn ID, RespCode)_Req PaymentsBB-->>PayerFI: paymentStatusUpdate(Ack) Note over PaymentsBB, BillAggregator: Mark Bill == "PAID" Req Sequence loop Mark Bill Payment Advice via SAF PaymentsBB->>BillAggregator: markBillPaid(Bill ID, ReceiptNum, PaymentStatus)_Req BillAggregator-->>PaymentsBB: markBillPaid (ack) end BillAggregator->>PaymentsBB: markBillPaid(MarkStatus, RespCode(C))_Resp PaymentsBB->>PayerFI: paymentStatusUpdate(Payment Status, Txn ID, RespCode)_Resp PayerFI-->>PaymentsBB: paymentStatusUpdate(Ack)" fullWidth="false" %} ``` ### 9.3.6 P2G bill payment with voucher {% @mermaid/diagram content="sequenceDiagram title Payment By Voucher ``` participant Payer FI as PR participant PaymentsBB as PBB participant Voucher Engine as V participant Biller as Biller note over PR: Bill Inquiry is Done - For Bill Payment "Voucher" is chosen as option note over Payer FI, Biller: BILL PAYMENT STATUS STAGE PR ->> PBB: voucherRedemptionforBillPayment
(BillInquiryCorrelationID,
Bill Details,
Voucher Secret Code) note over PBB: PBB receives API Call with Voucher as well as Bill Details. PBB ->> V: VOUCHER REDEMPTION note over PBB,V: PAYBB checks that Voucher is valid,
Voucher Amount and Bill Amount are same PBB ->> V: VoucherInquiry(Secret Code) V -->> PBB: VoucherInquiry_Response note over PBB: Check Voucher Value, Bill Value, Check Compatibility.
If Okay, Redeem. Else, Cancel PBB ->> V: redemptionWithoutAuthentication_Request V -->> PBB: redemptionWithoutAuthentication_Response PBB --x V: destroy V PBB -->> PR: voucherRedemptionforBillPayment(Status)_Resp note over PBB, Biller: Mark Bill == "PAID" Req Sequence loop Mark Bill Payment Advice via SAF PaymentsBB ->> Biller: markBillPaid(Bill ID,
ReceiptNum,
PaymentStatus)_Req note right of PaymentsBB: Payments BB keeps sending
Bill Payment Advice to Biller
until Response received from Biller end Biller -->> PaymentsBB: markBillPaid(ack) Biller -->> PaymentsBB: markBillPaid(MarkStatus, RespCode(C))_Resp PaymentsBB ->> PR: paymentStatusUpdate(Payment Status, Txn ID, RespCode)_Resp Payer FI -->> PaymentsBB: paymentStatusUpdate(ack)" fullWidth="false" %} ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://specs.govstack.global/payments/9-internal-workflows/9.3-p2g-bill-payments.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.