In this Dev Column, Ritesh Tendulkar, Chief Technology Officer, explains the revolutionary approach with which he built the Modulr platform.
When you’re looking to build your business around a payments function, you look for relevant functionality, quick integration and easy management thereafter. But payment infrastructure technology is notoriously complicated to adapt to your business needs.
We went about solving this problem with a modularised approach, making our services simple, flexible and quick to customise to the changing needs of the customer.
Why payments technology is no longer fit for purpose
We’ve come a long way from the old world. The past was categorised by payment service and software providers which would initially build a feature-rich and interoperable technology stack and go to market with the latest innovation.
And, to keep up with customer demand and the market, the service provider would keep adding more and more functionality to the original core feature stack. As a customer, I can even switch off the features I don’t want while I can still retain access to yet more functionality. So far so good, right?
Not quite. Instead what’s happening behind the scenes is ‘software bloating’ – each new feature adds a layer of complexity into the huge embedded environment of the tech stack.
And that complexity behind the scenes means the old payments service providers would soon spend the majority of their time maintaining a hugely complicated technology stack, to the detriment of customer experience and software flexibility.
Sure, as a customer, I can still turn the features I don’t need off, but this would have a knock-on effect to other layers in the software, as it tries to figure out new flows when parts of the original stack are turned off.
Why we pioneered a modularised tech stack in payments
And then along came modularisation and Modulr (see what we did there?). A modular approach to our tech stack means breaking down the software into separate yet independently operable modules, connected together by APIs.
In 2016, we built the Modulr platform with easy integration and control in mind to get customers up and running with the payments functionality they need to serve their customers.
It effectively means you, as a customer, can choose which features you need without worrying about the overall integrity of the software behind the scenes. Moreover, there are nearly an infinite number of combinations of modules which are under the customer’s full control.
How we use modularisation to deliver new opportunities
A good example is payment splitting. This is when a business – say, a lender – receives a payment in, splits it and sends out two payments to end beneficiaries. In the old world, you were reliant on predefined fixed percentages and effectively ‘locked’ into the code. Tough luck.
In the real world, a good example might be something as simple as collecting payments from tenants. Rent collections are historically unwieldly, with bank transfers to the property manager’s own account and a manual reconciliation to send the funds on to the landlords.
Modular technology not only enables the property manager to open unlimited accounts for automatic reconciliation, it also allows them to customise the amount collected and sent on each month, cutting down admin time chasing additional payments.
Example of modular payments in the wild
For example, a tenant pays £500 in rent a month, £450 goes to the landlord in one outbound payment via Faster Payments, and another to the agency’s holding account for the 10% fee; the split is a predefined 90/10.
| £500 | -> to landlord (90%) | -> £450 |
| -> to property manager (10%) | -> £50 |
(Read the documentation: https://modulr.readme.io/docs/rules-1 & https://modulr.readme.io/reference#createruleusingpost)
But, let’s say the property manager provides additional services in addition to collecting the rent. To make it easy for the tenant and their accountant, the property manager can combine the two payments into the same fund flow where previously there would have been two payments in need of reconciliation. In such cases, the property manager can take more control of the splits by using our notification API instead.
Let’s say the tenant must pay an additional bill of £159.
| £659 | -> to landlord (now 68.28%) | -> £450 |
| -> to property manager (now 7.59%) | -> £50 | |
| -> to gas company (now 24.12%) | -> £159 |
(Read the documentation: https://modulr.readme.io/docs/notifications-1 & https://modulr.readme.io/reference#addcustomernotificationusingpost)
Modularised technology is the fastest and simplest way to capture new market opportunities
This is one such example of how we've engineered our payments engine to future proof the core function of many businesses; it gives our customers greater control over how they make payments, all from within the code. It also means they can adapt their payment processing to suit new use cases and opportunities and take advantage of the resulting operational and customer benefits.
As we move into an Instant Economy - where consumers and businesses expect to instantly consume services - it is more important now than ever that the technology that underpins your offering is responsive, seamless and most importantly, modifiable.
With Modulr, you can access payment services and products on a platform that fits around your business proposition and scales as you grow, all from a single API.
By organising our tech stack with independent product and service modules we can give you the flexibility required to identify, pursue and modify payments to suit particular opportunities, such as the example above.
Those businesses that will not only survive in the age of the Instant Economy but thrive will be those who are constantly adapting their technology to their business models and ultimately the high expectations of their customers.