Stripe Checkout
stripe.com
stripe.com
http://web.archive.org/web/20130113004155/https://stripe.com...
It does make Stripe integration much quicker, which usually takes quite awhile especially when many users only need basic functionality when starting out.
However it's still intended for people that know how to do at least a little development, so I wouldn't call it a competitor to Shopify and so on.
As it is, every guide I see assumes the use of one of their few officially supported languages.
It doesn't have to be that way. For a web API, the strings sent back and forth in HTTP requests and responses can be generated by any server-side language.
Edit: Here is an example, the first guide linked from that page: https://stripe.com/docs/payments/accept-a-payment?integratio...
As you'll notice there's a toggle for language in Step 1 "Set up Stripe". The options are: Ruby Python PHP Java Node Go .NET. Note that CURL is not an option. The entire guide presupposes you're using one of 6 languages Stripe has blessed.
This has been the case for every guide on every similar Stripe product announcement I've seen shared here over the past year and a half.
And Elixir doesn't handle that well? Or it's hard to translate examples written in other languages to Elixir? (I don't use Elixir so I'm not grasping the problem.)
> Or it's hard to translate examples written in other languages to Elixir?
Well, the first line, "gem install stripe" is a bit tough to translate into a language that doesn't have an official Stripe library :)
The issue is that the official library does things behind the scenes that the guides don't mention (such as setting up headers, tokens for webhooks, etc).
Granted, your second link doesn't include curl examples.
Here's the link again if you'd like to check for yourself: https://stripe.com/docs/payments/accept-a-payment?integratio...
You've got to be kidding, right?
This is surprising, I've always found their docs to be world class. Their API reference site is especially nice. What have you found lacking other than the Elixir library?
Hey, I'm an engineer on the Docs Product team at Stripe. Thanks for the feedback about Elixir; if you have other ideas about how we can improve the docs, I'd love to hear them! Feel free to email me at nkohari@stripe.com.
That example you cited is about installing dependencies for the languages. You don't need to install an additional dependency to run a curl command. I've looked over the documentation you've cited in other posts and the only times it seems to omit curl requests is when you aren't required to make a request for the checkout flow.
While asking for specific documentation and language support for elixir is a reasonable request, it seems a bit unfair to claim their documentation doesn't provide enough information to roll your own interface.
Here's an example of something you'll need to know for subscriptions or anything else involving webhooks: https://stripe.com/docs/webhooks/signatures#verify-manually
How many clicks is it going to take you from the subscriptions page of the docs to get there? You know it exists, which is already a big leg up, but I suspect it will take a while.
To be clear, my site is integrated with Stripe. A lot of Elixir users in my audience have had a rough go of it, though.
And yes, only the six most popular webdev languages. Monsters.
http://web.archive.org/web/20130113004155/https://stripe.com...
As a shopify store operator, I'm super frustrated at a few things that we can't edit. This looks like it's not editable, but BETTER from a conversion standpoint, which could be a significant impact to profits.
From the perspective of a dev starting a new app, it's a great trend.
From the perspective of a dev maintaining a Stripe integration first built in 2014, the breaking changes and migrations haven't always been fun. Stripe circa 2016 "just worked". Today, we regularly run into stripe issues (ie. irregularities in webhook data structure) as a result of new edge cases introduced when Stripe has added new functionality + features.
Then again, I think we're at a point in technology where we basically need to assume that nearly 100% of an application's code will need a significant refactor (or complete rewrite) at least every few years in order to remain maintainable.
We're not actively having problems. It was a few months ago. Refreshing myself on the technical details of the payload inconsistency and its cause would take a couple hours. But I believe it was related to us using a 3rd party service (that integrates with Stripe) sending out emails to customers whose charges failed, with a form to collect updated credit card info. The form for updating cc info used payment intents (may be using the wrong term) which is delivered differently than the (old) payment sources type.
The edge case being now there exists 2 groups of customers, 1 group who have a payment method attached under the new payment method / payment intent architecture, and a 2nd group with payment methods attached using the original / old method.
Webhooks often include the payment method, and the data structure for the payment method differs depending on how the payment method was attached to the customer.
How so? To me it looks like Stripe is just providing a checkout experience, while Shopify is a complete ecommerce system for online and retail stores.