Before you go live, make sure you've done these things. Stripe gives you a checklist which seems very basic. It lacks actual coverage of security checks and ensuring that things actually work on the side of your app. It focuses more on checking the Stripe dashboard. As you know, it's great to look at your money and ensure everything is going smoothly, but the reason most of us developers automate everything is so we can free up time to work on other projects.
Stripe has about 1,000 employees working for them. They've had the time and expertise to perfect their payment system. What they haven't done is ensure your web app is actually using Stripe correctly. They did all the work, you just have to make sure you utilize all of the data they give you to ensure you are secure. As for these security checks, you can use a cronjob to check Stripe minutely, weekly, or monthly. Or you can use the method that Stripe prefers which is checking for information via a webhook that Stripe sends you. It is up to you completely, but here is a checklist of things you need to ensure your web app is fully secure with Stripe.
The biggest issue is always going to be with credit cards and payments. By implementing these additional security checks, you can be sure you'll probably save more money in the long run. An incident happened where a former customer of mine, who was a hacker, got into my system, and bypassed the security check because I wasn't checking for certain things. That hacker then proceeded to cost me about $200 by exploiting a bug in the system that didn't help him at all, but it harmed me more. So after allowing this hacker to wreck havoc on my web app for the entire week, I was able to patch most of my security issues.
If you are releasing your web app into the wild, just know it is going to get discovered by some great people... but also some of the worst people who sign up and try to exploit apps purposely so they can get something for free — or they just are there to make you miserable and drain your bank account.
It is highly recommended that you store Stripe data in a database which will make it easier to retrieve everything, otherwise you will be making a lot of calls to determine who is who and what belongs to who. Stripe's customer ID, subscription ID, and cardID are probably going to be the most important to save. If you use invoicing at all, you will likely want to save the id as well.
- Require email verification in order to ensure a legitimate account was created
- Add / Update Credit Card
- Require an authorization, but do not capture it
- By doing this, you will be able to charge the card immediately, usually $1.00, and this forces Stripe to ask the credit card company if this credit card or debit card has enough funds.
- It seems to also help Stripe process it as if it were charging the credit card for real — revealing a lot of information about this credit card including whether its stolen, being used by multiple people, or has been involved in any fraudulent activity
- Check & Require: CVC, Zip Code, and (Fraudulent) Reason (should return as NULL to pass)
- * Do not check for zip code if your customer lives outside of the United States — it will fail every time and prevent people from signing up
- Using a cron job or Stripe's webhooks, you should check for an active credit card and an active subscription. If the subscription is inactive, than Stripe has attempted to charge this customer several times and has disabled the subscription, so checking for anything other than "active" should result in disabling of the account.
- If you offer the option for your customers to remove their credit card, you need to ensure that ANY OUTSTANDING INVOICES ARE PAID before the card can be removed.
- When using the InvoiceItem API to add to the invoice, make sure you record the invoice ID so you can later check. It would be best to add these to a database so you can compare them against including their status of paid or outstanding.
- You will specifically want to check: closed, due_date, forgiven, amount_due, amount_paid, and paid.
- In your database, every invoice try should count up or down and once it reaches a certain number i.e. 0 or 4 (greater than 3 tries), as well as email the person that payment is due — this might seem annoying since I believe Stripe sends an email about it as well — but annoying your customer for payment is better than not getting paid. If it exceeds the countup or countdown
- If the number is hit, than the permissions to use product is removed from the database rendering the person unable to use your product any longer
By implementing these additional security checks into your app, you'll have better peace of mind. Imagine you have 10 customers and there are 1 or 2 who are exploiting your system. Now imagine you have built a massive enterprise out of your web app and you have 100 customers and 2 are exploiting your system. In which case do you think you will have an easier time catching the bugs and the perpetrators? I'm very grateful I had a hacker exploit my system early, as I was able to catch these mistakes fairly quick. It may have been a $200 loss, but being optimistic about it: I paid a hacker to exploit my system, find the vulnerabilities so I could patch them up and prevent future exploits.
Anyways, you could probably search for all of what I am talking about and while many security articles will pop up — none really dive into the nitty gritty of actually accepting credit cards and all of the interesting characters who might come across and exploit your system. This list is not extensive and there are many additional things you can do to check to ensure your customers have a legitimate payment method. Once you build in all of this once, it will become natural to you.