No code payments automation is a lie
No-code payments automation is a novel concept to eliminate code from accepting payments and managing payments lifecycle. It means you do not have to write any code to start powering payments on your website or app. And again no-code to manage anything/ everything in the payments lifecycle like initiating refunds, adding new payment processors, new payment methods. All clicks and no-code at all !!
This is an attempt to help you decide whether it is relevant to you as a developer/ business and what to consider while investing in payments automation.
(A) Are you developer integrating with multiple payment processors?
(B) Are you business processing beyond USD 10 million per annum?
If you’ve answered ‘yes’ and you are considering investing in no-code payments automation, beware!! If someone is trying to sell you a no-code payments automation stack to get rid of developers, the tech team, and the payments operations team - it is a big lie !!
Email us if you have still managed 100% no-code automation upon a multi-processor payments stack. We want to buy you a beer and learn how you did it !!
No-code payments automation is a possibility and a great value proposition for small startups and growing businesses running on Shopify or Woocommerce.
However, it may not apply to scaled-up businesses with more profound and complex payment use cases. Hence, you would need developers in your team, solution designing, quality code to be written, and quality assurance to be ensured. Let us see why.
Not all payment processors out there support full automation of end-to-end payment lifecycle.
There are numerous payment processors
- that do not support webhooks automation !!
- that asks you to manage chargebacks/disputes via emails !!
- that do not support payment status check APIs !!
And surprisingly, this is the case with some payment processors in the most developed markets. And, if you wish to directly integrate with the banks to reduce your payment processing costs, you will most likely encounter “sorry, we do not have automation for that use-case” surprises.
Unless all the payment processors you signed up with provide the necessary automation, code must be written, and a human brain is required for payment operations.
Let us take a scenario - you run a D2C brand selling shoes. You might have to accept any returns from customers hence and process refunds. And there could be a need to deduct a return/cancellation fee in special cases.
Now, a typical sales pitch of a no-code automation solution for this use case would be
-
Click a button on my dashboard to process the refund - But to do this, you either need a team of customer service executives doing this mundane work which would end up increasing your payment operations cost.
-
Upload a list of refunds on my dashboard to bulk process refunds - But customers may not be happy to wait another few hours for the refund to be processed. Customers prefer instant refunds.
The point is you will end up writing code to automate the complex business rules to calculate the refund amount and trigger refund APIs.
The no-code payments stack by itself could become a single point of failure. If you are a scaled-up business, you need to have a fallback in place.
For example, if the checkout page of the no-code payments tool cannot be triggered (for some weird reason), you will have to write code to trigger the checkout page of the alternate payment processor (which will be your first fallback). So code needs to be written!
Any no-code payments provider will also be a SaaS business, with its own set of priorities.
How much of your requirements will be prioritized in their roadmap?
Say, you wish to add a particular local payment processor in Latin America which is not very popular, nor in the roadmap of the no-code payment provider. Will the provider be flexible enough to get his done for you?
When you are dependent on someone else’s code which you have no control upon, you have to write code.
While the perfect no-code payment automation in a practical sense will be a utopian dream for scaled-up businesses, low-code could be a realistic possibility.
Payments will be some code to low-code for fast-growing and scaled-up businesses. Hence the need for developers who code will exist in the foreseeable future.
Writing code is not the most challenging, but evaluating a payment technology and solution design is complex.
If you make a hasty decision driven by a no-code sales pitch, you might end up with a brittle and inflexible payment stack that requires constant firefighting on the part of the future members of the team to keep it functional. Do not fall prey to the lie that writing code is the hardest part.
Payments are a critical aspect of any business. So when you make a choice for payments automation technology (you may build it in-house or evaluate a third-party solution), here are some general criteria you should look out for
-
Optimize for the least overhead: Any payment automation you build will add an overhead (latency) to payment processing. And higher the API latency, the poorer the conversion rate. Recognizing levels of memory hierarchy and programming to ensure they are used appropriately is fundamental to minimizing the overhead. Small mistakes while writing code (too many or inefficient database calls, incorrect sync versus async tradeoffs) and poor choice of deployment architecture can cost heavily regarding latency.
-
Resilience to failures: The technology infrastructure to process payments should be resilient and auto-scalable to cater to peak sales (quantified as Transactions per second or Requests per second). Few glitches or downtime during your peak sale hours could cause a big dent in your payment conversion rates.
-
Prioritize cost-efficiency: As you process larger-scale payments volume, the payment technology costs should not increase disproportionately. With more scale, you should get a better cost-to-benefit ratio. Only good engineering design can help achieve this. Betting on a low-level programming language and resource auto-scaling can make a big difference in the long run. Suppose you are planning to opt for a third-party solution. In that case, having a high-level visibility of the engineering design principles of the solution provider is critical. If you are a big brand, you may quickly get super-discounted pricing in the short term. But unless the solution provider cannot fundamentally sustain the low pricing with lower operating costs, the solution provider’s longevity is at stake. And eventually, it might put your business at risk.
Are you a developer passionate about simplifying the payments for other developers? Peek in here to contribute towards the Open Source Payments Switch to simplify payments.
Are you looking to explore how a payments switch can help you move towards low code? Sign up and checkout hyperswitch for fast and reliable payments.