Stripe Testing and Tricks

To wrap things up on my eight-part series on processing payments with Stripe, I’ll mention a few random things under the guise of testing and tricks. Most of the information will only make sense if you already understand how processing payments with Stripe works (i.e., if you’ve read the entire series).

Test Credit Card Numbers

To test your payment process, you can use any syntactically valid credit card number. You can search online to find some, or use those listed in Stripe’s documentation. But a syntactically valid credit card number will always work, making it impossible to test what happens when a charge fails. Naturally Stripe thought of this already, and provides specific credit card numbers you can use to trigger different failures:

• 4000000000000101 will fail based upon an invalid CVC
• 4000000000000002 will be declined (as if there were insufficient funds)
• 4000000000000069 will be declined as an expired card
• 4000000000000119 will be declined for a generic processing error

Other credit card numbers will fail based upon address verification problems. These are also listed in the Stripe documentation. And you can trigger declines by using an invalid month value, a year in the past, or a two-digit CVC number (correct numbers are three or four digits long). Providing a non-integer amount for the charge will trigger an invalid amount failure, as the amount must be an integer (in cents).

Two quick things to know when it comes to testing:

1. These numbers will only have these effects when in test mode (i.e., when using the testing public and private keys). Using these numbers on a live site will just report that the card was declined (because it’s fake).
2. What validations you want to test will depend upon what information you’ll take. For example, if you don’t take the customer’s address information, there’s no point in testing the address or zip code verifications.

Charging via Ajax

The code I use in this series submits the form to the server-side PHP script once the Stripe token is received via an Ajax request. As use of Stripe.js requires JavaScript, one alteration you could make would be to process the payment via Ajax to a PHP script on your own server. I leave that up to you, but be certain to validate, validate, validate in your PHP and JavaScript.

Recurring Charges

The focus in this series is on processing a single, one-time payment via Stripe, but that’s not the only option. You can create “plans” in Stripe and then have customers sign up for a subscription to that plan. The customers will automatically be billed at the increment of your choosing. You can also create coupons or discounts in order to run specials on plans and you can establish a free trial period before billing begins.

If customers might be billed again by your business, but not on a set schedule, that is also possible with Stripe. For example, if you have a site that sells multiple products, you could allow the customer to make subsequent purchases without re-entering his payment information. And, your site still won’t be storing any sensitive information (well, not beyond the customer’s non-payment info). This is accomplished by creating a “customer” record in Stripe, which is associated with a payment method. By storing the customer ID in your system, you can make subsequent requests to Stripe for other payments, passing along the customer object and payment amount at the time.

All of this is explained in the Stripe documentation, of course.

Using Webhooks

Webhooks provide a way to have Stripe notify your site when an event occurs (such as a successful charge, a verification failure, a recurring billing, and so forth). When doing a simple single payment, you absolutely don’t have to use webhooks. (Unlike PayPal, by comparison, in which an IPN script is the only reliable way to know that a charge went through.) But when you have recurring billing, you must implement webhooks so that your site can be notified when a customer is charged (so that you could, for example, extend the customer’s account expiration date at your site).

If you’re of the “more information is always better” mentality like me, then you can go ahead and implement a webhook anyway, and just be notified of every single successful charge or failure so that you may log those transactions on your own site.

Staying Secure

Last, but certainly not least, a couple of thoughts on maintaining the security of your e-commerce site. Stripe, and the Stripe.js library, make it very easy to securely accept payments on your site. But that does not mean you should rest on your laurels and just watch the money flow in. There are three things I’d recommend you regularly do to stay secure, and another step you should take once.

First, keep an eye on your logs. Make sure no sensitive data is being stored there (or being sent via email). As the payment information won’t be hitting your server, you should be safe, but it’s best not to make assumptions. You’ll also want to regularly rotate your logs, just so they don’t become unwieldily.

Second, every few months or so, go into your Stripe account and change your keys. This is a good general practice for any e-commerce site, just as it’s best for everyone to change their login passwords regularly. You can change your keys in the Stripe Dashboard, under Your Account > Account Settings > API Keys. There’s a refresh icon (“Roll Key”) to click. Changing your private key is what really counts, as the public key is already, well, public. Stripe, in its brilliance, will continue to support the old key for 12 hours (if you choose). This gives you a little leeway in case an order comes through in the time between when you roll the key and when you change it on the site (or if you fail to change the key in all your code, but if you use a constant, that shouldn’t happen).

Third, while you are on the API Keys page, check the API version in use. When your site interacts with Stripe, Stripe will make note of the API version you’re using. Stripe makes regular updates to its API, but if the changes could break existing applications, they’re “gated”. This is to say that you’ll continue to use the older API until you specifically request to be updated (and you test that result). Periodically, you should check your API version against the current version. Then click the “Upgrade” button on the API keys page to complete the upgrade.

Finally, enable two-step verification in your Stripe account (Dashboard > Account Settings > General). By doing so, you can only log into your Stripe account after you’ve entered your correct email address and password and a verification code sent to your mobile phone. You’ll need a mobile phone with the Google Authenticator app installed to do this, but I would highly recommend it. That way no one can get into your Stripe account and make a huge mess of things without your email address, password, and physical access to your mobile phone.

Conclusion

So…that’s it: everything I can think of to say about processing payments with Stripe (which, frankly, is crazy easy in my opinion). I hope the series has been helpful. If you have any questions, problems, or comments, just let me know. And good luck with your e-commerce venture!