Ask HN: Is there any place to read about Payment system pitfalls?
We are adding payment system into our product. We want to know what kind of pitfalls we may encounter while building such system. Patterns used while developing payment systems. What kind of architecture are used by other systems and so on. (We don't have guys with prior experience with building scalable payment system, other than integrating Stripe or similar things)
1 comment
[ 2.9 ms ] story [ 11.6 ms ] threadBe careful around the types you're using to represent monetary amounts. Strongly typed languages will give you some defense against accidental rounding errors (don't use floats).
Are you adding a payment system to a product or are you creating a payment service that your product will use? Coupling your product / business logic with your payment/billing code may work for now... but in a year you may need to add another consumer or extend the billing code in a way that won't be possible if it's too tightly coupled with the business logic. Will you need to support multiple payment options per user? Subscriptions?
Also, if you're planning on using a single CC processor, Stripe is a pretty good choice. Just be careful about the coupling I mentioned earlier, you don't want to be too tightly coupled to any external services (like Stripe or another processor).
Another thing to keep in mind -- what does downtime look like? Will your payments fail, will you lose customers? Or is it designed to handle and recover from downtime.