Fintech Secrets: Paying Bills (I)

Welcome to the Fintech Secrets Series, where we go on a journey through one of the most transformative sectors of our time financial technology (Fintech). You can read the fintech history, when it originated, how it developed, and the reasons behind its emergence from Fintech Secrets: Fintech Era.

Paying Bills is one of the most practical and popular applications in the fintech, offering users a streamlined way to pay bills and manage expenses from a single, unified platform without the need for physical movement or extra effort. Designing a Paying Bills system in fintech requires robust integration with various government and non-government service providers, a reliable transaction processing system, and a user-friendly interface. In this article, we will explore how to design a fintech solution for Paying Bills service, focusing on managing transactions through applications, service providers, banks, and online payment gateways. We will also discuss essential components, key workflows, and design patterns that support efficient and scalable implementation.

Before diving into the implementation, we need to step back and view the service at a high level, focusing on the big picture rather than specific details. Let’s start by defining the core components of our system and considering the number of clients we’ll be dealling with.

The User Interface (UI) is the initial interaction layer, followed by the Biller Integration Module or our providers. At this point, we need to determine whether we’ll work with an intermediary between us and the provider or interact directly with the provider. Either way, it’s essential that our system remains dynamic and abstract, avoiding dependency on provider-specific details. This principle aligns with the Payment Processing System, which will be responsible for collecting funds from the client and transferring them to the provider. There are numerous important and intricate aspects to consider here, and we’ll dive into those in detail.

Additionally, the system will need a Notification Service to inform the client of the transaction status. This ties in closely with both payment and provider interactions, especially when handling failure cases. As we explore failure cases, we’ll cover broader system-related aspects in a general, abstract manner, focusing on concepts that apply across the entire system rather than to any one component.

Other key elements include Transaction Management and Ledger for accurate tracking. This feature will serve the client, provider, data team, and accounting, as well as provide valuable insights for us as developers, detecting fraud cases, highlighting service performance, and areas for improvement and expansion.

1. The User Interface (UI)

The user interface (UI) is where users browse their bills, enquire bills, see transaction details, initiate payments, and receive confirmations. The UI should provide an easy way to enquire bills, simple process to complete the payment, view bill details, and choose payment options.

In designing a user interface (UI) for Paying bills, a widely adopted approach for quick and intuitive search is to categorize services based on types or shared characteristics within each collection. Each main category, such as "Mobile/Phone, Donations, Utilities" would include subcategories representing the providers available in the market, such as "Gas, Water, Electricity" under Utilities Category, and within these, the specific services, such as "recharge or pay the bill", would be displayed.

This hierarchical layout simplifies navigation and allows users to quickly locate specific providers and services based on familiar categorizations, improving the user experience in bill payment applications.

To complete this flow from a backend perspective, it requires three primary RESTful APIs:

• Categories API: This API retrieves all active categories in the system. It may rely on the user’s location or adapt based on user-specific information, geographical region, or the user’s history with the system/transactions.

GET /api/categories
{
  "categories": [
    { "id": "uuid", "name": "Mobile" },
    { "id": "uuid", "name": "Utilities" },
  ]
}

• Providers API: This API lists all subcategories under a selected main category, based on the user’s chosen category.

GET /api/categories/{id}/providers
{
  "providers": [
    { "id": "uuid", "name": "Water" },
    { "id": "uuid", "name": "Gas" },
  ]
}

• Services API: This API displays all services available under each subcategory, using the provider/subcategory ID.

GET /api/providers/{id}/services
{
  "services": [
    { "id": "uuid", "name": "NatGas Bill" },
    { "id": "uuid", "name": "Petrotrade Bill" },
  ]
}

This structure provides a clear and modular API design for the paying bills UI, ensuring each API has a dedicated responsibility and can adapt dynamically to user and regional requirements.

Note: This is an example of popular approach in the market.

2. Biller Integration Module

The second core component in the Pay Bills service is the Biller Integration Module. This module serves as the essential connector to various billers, such as utility companies, telecommunications providers, insurance firms, and more. Its primary function is to enable smooth integration with third-party APIs or platforms, allowing the system to interface directly with external service providers.

Essentially, it acts as a mapping layer that links the services displayed to the user on your system with the actual, billable services controlled by the biller. This means that every service users see and interact with is mapped to its equivalent real-world counterpart at the provider level, ensuring accurate and secure transaction processing.

This module is the main core of the implementation and requires rigorous handling of:

API Endpoints: Direct mappings for retrieving biller services and processing payments.
Data Sync: Regular synchronization of services and rates between your system and the provider.
Error Handling: Mechanisms to manage failed transactions or inconsistencies in the service mappings.

This mapping is crucial for accurately representing available services on the user interface, maintaining consistent service details, and ensuring transactions reach the correct end-service provider.

3. Payment Processing System:

This system manages the transfer of funds between the user’s account and the biller’s account, incorporating:

• Integration with payment gateways or direct banking APIs.
• Support for multiple payment methods, including credit/debit cards and bank transfers.
• Security mechanisms like tokenization to protect sensitive payment data.
• Compliance with PCI DSS standards for data security and regulatory adherence.

A Payment Processing System can indeed be designed as a standalone microservice separate from the bill payment service, functioning as a third-party integration. Given the complexity and unique requirements of payment processing, such as secure transactions, compliance standards, and different payment methods, so we will dedicate a separate series of articles to this topic will allow a deeper dive into its architecture, security practices, and design patterns.

4. Notification Service:

Responsible for keeping users informed with real-time alerts, Sends real-time alerts and notifications to users for events like successful payments, failed transactions, or upcoming bill reminders. This component may use push notifications, SMS, or email.

5. Transaction Management and Ledger:
This component provides an audit trail for all transactions by:

• Tracking transaction status, timestamps, and reconciliation details.
• Maintaining a ledger/database for record-keeping, dispute resolution, and historical tracking.

6. Analytics and Reporting:
Helps analyze system performance and user activity by:

• Tracking key metrics such as transaction volume, success rates, and user engagement.
• Generating insights to optimize the payment flow, improve user experience, and quickly detect potential issues.

To conclude this article and avoid excessive length, we’ve covered an overview of the main components of the pay bills service and explored the first component, the UI, in detail. We’ve also dived into the Biller Integration Module. Looking ahead, we have several upcoming articles that will delve into how these components interact, from the UI to the completion of payment and notifying the user.

Subsequent articles will focus on Design Patterns for Efficient and Scalable Implementation, demonstrating practical examples to achieve a fully integrated design, covering UI, backend, database, and clean code patterns. Starting with the next article, we might set up a GitHub repository to implement this service together as an open-source project.

I’m very excited about this journey
see you all soon!