5 ms·

For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stri

For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe.

agreeahmed 11mo ago
For now, yes. The game plan over time is to get deeper into the actual card rails side of things. But first we really want to nail the developer experience.
- guessmyname 11mo ago
  Who cares about developer experience? Genuinely asking, because I’m a developer too and I certainly don’t care. What we care about is solving the actual problem of payments with the downstream companies.
  - poly2it 11mo ago
    Stripe became dominant by improving developer experience, which cuts implementation costs.
  - Scubabear68 11mo ago
    “Well your payments platform doesn’t actually do payments, but the developer experience of doing nothing was flawless!” Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
    - deleted 11mo ago
      [deleted]
  - jazzyjackson 11mo ago
    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
    - agreeahmed 11mo ago
      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.
      - scott_w 11mo ago
        100% This. I remember joining a billing team that assumed calls to Braintree succeed or fail, so everything was just calling the API as though it was a local function call. 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!
- jfyi 11mo ago
  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 see what's out there before committing to a standard interface. Take a look at https://datacapsystems.com/ https://datacapsystems.com/ to see it done well. Also, adding another layer like this, you better have an early plan to staff a support desk. Oh, also, you are gateway, not a processor.
  - agreeahmed 11mo ago
    > 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 soon as we could. That's why we very deliberately built our own billing engine from scratch. We could have gotten to market faster by just mapping onto Stripe Billing, but we would have foregone valuable experience mapping processor lifecycle events to our data model. For a while that's going to be much of the work on our plate, standardizing how we map their lifecycle to ours. We took the past year basically studying the prior art and developing / testing a data model that we feel is well on its way to describing the general case. I was frankly surprised how long it took to really hammer out the primitives.
    - jfyi 11mo ago
      Technically you are a wrapper api, but you are acting as a gateway. Though, if you were to claim to be a gateway you'd need pa-dss/ssf validation and that would cost a good chunk of that yc money, so I understand.
      - agreeahmed 11mo ago
        Exactly. One of our advisors who previously an exec at one of the card networks says that currently we are technically a "value-added gateway reseller". Doesn't exactly roll off the tongue, but that's the most precise way to describe us right now. And not necessarily where we will stay.
- turnsout 11mo ago
  The DX of Stripe is already great—it sounds like you want to give Stripe reasonable defaults. Not a bad idea, but if you know what you're doing, you can have AI read the Stripe docs and implement something based on established patterns. Who is your ICP?
  - brunosutic 11mo ago
    > The DX of Stripe is already great This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together. Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU https://www.youtube.com/watch?v=YuXp7V4nanU
  - agreeahmed 11mo ago
    Today our ideal customer is someone starting a project on day one who wants an easy pathway to 1) get stood up ASAP, and 2) start iterating on pricing as they learn what customers really care about. What we found when talking with dozens of builders was that the DX is indeed much better than e.g. Adyen, Braintree, etc. But their DX is far from the counterpart best in class devtools in auth, hosting, or databases. To be clear, what Stripe has built is a towering accomplishment. But a lot of why innovation in payments DX has been slower than other parts of the stack is that since Stripe, there haven't really been many others who have attempted to tackle the *entire* job to be done.
- Denvercoder9 11mo ago
  That's fine, but it does mean that your current submission title is factually incorrect. You didn't build a payment processor, you build a payment gateway.
- whizzter 11mo ago
  You intend to restrict this to a single market? There's some sibling comments that do point out that. Much "annoyances" when it comes to money is all those weird laws and rules from lower level companies in place, improving things for developers is a laudable goal but I do hope that you guys have some real world experience with these systems apart from frustrations as system users because doing a good DX right now feels like it could make you end up in a dead end.
  - agreeahmed 11mo ago
    100% agree - this is not a space to tread into lightly. We have some really knowledgeable payments people in our corner, including several veterans with many decades of payments industry experience as leaders at the big payments players. There's a lot that we've been able to learn from them as they help us navigate the financial services side of this business. We're conscious of how much work there is to do, and how the "good DX" is really just the visible tip of the iceberg. Currently through Stripe we are able to onboard merchants wherever Stripe can serve them directly. Our upcoming merchant of record offering (which we hope to launch soon), will be available to merchants wherever Stripe can send payouts, which is a longer list of maybe 150+ countries. The pathway to building deeper payment rails will indeed have to be country-by-country as each one requires new banking partners and compliance regimes.
redbell 11mo ago
So, this is somehow similar to Polar (https://polar.sh/ https://polar.sh/)
codegeek 11mo ago
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.
- amelius 11mo ago
  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.
  - theturtletalks 11mo ago
    Their website says fully opensource and since it’s a Stripe wrapper, this seems to be an opensource alternative to Stripe Elements. It does require a Flowgrad account and key so it will provide value if other payment processors started using it. Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
    - fn-mote 11mo ago
      I thought the whole post was about the benefits, namely that Stripe has too many webhooks and doesn’t handle enough of the tax computation. Did I misunderstand something? Or is this about a different angle?
      - theturtletalks 11mo ago
        Ah that is another benefit, using Stripe Elements and Stripe directly, you have to save the subscription ID and other fields in your database. Flowgrad seems to handle this on their side.
    - agreeahmed 11mo ago
Aurornis 11mo ago
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 learn that they can make some sales by promising a non-technical manager that buying this product will actually save them money because it’s easier to use.
- whizzter 11mo ago
  Literally describes one company I work for periodically.
- skwee357 11mo ago
  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.
  - withinboredom 11mo ago
    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 ticket could be closed. This is much more common than you might think.
    - numpy-thagoras 11mo ago
      That describes more than just one POS (Point of Sale) company I know of.
    - 11mo ago
runako 11mo ago
It looks like this is more akin to a React-only Chargebee where entitlements etc. are stored with the billing provider. (Apologies if I am misreading the site.)
- agreeahmed 11mo ago
  It scans that way right now because Stripe is more visibly involved in the onboarding process. Maybe another way to parse it is "Shopify for software", where we combine the movement of money and subsequent state transitions involved in unlocking value. But instead of shipping physical items, it's granting entitlements. Either way, thank you for the feedback. We're still refining how we explain it.
  - runako 11mo ago
    > we combine the movement of money and subsequent state transitions involved in unlocking value > it's granting entitlements This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space. 1 - https://www.chargebee.com/entitlement-management/ https://www.chargebee.com/entitlement-management/
    - agreeahmed 11mo ago
      There are a few billing engines that have shipped entitlement management offerings. We’re focused on making the best DX for managing entitlements as possible. A lot of that comes down to details: cloning pricing models across environments, React hooks to manage your state. We want to build something you pick to build with on Day 1 - rather than something your boss tells you that you have to use.

For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe.

agreeahmed 11mo ago

For now, yes. The game plan over time is to get deeper into the actual card rails side of things. But first we really want to nail the developer experience.

guessmyname 11mo ago
Who cares about developer experience? Genuinely asking, because I’m a developer too and I certainly don’t care. What we care about is solving the actual problem of payments with the downstream companies.
- poly2it 11mo ago
  Stripe became dominant by improving developer experience, which cuts implementation costs.
- Scubabear68 11mo ago
  “Well your payments platform doesn’t actually do payments, but the developer experience of doing nothing was flawless!” Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
  - deleted 11mo ago
    [deleted]
- jazzyjackson 11mo ago
  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
  - agreeahmed 11mo ago
    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.
    - scott_w 11mo ago
      100% This. I remember joining a billing team that assumed calls to Braintree succeed or fail, so everything was just calling the API as though it was a local function call. 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!
jfyi 11mo ago
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 see what's out there before committing to a standard interface. Take a look at https://datacapsystems.com/ https://datacapsystems.com/ to see it done well. Also, adding another layer like this, you better have an early plan to staff a support desk. Oh, also, you are gateway, not a processor.
- agreeahmed 11mo ago
  > 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 soon as we could. That's why we very deliberately built our own billing engine from scratch. We could have gotten to market faster by just mapping onto Stripe Billing, but we would have foregone valuable experience mapping processor lifecycle events to our data model. For a while that's going to be much of the work on our plate, standardizing how we map their lifecycle to ours. We took the past year basically studying the prior art and developing / testing a data model that we feel is well on its way to describing the general case. I was frankly surprised how long it took to really hammer out the primitives.
  - jfyi 11mo ago
    Technically you are a wrapper api, but you are acting as a gateway. Though, if you were to claim to be a gateway you'd need pa-dss/ssf validation and that would cost a good chunk of that yc money, so I understand.
    - agreeahmed 11mo ago
      Exactly. One of our advisors who previously an exec at one of the card networks says that currently we are technically a "value-added gateway reseller". Doesn't exactly roll off the tongue, but that's the most precise way to describe us right now. And not necessarily where we will stay.
turnsout 11mo ago
The DX of Stripe is already great—it sounds like you want to give Stripe reasonable defaults. Not a bad idea, but if you know what you're doing, you can have AI read the Stripe docs and implement something based on established patterns. Who is your ICP?
- brunosutic 11mo ago
  > The DX of Stripe is already great This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together. Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU https://www.youtube.com/watch?v=YuXp7V4nanU
- agreeahmed 11mo ago
  Today our ideal customer is someone starting a project on day one who wants an easy pathway to 1) get stood up ASAP, and 2) start iterating on pricing as they learn what customers really care about. What we found when talking with dozens of builders was that the DX is indeed much better than e.g. Adyen, Braintree, etc. But their DX is far from the counterpart best in class devtools in auth, hosting, or databases. To be clear, what Stripe has built is a towering accomplishment. But a lot of why innovation in payments DX has been slower than other parts of the stack is that since Stripe, there haven't really been many others who have attempted to tackle the *entire* job to be done.
Denvercoder9 11mo ago
That's fine, but it does mean that your current submission title is factually incorrect. You didn't build a payment processor, you build a payment gateway.
whizzter 11mo ago
You intend to restrict this to a single market? There's some sibling comments that do point out that. Much "annoyances" when it comes to money is all those weird laws and rules from lower level companies in place, improving things for developers is a laudable goal but I do hope that you guys have some real world experience with these systems apart from frustrations as system users because doing a good DX right now feels like it could make you end up in a dead end.
- agreeahmed 11mo ago
  100% agree - this is not a space to tread into lightly. We have some really knowledgeable payments people in our corner, including several veterans with many decades of payments industry experience as leaders at the big payments players. There's a lot that we've been able to learn from them as they help us navigate the financial services side of this business. We're conscious of how much work there is to do, and how the "good DX" is really just the visible tip of the iceberg. Currently through Stripe we are able to onboard merchants wherever Stripe can serve them directly. Our upcoming merchant of record offering (which we hope to launch soon), will be available to merchants wherever Stripe can send payouts, which is a longer list of maybe 150+ countries. The pathway to building deeper payment rails will indeed have to be country-by-country as each one requires new banking partners and compliance regimes.

redbell 11mo ago

So, this is somehow similar to Polar (https://polar.sh/ https://polar.sh/)

codegeek 11mo ago

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.

amelius 11mo ago
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.
- theturtletalks 11mo ago
  Their website says fully opensource and since it’s a Stripe wrapper, this seems to be an opensource alternative to Stripe Elements. It does require a Flowgrad account and key so it will provide value if other payment processors started using it. Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
  - fn-mote 11mo ago
    I thought the whole post was about the benefits, namely that Stripe has too many webhooks and doesn’t handle enough of the tax computation. Did I misunderstand something? Or is this about a different angle?
    - theturtletalks 11mo ago
      Ah that is another benefit, using Stripe Elements and Stripe directly, you have to save the subscription ID and other fields in your database. Flowgrad seems to handle this on their side.
  - agreeahmed 11mo ago

Aurornis 11mo ago

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 learn that they can make some sales by promising a non-technical manager that buying this product will actually save them money because it’s easier to use.

whizzter 11mo ago
Literally describes one company I work for periodically.
skwee357 11mo ago
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.
- withinboredom 11mo ago
  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 ticket could be closed. This is much more common than you might think.
  - numpy-thagoras 11mo ago
    That describes more than just one POS (Point of Sale) company I know of.
  - 11mo ago

runako 11mo ago

It looks like this is more akin to a React-only Chargebee where entitlements etc. are stored with the billing provider. (Apologies if I am misreading the site.)

agreeahmed 11mo ago
It scans that way right now because Stripe is more visibly involved in the onboarding process. Maybe another way to parse it is "Shopify for software", where we combine the movement of money and subsequent state transitions involved in unlocking value. But instead of shipping physical items, it's granting entitlements. Either way, thank you for the feedback. We're still refining how we explain it.
- runako 11mo ago
  > we combine the movement of money and subsequent state transitions involved in unlocking value > it's granting entitlements This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space. 1 - https://www.chargebee.com/entitlement-management/ https://www.chargebee.com/entitlement-management/
  - agreeahmed 11mo ago
    There are a few billing engines that have shipped entitlement management offerings. We’re focused on making the best DX for managing entitlements as possible. A lot of that comes down to details: cloning pricing models across environments, React hooks to manage your state. We want to build something you pick to build with on Day 1 - rather than something your boss tells you that you have to use.