91–100 of 230 posts
Something tells me the main problem with payment processing is integrating with card companies like visa and mastercard, and not whether you use webhooks or not (if I understand correctly how online payments work).
Yep! I would love for somebody to actually solve that problem.
Earlier quoted context omitted.
You can't standardize the developer experience across different processors. I'm not trying to be negative here, just practical. You are going to run into things like TSYS closing out batches every three days regardless of what happens. The handling features for them and their customers thing is going to be a herculean task over even a couple different platforms. Not impossible, but it's big and you would do well to s…
> Oh, also, you are gateway, not a processor. Technically right now we are a value-added payment acceptance reseller. Eventually we'd like to become a payfac. And maybe with the new regulations that came out in Georgia, a chartered merchant acquiring bank. But that's down the road. You're totally right about standardizing the devex across processors. We want to go as "close to the metal" as we realistically could as…
All of the value in payments is on the top (acquiring payfac side)...all of the value on the issuing side is only made via extremely high volume and requires a ton of tech that just schleps data (no fun). I'd recommend getting this idea out of your head.
Earlier quoted context omitted.
Pretty much my 1st question when I see a new billing product. Thank you for answering that. I don't understand why products like these hide that fact or keep it hidden. A great product that requires connecting a payment processor can still be a great product but it is not an actual payment processor and that part needs to be clear immediately on your landing page.
It's probably because "we built our castle inside Stripe's kingdom" doesn't sound very cool. However, if enough people start using this then they might become the new gatekeepers because they could swap Stripe for any other payment processor without the need of the user knowing.
Stripe would likely change their ToS and then revoke their API keys before they could get anywhere near that level of dominance.
Earlier quoted context omitted.
Pretty much my 1st question when I see a new billing product. Thank you for answering that. I don't understand why products like these hide that fact or keep it hidden. A great product that requires connecting a payment processor can still be a great product but it is not an actual payment processor and that part needs to be clear immediately on your landing page.
It’s not very well hidden, it took me around 15s to figure it out from the main page. They are also trying to diversify (obviously).
Earlier quoted context omitted.
I’ve been in software long enough to know that there’s a market for products that make things slightly easier for devs and their managers who think even common APIs like stripe are too hard. The number of devs who are struggling with web hooks and simultaneously have some budget to spend is probably bigger than you think. Often these products are pitched and sold to non-technical managers, too. The sales team will le…
I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe. I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.
> 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.
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.
Earlier quoted context omitted.
DX = developers not shooting themselves in the foot and making it impossible to cancel my free trial because my account got deleted but the autopay didn't fewers bugs = happier customers not getting charged for shit they didn't agree to be charged for
Basically this. The existing integration paradigm for payments, at its worst, feels like a warehouse filled with footguns on the floor with the lights turned off. Esp for newer developers who are used to more modern devexes which explicitly try to take reasoning about complex state transitions off of your plate.
It was great fun debugging the twice annual incidents where the API returned a HTTP500 but charged the customer and created the recurring subscription anyway.
Not to forget we had to scream at them for 6 months to implement 3DS2 on top of their Subscriptions API. Turns out we were the only users of it!
Earlier quoted context omitted.
I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe. I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.
I had the pleasure of working with teams that couldn’t even figure out how to use analytics in their product. They had zero idea who was using it and how many people were using it. They ignored the thousands of DB deadlock messages in the logs; well, they just ignored the logs completely, actually. All they cared about was shipping the next feature and getting the one QA guy to agree it was working correctly so the t…