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