We’re excited to present the second episode of the three-part column by our Lead Product Architect. In the previous part, Ivan explained the nuts and bolts of offline sales and ways to enter the e-commerce market. In the current episode, you’ll learn how Mr. Baker gained a foothold in e-commerce and what challenges he faced expanding his croissant business to a new market.
Hi, I'm Ivan. I've been working at Corefy for almost five years. Today I will share the insights I got from my experience and the best scenarios for payment management. Also, I’ll answer the most common question about our company – how our products simplify online payment processing and help businesses boost their profit.
What to do if a payment provider crashes?
One cold November morning, Mr. Baker notices that lots of payments were not processed. There are lots of abandoned carts and unprocessed transactions. What has happened?
The thing is, payment providers may experience downtimes for various reasons. This is what happened to LiqPay, a payment system created by PrivatBank that Mr. Baker uses. Black Friday's discounts and online shopping spree have led to the enormous traffic of transactions that overloaded PrivatBank and resulted in a system crash. Due to this, the requests to replenish Mr. Baker’s merchant account were received, but LiqPay didn't answer. Accordingly, having a POS terminal from PrivatBank and the account in LiqPay, Mr. Baker won’t be able to sell croissants at the moment of downtime and might lose lots of clients. What shall he do?
How payment routing helps avoid losses
Mr. Baker can sign a contract with one more provider, let’s call it Provider 2, and get a +1 merchant account. The developer will connect this new payment method to the website and configure its usage rules.
In case of any issues on LiqPay’s side, the developer can re-route all transactions to Provider 2 by writing a few lines of code. Provider 2 can also be used along with LiqPay under certain conditions.
They can split the whole transaction flow equally – 50% to LiqPay and another half to Provider 2. Alternatively, they can divide all payments according to certain parameters the following way: one goes to LiqPay, and one goes to Provider 2. This scheme is more fault-tolerant than the previous one. It is also more profitable in some way because LiqPay, for example, sets a commission of 2.75% for each payment, and Provider 2 charges only 2.5%. So, it is cheaper for Mr. Baker to use Provider 2 than LiqPay.
You might wonder, why wouldn't he completely switch to Provider 2? It’s all about conversion. LiqPay’s conversion rate can reach 70%, while Provider 2’s – 60%.
Conversion is the percentage of successfully finalised payments compared to all.
Why can one provider have a higher conversion rate than another? For instance, they might have set up their payment routing in a specific way and know some tricks to achieve higher conversion. And Provider 2 may be unable to offer this due to the lack of competence or under-the-hood integrations.
I do not advertise any providers, I invented all the figures and facts for illustrative purposes.
So, there is one website and two accounts to accept payments. How each transaction gets there depends on Mr. Baker and his developer. The scheme is complex, so the developer must tinker a bit. It is more fail-safe and profitable, yet not perfect.
Entering the new markets
If Mr. Baker decides to enter a new market in Eastern Europe and start selling croissants, say, in Poland, he’ll need to sign a contract with a Polish provider. It is essential to offer convenient payment methods depending on the geography of your audience. So, Mr. Baker integrates a payment provider in Poland for his local customers to pay conveniently. Let’s call it PolProvider. I think it wouldn’t be a problem for the developer to integrate this provider, even though the documentation may be in Polish.
Coping with multiple payment providers
Mr. Baker starts selling croissants in 2 countries, utilising three merchant accounts. To monitor all payments data, check with his accounting, submit some kind of reports, or make a refund in case someone didn’t like his croissants, Mr. Baker needs to enter each of the accounts via separate dashboards. He needs to understand via which of the providers the payment was accepted, enter this account, find the necessary transaction, and click on the refund arrow. The same with reports: he needs to go to each provider and then consolidate these reports somewhere in one place.
Let’s suppose he stores all the orders in Excel. He will compare all payments with the list of orders in Excel. Of course, the developer will help him with it. He will develop some automatic tools for reconciliation and getting these reports in Excel. But it’s not a trivial task. There is one more challenge: the message about a transaction of 20 UAH via LiqPay looks like “20 UAH”, but with Provider 2, it may look like "2000 980". Why? Because Provider 2 transfers the sum of 20 UAH in kopiykas (like cents in Europe) – 2000, and 980 is the numeric code of the currency according to the ISO standard.
This example shows that every payment provider has its integration peculiarities, and the developer should take them into account. Apart from the case with numeric currency codes, there is another issue – currency conversion. As Mr. Baker sells the croissants across two countries, he’ll deal with a minimum of two currencies. The Polish provider will need to convert 20 UAH into zlotys or vice versa while accepting payments and settling them into Mr. Baker’s account. It requires developers to configure the conversion schemes and rates from the national bank or another source. Such a sophisticated payment setup becomes a tough task for one developer. So, Mr. Baker faces the need to expand his staff and hires more developers, plus a team to deal with reconciliations, support, and tracking transaction statuses.
On the one hand, sales are growing; on the other, costs are also increasing. A lot of effort is spent on establishing all these integrations, monitoring for nothing to break down in case one of the providers changes some field, adds a new one, or changes its format. It requires a large competence and a lot of human resources.
Thus, the complex scheme works, but it becomes pretty expensive for Mr. Baker to support it. Moreover, he could create new recipes for croissants or add new products to his assortment, but he can’t because his focus is constantly shifting to payments.
Still, seeing his sales boost and being a far-sighted businessman, Mr. Baker wants to expand to other markets. Let's say he wants to enter other European countries. What shall he do? Is it sound to keep opening new merchant accounts and manage them on his own? Stay tuned, we’ll discover the following steps in the next part.