[codegeek]

Even though you should use stripe (we all love it), you should not directly code for stripe only. Here is how:

- Create an abstract "Ecommerce" module in your app and let it configure different payment gateways. In your case, start with stripe as the only payment gate way to choose from. But doing it this way now lets your app easily plug into other payment APIs in future as needed.

- For the user model, instead of having "Stripe customer id" as a field, I suggest having a user meta table with key/value pairs. So in the usermeta table, you can have {'stripe_customer_id': 'xyz'} for a particular user. This way, you can use other payment gateways and not really limiting to Stripe.

- manage the subscriptions/cancellations/refunds in your app instead of stripe. This way, your app has all records of transactions.

[user3487]

Thank you for the answer!

Mr. @davismwfl gave me some really good directions on my problem in his answers, do you agree on that way? Is there a reason you suggest managing the subscriptions directly in the app instead of in Stripe? And does it count as "my app" if I manage it in a separate service, as @davismwfl solution?

[davismwfl]

Codegeek is right on with this, the description I gave is in line with the same thing he is stating. Our data store is mongo so we use documents for the subscription details but if I was in an rdbms it would likely be a key/value pair as described.

The detail about storing all your subscription details locally is valid. We do it but also put the details in Stripe as that is what enables the recurring billing. That is also what I was pointing out in the web hooks as we store all the Stripe history from the web hooks. Works great.