So, this blog is going to be about my experience integrating with the new Stripe terminal from the folks over at Stripe.com. I have a cloud-based point of sale system. An important factor in point-of-sale system is integrated card payments into the system. Standalone terminals are a pain. I have a few integrations with other providers. The biggest factor with any integration is always security. You don’t want to be the target of thieves. The best security for a small point of sale developer is to have all sensitive card data stay completely outside your application. There are a handful of companies that provide a complete out-of-PCI-DSS-scope integrated payment solutions.
Stripe has long had an out-of-scope solution for online payments. The basic workflow is that you embed a widget on your page for taking the card details. The card details are sent in an ajax request to Stripe’s servers (card numbers never hit your application). Stripes server authorizes the card and sends a token representing the card back to the client, which relays the token to your web server. Your web server then communicates with the Stripe API, sending over the token and the charge amount. Stripe processes the payment, takes their fee, and puts the amount in your account. The token is worthless if it’s stolen from your server, because it doesn’t have the card data, but rather just tells Stripe where the card data is stored on their servers. Plus, the tokens are generally only valid once. (You can turn a token into a card object, which can be charged multiple times, for subscriptions. But even that is just another token, not actual sensitive card data.)
Anyhow, Stripe has for many years been loved by developers for online payment processing. However, they’ve never really had a solution for in-store payment processing. That’s been largely the domain of Square, for the “Silicon Valley Disrupter Style” payments. (Easy sign up, simple pricing, small amounts of paperwork, no gotchas.) However, Square has been more of an A-Z solution, rather than just payments. Square has their own point-of-sale system, and is not particularly developer friendly. So, I’ve had some clients that wanted to use Square (which has become a little more developer friendly over the years), but since Square attempts to complete with the core point-of-sale product, it puts you as a POS developer in an odd position. (Same thing with another provider of an interesting product, Poynt. They are more developer-friendly than Square was, but they have a core POS product, and they are trying to get developers to make products that are accessories to their core POS product.)
On March 8, I got an e-mail from the fine service Owler.com, which is useful for stalking various companies and their announcements. I’d been tracking Stripe, among others. I get an e-mail saying that Stripe bought a company Index.com for an unknown amount. Index.com was not on my radar, so I popped over to their website. Right there there is an advertisement claiming 1-second EMV. As many of my fellow US-residents have noticed as we’ve transitioned over to chip cards, they can be painfully slow. (They’re more secure and better, so we should use them and be happy about them! But the slowness is annoying.) Most people no know how to use chip cards now, but waiting for them to process has been a pain point. 1-second EMV is a pretty significant speed-up. At the point of reading Index.com’s website, they didn’t seem to have a product that a general developer could access, or even a general retail store. However, I knew that Stripe was a big, scaled company. So, they were probably finally ready to make their play in physical retail with their purchase of Index.com.