If you have decided to create an online payment system for your ecommerce business, I highly recommend that you read this article.
What are the most important aspects to consider when building a Payment Processing System?
- PCI Security Standard for Credit Card Processing. This standard, which is the Payment Card Industry Data Security Standard, has 12 rules to ensure some level of security for Credit Card information. However, it can also be used for Personal Identifiable Information. You may need to undergo PCI DSS audit and certification in order to process credit cards. This could lead you to incur large costs or other personal liabilities.
- Security and encryption. This is closely linked to PCI DSS which enforces multiple processes in your software development process. You don’t need to process credit cards to be concerned about security. However, security should be a top priority for your team members and you, as it is difficult to gain trust and easy to lose it.
- Geography. This is a very important topic. It will determine the payment methods you accept, which languages and cultures are supported, where your servers should reside, and how fast they should work.
- Scalability and Traffic. Software requirements and payment’s processing differ depending on how large your system is. You can outsource 100% of your payment processing to Stripe if you only do a few transactions per day. However, if you need to process millions or billions of dollars per year, your system architecture will change, and the number of partners will vary.
- MCC codes or the industry you are in. Your business’ industry can have a dramatic impact on your architecture, system design, and legal implications. You will notice a significant difference in the risks and benefits of payment processing for Poker, Gambling, or Adult (18+) transactions.
- Backup payment processors. You may need to use a different architecture or security restrictions if you have to manage retries and backup payment service providers.
- Customer support and operations. When you think about payment architecture, don’t forget your Fraud and Business analysts as they will need to consume the system and reconfigure it “during flight”.
- Business acquisitions and mergers. You can save time and money if your business has parent-child relationships and other companies have built a payment platform that can be used again and again. You may also need to be the CTO of an umbrella business to create a payment processing system that can be used as a gateway to other companies within the group.
- Cloud vs On-Premises. This is more of a “To be or to not be” situation. Before claiming that the cloud is unsecure or reliable, I recommend checking this page. Reliability is largely dependent on the Engineering that runs the system.
- Analytics. Analytics are essential if you want to make your business more profitable and to improve over time. The length of the waiting period before you get your answers (minutes vs. days) is another important aspect. This may differ between Data Streaming and OLAP approaches.
- Fraud (External and Internal). Fraud can also be internal. Therefore, when developing payment processing systems, you need to consider internal and external breaches, data trade, or other similar issues. You can use existing rule-base systems to extend them and add machine learning and manual ad-hoc review.
- Mobile. Mobile may have additional architectural and deployment implications, regardless of whether you support Native Mobile Application. You may have a native App but cannot control when it will be updated. This means that you might need to support many versions and APIs. Knowing this beforehand may help you avoid problems. Don’t forget to mention that you can’t use your Payment system in the Appstore to purchase In-App products (and you may not wish this). However, if you are selling goods or services that aren’t consumed within an App, you might be willing to go for Off-App Payment Processing. This adds complexity.
While there are many other aspects to consider when designing payment processing systems, I believe that I have covered the most important.
Let me continue the evolution of Payment Processing Architecture (one possible branch and I would love to hear more versions in comments).
The Architectural Evolution of Payment Processing Systems.
It is wise to begin with the simplest pragmatic solution, but always have future scalability and growth in mind (develop isolated in-proc services which can be further be decoupled/extracted).
Do not do it at all or outsource as much of it as possible.
- Do not do it or outsource as much. If it meets both business and technical requirements, I would consider this solution. Why? Why? Because the Payments domain can be complex and regulated. This can make it very time-consuming and sometimes not rewarding. It is possible to simply redirect a customer to your payment partner and make a transaction. After the transaction is completed or cancelled, your customer will return to your side with a branded payment method selection page. To prevent duplicates from being allowed and to properly receive notifications, you will need to manage redirection. You can use Stripe, Adyen or Global Collect as examples. However, Payment Processing companies usually charge additional fees for branded pages on top of any processing fees. If you are just starting your business, 100% Payment Processing outsourcing might be a good choice.
- You can do everything yourself, but you need to outsource credit cards. As you grow, you might need/want/desire greater control over payment processing. However, you don’t want to or can’t afford to deal with PCI DSS certification (even for Level 3-4 merchants). You may decide to make your payment method selection page, store all Payment Accounts/PII and outsource Credit Card processing. You will likely start with a monolith system and store your payment accounts in your local data base, which is part your main database. You will have high coupling but easy deployment and development. Even if you have a monolith system, I recommend that you think about decoupling and testability. It is much easier to do this once you get started.
- SOA, and use batching. This is a natural progression from the previous steps where you can see that some parts of your system need to be secured/scaled separately. You might want to be more careful about security of your Payment Accounts and user information. To do this, extract the Payment Account and User account services and encrypt them. Or, put a HAProxy to those services and deploy them in a separate backend farm behind DMZ. You can also use background processing in batches to offload some front-end processing. However, you may face other problems such as asynchronous payments processing and its complexity. However, you might be able to start with Asynchronous payment processing. This does not mean that your checkout process will be asynchronous but offers huge benefits. This is what Amazon and PokerStars do, to allow them time to address scalability issues and other issues.
- Use queues for a more reliable system that is resistant to load and change. This step allows you to create software design that allows communication between all components, or almost all of them, via queues (where async permits). You might have queues for both internal and external Fraud scoring (aka MaxMind, ThreadMetrics), storage, notifications from other systems, and a queue to receive every payment processor.
- Microservices, and other parts. Although this is very popular, it also has many disadvantages, particularly for Payments. It can be very cost-efficient and beneficial if done right. However, you must consider all aspects of the system. For example, deployment, monitoring, service discovery and reliability. Security, administration, and automation are all important aspects. (I don’t mean that all systems should ignore these aspects. But if it was internal communication within those architectures, it could be out of protocol communication and network issues. Mircoservices are not the focus of this article, however they can be useful and make sense for large merchants or payment service providers. Contrary to popular belief, Mircoservices can be managed by software developers even for small businesses.
- Multi Availability Zone deployments. Multi AZ installations can improve reliability and latency when processing payments around the Globe. This is a separate point to emphasize the complexity. However, it will most likely be used from the monolith architecture to improve up-time and deployment (Red Green Blue). Multiple AZ can cause many problems, including replication, split-brain, synchronization, data collection and analysis, traffic routing, monitoring and security.
Although microservices are perfect for Payments, they add complexity.
Mobile clients are an aspect of your system that needs to be considered. However, mobile clients can’t be controlled by you. You may also need multiple versions of your Payments API.
Summary: Online-Payment Processing System is a software system with higher security and reliability requirements. Every call can have a direct financial impact on your bottom line.
Balancing Processing Partners offer multiple payment options for different types of businesses. We will analyze your company and make recommendations to help you choose the best payment option for your budget and business. You can learn more about us online or you can call us at (800) 354-6256 or via email [email protected]. Let’s find the right payment system for you.