Digital commerce experiences are increasingly stepping outside the bounds of the dot.com website. To make newer touchpoints such as mobile apps, in-store digital, interactive display, rich content and IoT natively shoppable, or support one-touch, gesture or voice-enabled transactions, merchants need to extend payment processing anywhere.
The key to achieving anywhere commerce is API-driven systems that allow applications to share and process data. Many organizations are exploring microservices as a flexible way to extend, customize and scale their commerce functionality to fit the new world of shoppable touchpoints.
Microservices are small applications built around specific business functionality decoupled from other pieces of your commerce platform. Their independence and dedicated APIs allow them to integrate with diverse touchpoints and be scaled, updated and removed without impacting the database or code of your core commerce platform. They’re especially helpful when you want to satisfy unique use cases without “breaking your build.”
But is building a payments microservice the right way to satisfy unique requirements within emerging consumer touchpoints?
Third party payment solutions are already microservices-like
There’s good reason why ecommerce platforms typically don’t ship with native payment processing and require integration with third parties for merchant accounts and payment gateways. Payments is too critical a service to lock into. As the industry continually evolves with new payment types, best practices for fraud and PCI compliance, privacy and security, it’s important to have choice and flexibility to swap in and out payment processors as required. Your payments vendor is responsible for delivering innovations such as mobile wallet, cryptocorrency, mPOS and more, and if you ever outgrow your solution a switch is relatively easy.
You never want payments tied to your ecommerce platform’s upgrade cycle and risk falling behind on critical updates. Nor do you want an update to your platform such as adding a new product attribute to your catalog potentially breaking payments, or an interruption in payment processing taking down your whole site.
The good news is your third party payments service already functions like a microservice, with its own code, data and API. Deployed alongside your commerce platform, it can extend to new touchpoints without taking your core commerce code with it, and can pass back data with the right integrations. Depending on your payments vendor, there may be quite a bit you can do with the APIs they provide.
However, with payments-as-a-service, you don’t own the code, nor can you make updates independent of your vendor. If market solutions can’t provide what you need for your unique use cases, you may opt to build a layer between your processor and your commerce platform to fill the gap.
When you want more power from payments
As a majestic commerce unicorn, you may desire to (for example):
No matter how strategic these may be to your digital experience plans, you do not want to build and maintain a payments service from scratch in-house! It’s simply too risky, and there are enough third party solutions to take care of the important features.
Instead, you may choose to build custom functionality into a microservice API layer that sits between your payments application and commerce platform. This allows you to build, test and iterate on this code independent of your payment processing and merchant account with less risk. Rather than directly call the payments service, your touchpoints can communicate through the business logic of an API layer that you control.
And if it fails? Just remove it. That’s the beauty of microservices.
Payment microservice precautions
While this workaround sounds simple, there’s more to microservices than just developing custom code. Your IT environment needs to be set up to support microservices, including an API gateway and framework to support service discovery, messaging, monitoring and more. This takes time to build, and often carries a learning curve. Setting up this infrastructure can take longer than development of microservices themselves.
What’s more, your IT team likely needs to support DevOps if they don’t already, and have experience with deploying, testing and maintaining microservices. For organizations just looking to fill a feature gap within a single service, the overhead doesn’t justify the effort.
Until your organization requires a full transition to a microservices architecture, it’s best to work with your payments vendor’s API or your API-driven, headless commerce platform when extending transactional capabilities to new experiences.