It seems like payment/e-commerce companies in general are shifting towards offering "express checkout" experiences nowadays - Shopify, Paypal, Amazon Pay, are a couple prominent examples. My former employer Affirm was also very concerned about owning the checkout experience/acquiring users up-funnel. It's a smart move, really.
We always hear about how payment networks manage to nickel and dime merchants to produce lots of revenue, so it was probably only a matter of time before other players in the process wanted a piece of that action.
Stripe checkout has existed for awhile, which might not be obvious seeing it on the frontpage of HN.
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.
I really wish Stripe would either support Elixir or drastically improve the quality of their docs.
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.
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.
Not sure exactly what you're asking for based on the comment. Just an official Elixir library? The docs have raw curl requests in addition to the languages, which just show the HTTP method, url, and raw params–those can be thrown into any HTTP request library that Elixir might have.
> 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.
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.
The documentation does provide enough information to roll your own, but it's buried. Notably, the newer "guides" seem to assume everyone is using one of their official libraries.
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.
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.
Your first link does include curl examples for everything except for the instructions for downloading the client libraries and for the frontend examples. This has already been pointed out to you in another comment, so I'm not sure why you're persisting with your claim.
Granted, your second link doesn't include curl examples.
> It's a web API and the strings sent back and forth in HTTP requests and responses can be generated by any serverside language.
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.)
Elixir's great at that stuff. I wrote a wrapper library for the specific functionality I needed, basically just building up from Plug.Conn.Query.encode/1.
> 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).
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?
As much as i loved integrating Stripe before i have to say it is pretty expensive for micro-transactions in Europe (less than 5€). They charge a base fee of 0.25€ +1.4% so this pretty much kills the business margin. We went with a local payments company in Spain (paycomet) because they could offer a flat 17€ fee a month.
(I work at Stripe.) We're working on microtransactions in Europe! We can support most use cases in Spain today, and we can look into hooking it up for you if you email me at edwin@stripe.com.
Stripe Checkout has been around since 2014, but along with the new page, there are a bunch of new updates today (coupons, tax rates, and more payment methods). More in the blogpost: https://stripe.com/blog/checkout.
The blog post[1] (which seems like a better link than the landing page) says, "Today, we’re adding support for coupons, tax rates, and two new payment methods".
Seems like a direct response to shopify. I like the competition. Interesting how the design language is so similar, too. Seems there's been a solid convergence in the payment space around simplified payment flows. As a developer and a user I'm very happy with this trend.
> As a developer and a user I'm very happy with this trend.
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.
Hi, Kenneth here from Stripe. I'd love to chat with you about the problems you have with webhooks. How can I best reach you? My email is auchenberg@stripe.com
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.
Shopify is a big customer of theirs....this is interesting.
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.
https://news.ycombinator.com/item?id=19739630