Stripe testing

(mostly a note-to-self, as I discovered yesterday that returning to my Stripe payment project wasn’t as easy as I thought it would be.)

The Stripe package provides two sets of keys - development and production. The crucial thing about the development keys is that you can use phony credit card numbers to test your payment setup. The Stripe website also has a development/production toggle, the entire dashboard flips between the two ‘worlds’ of real data and test data.

The code snippets out of which my project has grown (react-express-stripe and react-stripe-elements) both check for the existence of a production environment variable; if production, use production keys, else use development keys.


The other moving piece here is the two-part site security issue - part one from Stripe and part two from the browser’s paymentRequestAPI method.

Stripe will let you test your code in development over an HTTP connection (like, say, when you’re running your site on localhost:8000 or whatever), but you can’t roll it into production that way (no problem, Netlify offers reasonably easy SSL to host your site over HTTPS).

…but, as the Chrome docs helpfully remind us: Payment Request is only available on sites served over HTTPS. see. Thus, over HTTP you can test your Stripe setup, but you don’t get the extra benefit of the browser payment API (which is 90% of the fun, if you’re on a Mac or iPhone. You get the ‘Apple Pay’ logo and can pay with your thumb. The Google Pay bit is nice too, taps into any saved cards you might have in Chrome, but c’mon. Apple Pay.)

a screenshot of Apple Pay

I accidentally charged myself $15, taking this screenshot. Guess it’s time to test the Refunds setting

The solution to test the entire thing locally, which I originally set up, but forgot, then re-learned yesterday and am writing down this morning, is this:

  • Run the back-end code locally. In my case it’s set to start on port 8080; the front-end code knows to make calls to :8080 when not in production.

  • Start the front-end code on port 8000 (or whatever, Gatsby defaults to 8000).

  • Run ngrok in a terminal — ./ngrok http 8000 — that’ll give you a live HTTPS connection that resolves to your front-end code.

  • don’t forget this bit: Copy the new HTTPS link from grok and paste it into the array of FRONTEND_DEV_URLS in the back-end’s /constants/frontend.js file. The express.js server does a CORS check and won’t accept connections from URLs not listed in that array.

This entry was posted on July 04, 2018 with tags