Comment by ralusek
9 hours ago
PaymentMethods = a specific credit card, debit card, etc. Payment Method is basically a term of art so ubiquitous that it's user-facing in UIs and has nothing to do with Stripe.
PaymentIntents is definitely a Stripe abstraction, however, but that's one that I like. It's been a while since I used it, but I remember liking that it allowed me to bundle up everything related to the payment, i.e. the amount, the payment method, etc, and pass it around between server, client, and different views in the client, such that you could really build the exact payment flow you want without touching PCI data.
The Stripe abstractions I have always felt are much clunkier are the distinctions between Products/Prices/Subscriptions/SubscriptionSchedules, etc. A lot of "what lives where?" with those; very clunky to work with.
I'm pretty sure that all Stripe abstractions and layers they do have a merit. No doubt and I'm being serious here.
However:
PaymentIntent, InvoiceCreationIntent, InvoiceCreationSession, InvoiceCharge. InvoiceChargeIntent, InvoiceChargeSession, InvoiceChargeSessionIntent, InvoiceChargeSessionIntentSession, InvoiceChargeSucceed, InvoicePaid, InvoiceFinalized, and so on.
All of those can absolutely be explained in a way that justifies their existence.
But in the end systems end up incurring so much mental tax that no one wants to really have to do anything with it.
Stripe began as a company to outsource complexity to and then grew to become a source of complexity itself.
https://www.joelonsoftware.com/2001/04/21/dont-let-architect...