> Not to mention choreographing the lifecycle of our business domain with the Stripe checkout flow and webhook event types, of which there are 250+

You don’t need to listen for all event types if you aren’t using _every_ Stripe feature.

▲

agreeahmed 4 hours ago | parent | next [-]

But you do have to figure out which ones are salient to you and how they map to your specific app's lifecycle.

As a very small example: would you need to handle `charge.succeeded` and `payment_intent.succeeded`? How would you dedupe processing these events vs `customer.subscription.created`? Today, there's a lot of incidental knowledge about your payment processor's specific approach to webhook events that you need to know in order to integrate them.

▲

OsrsNeedsf2P 7 hours ago | parent | prev | next [-]

Sure, but everything from the Stripe UI down to their API is feature creeped. I remember using it 10 years ago and I got it working in 10-20 minutes. Last month I see it up for my new project and it took almost a whole day

▲

Scubabear68 6 hours ago | parent | next [-]

You setup a payment flow and it took you less than a day, and you are upset? I don't understand.

▲

tyre 7 hours ago | parent | prev [-]

Were you using it in the same way?

	▲	agreeahmed 7 hours ago \| parent [-]
		I'd bet the typical payments integration has more complex requirements now than those from 10 years ago. That's what usually happens as a space becomes more important and, therefore, more regulated. Usually new entrants will come in and try to provide a tidier interface for solving an increasingly complex problem. In payments, as others in the comments have pointed out, that process is hampered by the gatekeepers involved. You'd have to commit to building an amazing developer experience and navigating bank partnerships and compliance (per country), risk, antifraud, etc. That's why the payments devex feels so behind the DB, hosting, or auth devex today.

▲

huflungdung 7 hours ago | parent | prev [-]

[dead]