Almost every service on the Internet today deals with money. And dealing with money requires a robust Billing system. Building your own billing system is a pain. It is a crucial component that should be highly available, secure, and 100% bug-free, otherwise, your users or your business might lose some money, which is unacceptable.
At Mad Devs, we prefer to use robust, suitable, and resources-saving solutions if possible. That is why we often use Stripe & Stripe Connect to enable billing for our products. That saves our clients a lot of time, money, and negative emotions.
Stripe as well as Stripe Connect is very easy to integrate: it has a lot of documentation and very simple and powerful API. Yet, for those who are new to online payments & e-commerce Stripe integration might cause issues and unexpected side effects. This article is to describe some of our lessons learned so that when you integrate Stripe Connect for your business, you are easy to avoid or overcome them.
If you link cards to your users’ accounts, or you accept card payments make sure users authorize the cards, otherwise you might have a lot of fraud resulting in disputes. Cards authorization happens in several steps, you request basic card details and make sure they are passed to Stripe so that it can verify the card. But it is very easy to break defense if a person has stolen/scanned a card. To completely avoid cases of stolen cards being used, use the 3D Secure.
You can do it either setting Stripe Radar rules and it would request users to authorize their cards OR make it a default way to auth the cards from backend when constructing payment intent or setup intent objects. This will save you a lot of efforts, time, and money. 3D secure also gives a liability shift, so that your platform bears no responsibility for fraud-related cases.
Lesson learned #2 Fully customizable onboarding is a pain
Stripe Connect comes with onboarding options, which means you might outsource users onbording & verification to Stripe and new users will have to fill out the forms to complete their profiles, or you might conduct your own onboarding & verification within the Platform. The second option allows you to make it look as you wish and avoid Stripe-related info during onboarding & verification. Yet, even if it seems really attractive, it is not an easy way. There is a lot of data to deal with, a lot of cases to consider, and a lot of formatting.
Otherwise handled by Stripe, you can feel the pain integrating all of that to your platform. So, make sure you have a strong important reason not to use Stripe express onboarding flow.
Lesson learned #3 Avoid charging users from backend, preferably use Stripe components
As with card attachments, payments should be implemented from a client (mobile app, website, etc.) side since only in this case it can be authorized properly. With the help of Setup/Payment Intents, you can implement all sorts of workflows and track responses right away while a user pays. There are cases when you would be willing to charge a user’s card off-session, yet, this is where (especially if a malicious card was added) a lot of problems can arise. Avoid charging users from the backend and make sure they better pay you on-session, if they can only use off-session payments if users might not be able to authorize the payment (an example here might be a simple subscription).
Lesson learned #4 Prepare your system to edge cases!
There are a lot of edge cases that can happen during your workflows. Stripe might begin their fraud prevention checkups and temporarily disable your accounts. Users might not have enough funds on their cards. Cards might not support 3D secure, and so on and so forth. To avoid it — be prepared for it. Test your integration with Stripe Testing data. You should always listen to webhooks and update the state of user’s accounts notifying users of the changes, blocks, etc. + sync your own code workflows with those of Stripe, so in case of any delays, failed transactions, temporary locks you would be able to show your users that something is happening and they should not worry about it. Read about Development Checklist to get more ideas on this lesson.
Lesson learned #5 Handle webhooks very well
One of the most important components of Stripe is communication with your server via webhooks. Stripe sends events when something happens either with your platform account or your connected accounts (Important! These are two different things!). So, make sure your platform is highly available and you enable all the webhooks that help you synchronize your server’s data to Stripe’s data and visa versa. Never use polling with Stripe since this would require a lot of resources and requests to Stripe which are not needed, always rely on webhooks and make sure you can reprocess them if something starts failing on your server.
Lesson learned #6 Decide on payment methods right away
Stripe offers a variety of payment methods, which seem so clear at first, yet sometimes the choice might have a negative impact on our system or might not exactly fit into a workflow of yours.
For example, which destination charges and transfers might sound like a good idea, keep in mind what you transfer to your connected account. If you also transfer the fee data and then take it after all, in case of a full refund you might get a negative balance on the connected account. If you want to reject it after all you will have to manually transfer money to that account to bring its balance to 0. Pay attention to those details, since they might get you confused or even cost you some money after all.
Conclusion
All the above-mentioned lessons are just a small part of what there is to know and to learn when dealing with online money and the integration of payment processors. Still knowing them can save a lot of time, financial and emotional resources and prevent things from going wrong. If you have something to add to the list or any suggestion, proposal that can help improve this article, feel free to comment and send us your feedback at [email protected].
