Ask HN: Should we start switching payment providers dynamically
Right now Polar.sh and many other MOR services are becoming popular but I was thinking in some cases you would probably want to use a MOR for customers who are in a region where you have already crossed the threshold for sales tax but in others it might be better for you to use stripe directly since the price would be lower for your customer since you have not crossed the threshold for sales tax. would it be a good idea to switch payment providers dynamically based on what's best for the situation?
1 comments
Builder of an open source payments provider [0]. You could dynamically switch payments providers based on the situation, but as of today:
- you would have to integrate into multiple providers' APIs and then maintain mappings of their event lifecycles to your app db's ground truth
- internal revenue reporting would also get annoying, as your revenue charts would be split across multiple processors. You could see them in one dashboard via your accounting software (usually clunky and user hostile ime) or you'd need to start tracking payments in your DB so you could include it in your metrics
What's frustrating is that right now when you use a payment provider, you get everything in a bundle: their flow of funds and their developer experience. Solving this is one of the big problems on our roadmap. Because yeah, you're absolutely right. You should be able to route payments flows dynamically based on what's best for the situation.
[0] https://flowglad.com
What's frustrating is that right now when you use a payment provider, you get everything in a bundle: their flow of funds and their developer experience. Solving this is one of the big problems on our roadmap. Because yeah, you're absolutely right. You should be able to route payments flows dynamically based on what's best for the situation.
[0] https://flowglad.com