You have a big problem with your payment system.
At least that’s why we suppose you read this article.
Maybe your business just started, but the payment system you integrated already struggles to meet customer expectations. Or you run an established platform, but your legacy system has grown into an inflexible and costly monolith of different providers.
If you work with a particular provider like PayPal or have integrated a variety of individual acquirers or PSPs, you cannot excess full control over your payment. For example, feature updates, security or transaction limits and fees lie outside your agency.
However, perhaps your transaction system runs just fine, it is functional and flexible. But have you utilized its full potential yet? Have you thought about adding e-money wallet functionalities to enable P2P transactions, loyalty point systems or quick refunds?
Whatever of the above is the case, this article is for you. It will discuss how you can turn your legacy system into a version that better suits your needs. By finding a proper payment solution provider and adding payment orchestration and e-wallet functionalities, you will be able to take back control.
This Article Gives an Overview of:
- Reasons why you want to switch your payment system in the first place
- What to mind in the initial stages of payment system creation, e.g. regarding system architecture
- How you properly migrate your system, incl. development and testing
- How you take your improved system live
- What to mind when maintaining and expanding this system
- Where you find a payment solution provider to support you execute all of the above
First off, let’s give Simon Sinek some credit: Let’s start with why.
Why Change Your Payment System?
Payment is a competitive factor.
When competitors offer payment solutions that are faster, more user-friendly or more scalable, your business will notice. But even if your system is generally functional and largely bug-free, it probably has its limits. Many legacy systems are quite cumbersome. Once you want to step up your feature set and expand to new markets, they cannot be adjusted flexibly.
And sometimes, that’s hard to prevent. In many companies, payment systems sprawl organically alongside the platform or products. It starts with one PSP, single-handedly integrated. More PSPs and acquirers follow, by demand of the customers. More markets follow, more regulations and higher transaction numbers come along.
Finally, you end up with a payment system based on a single PSP or a patchy host of providers with non-uniform integrations. Adding features to such systems requires serious effort and inhibits your business to prosper.
There are ways out of these dead-ends. You could change your payment system into a unified, API-based solution, like a custom-built payment gateway or an e-wallet solution (we discuss the differences between those two here). If you want your business’ payment system to benefit from the improvements below, it is a path worth taking.
Reasons to Reform Your Payments from External to In-House Payment Solutions
1. Access to Data Control and Analytics
Many businesses rely on one specific, external PSP to process their payments. But doing so means that they are missing out on a valuable business opportunity: data analytics.
The evaluation of transaction and customer data provides viable insights into consumer behaviour, payment bottlenecks and specific dynamics of the market. With an in-house payment solution, you can analyze those data sets accordingly.
2. Improved Data Security and Compliance
Don’t force your customers to store their full personal data on your platform and the payment provider as well, either. If you run a unified payment solution layer, your customers just have to grant you data access. You then manage and store the data, only handing over what’s needed by PSPs and acquirers for the payment process.
As a result, it’s easier to safeguard the data and stay compliant with data protection regulations. Mind though, that some countries prohibit customer data to be stored in foreign countries. Say you generally operate inside the EU. But now, you want to tap the Russian market. Russian regulations demand that you store the data of Russian customers on servers in Russia. Plan accordingly.
3. Better Transaction Scalability
Every business delights in an increasing number of transactions on its platform. But working with a single PSP often requires businesses to step up the contract once traffic increases. If multiple PSPs are involved, for example for different regions and markets, transaction management becomes challenging.
A payment system based on a single API is not dependant on permissions or capabilities from outside to handle high transaction numbers. As you have full control over how your software is built, you can factor in the increasing traffic from the get-go.
4. Higher Transaction Success
Consolidating different PSPs and acquirers on a single, unified layer enables you to improve routing processes as well. For instance, you can set up a smart routing system, which can detour a payment to a different provider should the initial attempt fail with a recoverable error cause.
What’s more, you can offer your customers or merchants to automatically pass the payment on to the provider with the best conditions.
5. Coherent User Experience
External payment processing is exactly, what it says: External. The payment occurs outside your platform. And that can form a significant obstacle when trying to create a coherent user experience.
Customers are well aware when they encounter a sub-par payment UX: In a Salesforce research, 80% of them stated that the user experience is as important as the products or services offered.
Uniting the whole payment process under one roof has advantages here. For example, you can provide additional features related to payments that don’t lie within an external PSP’s capabilities. For example, you can easily introduce subscription services or deferred payments.
6. Easy Feature Integration
An in-house payment system underlies your full control. It allows you to quickly react to popular demands from customers, while not being dependant on support from external parties (mostly).
Thus, you can integrate new features exactly like you envision them. You could decide to build your new payment solution to include e-wallet functionalities. That would allow you to accelerate refunds, for instance, with money being retransferred to customer wallets instantly after the request, saving you transaction costs at the same time. This also would incentivize customers to spend the refund money on your platform.
7. Quicker Adaption to New Markets
Taking root in a new international market is not possible without the proper payment portfolio. A decentralized payment system will pull the brakes on global expansion here: You would have to integrate every PSP and acquirer on its own. Who would want to deal with 25 separate shop plugins just to take their business to a new continent?
Placing your system on a unified foundation enables you to quickly access those new markets, as payment method and currency integration follow the same routines every time, no matter the country.
…Or What Have You?
Those were just the most obvious advantages of an in-house payment system with a unified API. Given specific circumstances or use cases, additional benefits will emerge. If you run a marketplace, for instance, you can present your merchants with a better experience.
For example, you could offer central, automatic billing. Or you could easily implement limits and fees to comply with specific jurisdictions.
Maybe you even want to settle for a full e-money license (read more about e-money here). This would multiply your options tremendously: Why not set up a peer-to-peer payment solution to allow customers to trade their loyalty points among each other? Or refund them as fiat money on their emoney wallet?
Taking everything into account, the key reason to run a centralized orchestrated payment system yourself can be summarized as such: You are not dependent on external providers. This helps you to avoid vendor lock-in and puts you in a better position to negotiate conditions with PSPs or acquirers.
The Stages of Switching Your Payment System
Admittedly, the term “Switching” is a bit misleading.
Putting your payment system on a new, unified basis is not done by just turning a switch. Once you have identified the general problems in your legacy system, your team passes several stages in software development. During any of those stages, you might need to bring in support from a payment software solution provider specializing in payment orchestration and e-wallets.
This will be especially viable when your team lacks experience in these fields or essential side disciplines such as Secure Coding. External payment solution providers, solution architects or software engineering specialists present a good addition to your in-house staff. Workshops can also help get your team ready for the stages ahead.
Preparation and Architectural Design
Before you write a single line of code, you should take stock: What does your current solution look like and what dependencies exist? The answer should take the following factors into consideration (among others):
- Countries your system is active in
- Regulation and legislation in those countries
- Data security standards in those countries
- Payment methods you have integrated
Based on these factors, you can reflect on which country you want to base your payment system in. That boils down to a decision between two ways to “serve” your services to consumers:
Cloud
Your payment system runs in the Cloud and customer data is stored there and called up from there, too. This option is, to a degree, more flexible and easier scalable.
On-Premise
Your payment system runs and stores customer data on physical servers you rent or own. Naturally, those servers are situated in a specific location and thus fall in a specific national jurisdiction.
This is important for some markets: Specific nations, e.g. Russia, require that personal data of their citizens is stored within their national borders. So even if you settle for the Cloud option, you need to have a few servers ready to operate in such countries.
(In fact, that you can adopt such a two-pronged approach. This is an additional advantage of consolidated payment API solutions.)
The 2 Types of Payment Solutions
The next key question is, what you want to settle for in terms of functionality:
- Do you want to keep it simple with a basic Payment Gateway?
- Or do you go all-in with a Full E-wallet System and an E-Money License?
We can think of good reasons for any of those options (we have written some down here).
With CoreWallet, our payment software framework, it’s also perfectly possible to settle for a straightforward payment gateway first and add e-wallet features on top of it later on. Scroll down to learn more about CoreWallet.
Additional Software Design Decisions
As the last step in this stage, you must lay down which 3rd party integrations (such as PSPs or KYC providers) and features you want to include. It’s a big catalogue of small decisions:
- Will you run a single-vendor shopping platform or a marketplace with multiple merchants?
- Does the payment have to take place instantly after checkout (as would be the case for food delivery platforms e.g.) or is it sufficient to generate an invoice? Is deferred payment an option?
- Will you deliver your products individually or is the whole order shipped only when everything is ready? Will the payment take place for each item upon delivery or are all goods paid at once? And how about subscription services?
- Will you allow peer-to-peer payments, so each customer’s wallet is configured to send and receive payments?
- And so on…
In the end, you come up with an architectural concept detailing how these components interact with each other. In the case of CoreWallet, this will proceed through RESTful APIs, but alternatives exist, such as interaction via messaging.
Developing and Launching Your Payment Solution
In many cases, the transition from one system to another might include more coding groundwork than is often estimated. Legacy systems tend to have sprawled organically.
In the end, this can lead to maintenance and further development efforts that make it too costly to operate the system much longer. This is the point where any system has to migrate. But the organic, decentralized structure of the system can prevent an easy transition to new software.
The good news: The development of your fresh payment system doesn’t have to start from scratch. A software framework with modules meeting your system’s requirements will shorten the development and cut costs. And involving the team of an experienced payment solution provider might bring extra power to the workforce.
Also, you don’t need to migrate your whole system at once. A relatively failsafe migration procedure is the so-called canary testing. Instead of going live with the whole system, only parts of the customer base get the new version. The larger share of traffic still runs on the old system.
Thus you can test operations on a manageable scale – preferably via the live system, logging and business monitoring, which identifies which transactions fail and why.
Should the system prove to be stable, it can be rolled out gradually until the old system is completely replaced. (If you want a practical example of this approach, check out our case study of a migration for a major food delivery service).
Continuous integration procedures also help to prevent bad surprises. There, code changes are automatically built, tested and only deployed if approved.
Maintenance and Expansion
Live system logging and monitoring also play into the continuous after-launch bug-fixing. Generally, running your own orchestrated payment system has advantages for maintenance as well. If you are reliant on outside payment providers, you can only hope that they will offer crucial features or security updates within an appropriate timeframe.
And if they make changes you don’t like, you’ll have to roll with it, quickly find an alternative or close business altogether. For your system, you can simply code what is necessary yourself.
The same applies when you want to expand your business. E-wallet-based systems are perfect for a multi-national business strategy, as new regional payment providers can be adopted without much technical effort.
What’s more, as you have full control, you can include new business processes as you see fit. Say, for example, you want to update your online marketplace with a delivery service for perishable goods, you need to adjust your payment processes to feature instant payments.
The Payment Solution Provider: Re-Framing Your Payment System with CoreWallet
Finally, it’s time to get practical.
You have decided that you want to change your payment system by putting it on a new foundation? You want your system to be capable of payment orchestration, enriched with a few e-wallet functionalities as well, perhaps?
In this case, you need a payment software provider with experience and domain knowledge to support you – and a framework to base your new system on.
We created CoreWallet, our payment and e-wallet framework, to present a flexible and feature-rich solution for businesses of all industries. CoreWallet comes with a RESTful stateless API, that can act as a single unified layer for transactions of all kin. Its modules contain all the crucial functions needed to implement payment systems of all shapes and colors like:
- Multi-tenancy platforms with configurable e-wallets for marketplaces and customers (B2C, B2B and P2P)
- Multi-currency support and easy PSP integration for international businesses
- Context-based payment routing for least-cost and least-risk transactions and reduced payment defaults
- Extension points for KYC and AML software to ensure local compliance and reduce risk of fraud
- And much more…
trimplement, Your Payment Solution Software Partner
When you go with our payment solution CoreWallet, we come along as a software partner.
Our experienced team will support you in every stage of your project. We will plan the architecture with you, analyze your code, help you with development and onboard your team to run and expand the application post-launch.
Just drop us a line to info@trimplement.com
Conclusion
Switching your payment system is more than just turning a switch. But if you are running a legacy system that grew organically, it might be necessary at some point.
With the switch comes a chance: The chance to end vendor lock-in and take full control over your payments. You can hereafter decide what features or updates you want to integrate and when. Beyond that, custom-built payment gateways or e-wallet systems have additional advantages. For instance, they allow you to quickly expand to new markets.
But you don’t have to create anything from scratch either. To get a new system off the starting blocks, you can rely on flexible software frameworks and external payment solution providers.
Solving your payment problem should not be complicated.
