Discover our latest AI-powered innovations around faster payments, smarter workflows, and real-time visibility.Learn more →
Building a Payments Hub
This journal digs into what payment hubs are, how they function, what teams building them should know, and how scaling businesses can benefit.
As companies process more payments, the tools and infrastructure required to manage money movement become more complex. As a result, teams often initiate transactions and manage incoming payments across disparate systems and processes—at a detriment to speed, efficiency, and security. Especially for enterprise businesses, the need for a shared aggregation point, or payments hub, that centralizes transactions is significant.
Read on to learn what characterizes payment hubs, where companies should focus when building one, and how businesses stand to benefit.
Understanding Payment Hubs
A payment (or payments) hub provides a single way for every team at a company to make outbound payments or process unoriginated inbound payments. Payment hubs remove the need for these teams to individually manage the steps that surround each transaction (i.e., payment operations) or handle the engineering work.
A payments hub serves as:
- An easy way for internal teams to get started making payments
- A source for a company’s general ledger
- An aggregation point that talks to every payments-related system, whether internal or external
- A means of enforcement for appropriate financial controls across all payments
For a payments hub to provide maximum business benefit, it should handle every incoming and outgoing payment with complete visibility. A hub could still serve an organization without 100% coverage but value drops off sharply.
From an engineering perspective, at its core, a payments hub must serve as an internal abstraction layer that can handle all downstream functionality. Abstraction layers are actually a fairly common architectural pattern across industries, designated by terms like messaging abstraction layer or enterprise messaging layer.
Payment Hubs in Practice: Rent Well Properties
As an example, consider a property management company called Rent Well Properties. Suppose Rent Well is a rent tech business, allowing residential tenants to pay rent via their app. Rent Well’s original payments data flow is detailed in the diagram below.
Rent Well's core product offering
When Rent Well decided to expand into commercial real estate rentals, the team built a new parallel web application and database to power their product.
The commercial real estate team needed to route transactions through Rent Well’s bank, but didn’t want to build out their own separate SFTP connection. To save time, they decided to use the existing Internal Payments API. Unfortunately this API was built to only store information in databases used by the residential real estate team.
For support and operations teams to oversee and troubleshoot payments processes, they would need information from one of three places:
- The rent tech data warehouse
- The new commercial product’s database
- Directly from the bank portal
Rent Well's core product and new offering
Finally, suppose Rent Well acquired a fractional investing product focused on real estate. This product required a different bank, and Rent Well inherited a fund flow managed via an ERP. The fractional investing platform had its own dedicated support and operations team with no visibility into other payments at Rent Well.
Rent Well's core product, new offering, and acquired product
Rent Well’s success and growth is a boon for the business but creates new challenges—siloed data and operational inefficiencies—without a dedicated payments hub. And as the company continues to scale, the complexity and drag on business will only grow.
Building a Payments Hub: Top Considerations
For companies like Rent Well looking to establish or improve a payments hub, questions like the following should guide the process:
- What payments functionality will this centralized service need to support?
- Which controls will the finance team need to enforce across all payments?
- Which types of internal tooling will finance, support, and operations need access to?
- Which reports do they need to see that encompass every payment (i.e. status, returns)?
From an engineering perspective, a payments hub should provide a single integration point for every bank and payment rail.
It should abstract away complexity from other internal teams so they don’t have to think about who the underlying provider is, which bank to route over, or, even in some cases, which rail to use. These decisions can be made centrally and therefore won’t require any code changes on behalf of teams calling into the payments hub.
It’s also important to note the potential challenges of scaling without a quality payments hub. Companies like Rent Well must consider issues like how to get good data for an audit from the hub, how to keep track of every payment (from start to finish), and how to troubleshoot and solve problems.
When something goes wrong, which system will teams use to track it down? If the balance is off, where do they look? Does the support team have to log into different portals to answer a question? Without the right payments hub, scalably adding new banks or new rails, migrating banks, or shifting payments traffic can be difficult.
Further, is the company in a scenario where real-time API speed matters? For example, if the hub powers the core of a customers’ UX, modern payments hub architecture matters more. For back-office, AP/AR processes, the needs are different. In terms of a comprehensive payments hub, it’s important to note the following:
The more complete a payment hub becomes—the more breadth it has internally—the more valuable it becomes a single source of truth.
For companies looking to build out a holistic solution, choosing API-driven software and tooling from Modern Treasury offers major benefits—it allows companies to add additional banks and rails without any additional integration effort. Adding a payment operations layer to a hub can provide the flexibility and breadth companies need to scale.
Two Solutions for Rent Well Properties
Returning to the example of Rent Well, Modern Treasury could service two potential solutions to help the company centralize payments and prepare for further scale.
For the first solution, Modern Treasury would serve as a complete hub, with all three Rent Well apps connecting directly into our API.
How Modern Treasury could serve as Rent Well's payments hub
In Rent Well’s original setup, the web server from the commercial product was feeding into the internal payments API for the rent tech product but not receiving any updates back out. With Modern Treasury, all three applications would receive data via API and webhooks or sync directly with databases via push-to-warehouse.
Even if the Fractional Real Estate Investing division leaves existing legacy infrastructure in place, Modern Treasury would still be able to reconcile and route all data feeds back to a single stream regardless of whether the payment was initiated through our system or not. Optionally, Rent Well could set up a connector between the ERP and API—a net new service.
Either way, all support and ops teams could use the same web app, simplifying their work and enabling unified reporting. This will reduce operational expenses as well as improve UX by providing fixes and answers to customers faster.
For the second solution, Modern Treasury would support and augment a hub Rent Well built. In this scenario, imagine that Rent Well is also using a third-party sender for global coverage and has wanted an integration with a third bank for a long time (they could achieve the latter more easily with Modern Treasury).
How Modern Treasury could augment Rent Well's payments hub
Much of the payment hub functionality would be similar, although in this case Rent Well might choose to build all data into a single database and pull it out for product-specific uses. Rent Well would use internally-built support tools that take advantage of the normalized data Modern Treasury provides.
With the Modern Treasury web app, Rent Well would still be able to access finance data, get cash balances, and perform cash management—this functionality is universal even if Modern Treasury doesn’t manage payment initiation for a given bank.
Primary Benefits of API-Driven Payment Hubs
For many enterprises, payments will involve multiple (and distinct) internal producers and consumers, with corresponding many-to-many demands on underlying banks and payment processors. When these payments are all routed through a central point, companies can build all necessary tooling, visibility, compliance, and checks into that single hub.
The benefits of a unified payments hub, run through an API-first solution like Modern Treasury, include:
Flexibility
The ability to initiate payments across banks and rails from a single endpoint can be hugely advantageous. From future-proofing payment systems and gaining the ability to choose the best (or most economical) rail for every scenario, to enhancing customer convenience with multiple payment options, flexibility matters.
Modern Treasury normalizes data across financial institutions. Even if companies build their own internal UIs that are vertical-specific and deal with unique systems of record, Modern Treasury customers can access a data stream that's unified and standardized across dozens of different banks, which is much simpler than starting from scratch. This allows companies to focus on building what’s core to the business.
Control, Insight, and Security
When teams are working across systems to send, receive, and manage payments, proper oversight grows more challenging. As a result, the likelihood of unauthorized transactions and errors increases. Modern Treasury offers robust role-based permissions and approval rules to ensure only designated individuals are able to interact with payments.
A payments hub also serves as a comprehensive source of truth, empowering leaders to make important decisions and manage liquidity. When payments data is siloed in different systems across teams, everything from audits to regular reporting and monthly close become more challenging. If a payments hub can’t power a company’s front-end, then a parallel, or “shadow,” system is required. And unfortunately, having multiple sources of truth is a contradiction in terms.
Centralizing transactions and payments data also serves security. Compliance and fraud prevention requires monitoring and recording all payments—a payments hub centralizes this process which ensures protocol is universally and consistently applied.
Saved Opportunity Cost
As companies scale, the need for a payments hub grows more pressing. Managing payments across systems and processes without proper oversights and data access can quickly become unwieldy, not to mention risky. Inefficient payment operations, especially those that require manual work, are costly in terms of human resources and tech—and if something goes wrong, the time and expense required to research, fix, or (worst case) pay out fines often doesn’t make sense.
Further, businesses that expand their products and payments are also likely to explore additional rails and banking partnerships. Building integrations in-house can be an intensive and, ultimately, expensive proposition. On the other hand, Modern Treasury customers can expand coverage with access to pre-built bank integrations and rails.
Powering Payments with Modern Treasury
Many companies build portions of a payments hub in-house. However, the more individual pieces businesses create (for example, building things in parallel like an in-house integration to a bank), the harder it is to ensure universal visibility.
Modern Treasury can serve your company at any stage—our solution can act as a fully-functioning payments hub or expand your existing hub’s access to new banks, rails, reconciliation, or data streams. As the operating system for money movement, Modern Treasury was built to help businesses scale (and centralize) payments seamlessly. Reach out any time to learn more.
Try Modern Treasury
See how smooth payment operations can be.