Earlier quoted context omitted.
In my experience, you couldn’t just setup an account and start selling, you had to contact their sales team and they let you know if they want your business. Stripe has no real competitor.
Mollie might be a direct competitor
Stripe's Payment APIs: the first 10 years (2020)
11–20 of 56 posts
Re: Stripe's Payment APIs: the first 10 years (2020)
#12Earlier quoted context omitted.
> If you just need to take dumb payments, just use Stripe Checkout. Could not agree more. Offload as much complexity (receipts, invoices, tax, customer info, etc.) to Stripe as humanly possible in the beginning. Don't build for edge cases or UX polish. If people want your product, they will buy it.
and then without knowing it you are paying 1000's a month to stripe
Stripe takes 1.5-2.5%, so if you're sending them 1,000s a month, your revenues from that checkout are approaching the $millions p/a. Certainly enough to hire an expert in the domain.
Re: Stripe's Payment APIs: the first 10 years (2020)
#13Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple. You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should tr…
I'm working with Stripe subscriptions at the moment for a charity taking donations via their website. The subtle differences between subscriptions done through Stripe checkout and subscriptions set up yourself using Stripe elements are by turn infuriating and frustrating.
The documentation is geared towards people using checkout. Stripe's own AI help could find us a bit of information which going through the documentation didn't give us, and it even struggled to find the reference in the docs for it.
One product, two different ways to use it, and slightly diverging feature sets between the two. Argh!
Re: Stripe's Payment APIs: the first 10 years (2020)
#14Earlier quoted context omitted.
Mollie might be a direct competitor
Isnt Mollie Europe only?
[0]: https://help.mollie.com/hc/en-us/articles/115002116105-Can-I...
Re: Stripe's Payment APIs: the first 10 years (2020)
#15Earlier quoted context omitted.
> If you just need to take dumb payments, just use Stripe Checkout. Could not agree more. Offload as much complexity (receipts, invoices, tax, customer info, etc.) to Stripe as humanly possible in the beginning. Don't build for edge cases or UX polish. If people want your product, they will buy it.
and then without knowing it you are paying 1000's a month to stripe
Re: Stripe's Payment APIs: the first 10 years (2020)
#16Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple. You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should tr…
Re: Stripe's Payment APIs: the first 10 years (2020)
#17bro, just use Paddle, it's a MOR
In my experience, you couldn’t just setup an account and start selling, you had to contact their sales team and they let you know if they want your business. Stripe has no real competitor.
Re: Stripe's Payment APIs: the first 10 years (2020)
#18Re: Stripe's Payment APIs: the first 10 years (2020)
#19Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple. You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should tr…
Releasing two MAJOR SDK versions with breaking changes in a single week doesn't help either. [1] I dread every time they release a new SDK version because for me it means only more work for zero value.
I've got so incredibly tired of their constant flow of "innovation" in the API and SDK that I have finally gave up and created another SDK for Stripe from scratch: https://github.com/egorFiNE/simple-stripe-sdk (not yet released)
[1] https://github.com/stripe/stripe-node/releases/tag/v21.0.0 and https://github.com/stripe/stripe-node/releases/tag/v22.0.0
Re: Stripe's Payment APIs: the first 10 years (2020)
#20Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple. You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should tr…
Having done a major migration with Stripe, at a startup, I disagree. They have lots of products, but you don't need most of them and can ignore them. What's left is, in my experience, the correct amount of complexity. We looked at Braintree, and it was just missing things that we were legally required to support, we looked at Judopay and it was... lacking (a nearby founder describe Judopay as treating payments like a…
Initial integration is very simple and developer-friendly. The complexity comes later.