
Ask HN: Is there any place to read about Payment system pitfalls? - tuyguntn
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&#x27;t have guys with prior experience with building scalable payment system, other than integrating Stripe or similar things)
======
bruhbruhbruh
These pitfalls sound specific to payment systems, but really they're just
software engineering pitfalls viewed through a payment lens.

Be 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.

