agreeahmed

7 ms·

31.
by agreeahmed 11mo ago
Definitely - it's the nature of software that it tends towards higher order abstractions that make the tools easier and easier to use. The final frontier is English as a programming language. The tools that are easiest to program in En
32.
by agreeahmed 11mo ago
This is great feedback. We aren't trying to keep it hidden at all. But we could be clearer in how we communicate it. The processing happens through our Stripe Connect platform, through which you currently have to set up a Stripe accoun
33.
by agreeahmed 11mo ago
That feedback is very well received, thank you. Currently you set up a new Stripe Connect account to get started. We tried the "connect existing account" flow and discovered that, maybe due to regulations or Stripe policies, we we
34.
by agreeahmed 11mo ago
Thank you, Zed's is so beautiful. Our team's blushing
35.
by agreeahmed 11mo ago
Thank you, that's very kind of you. Funny thing about the site: we deliberately tried to keep it single-page because we spent all of the past year building / testing the billing engine, data model, and SDK.
36.
by agreeahmed 11mo ago
This would be awesome, it's just really hard to manifest because every payment processor is different, has different life cycle events, etc. They also have different risk and antifraud functions, which you have to consider because they
37.
by agreeahmed 11mo ago
Currently it feels more like a Stripe wrapper because we haven't yet fully in-housed the onboarding experience. But you don't bring your Stripe API key, you setup a Stripe Connect platform account. Recharge Payments looks cool, al
38.
by agreeahmed 11mo ago
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
39.
by agreeahmed 11mo ago
Grace periods and past due - our current default behavior is: - when the first charge fails, we block access - when the n+1th charge fails, we continue grant access until you cancel their subscription There's a lot of work to do to mak
40.
by 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 involv
41.
by agreeahmed 11mo ago
We're working on getting there. What got us out of our seats to build this was realizing that LLMs still struggled with the fairly basic data modeling and distributed systems problems that existing payments providers pose. Any solution
42.
by 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
43.
by 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
44.
by agreeahmed 11mo ago
Yeah this very true. We have a plan to allow you to store more of this data on the merchant's side and still benefit from the work we've done to refine our data model, and make the SDK super usable. Even if you do hit Stripe'
45.
by agreeahmed 11mo ago
Very helpful callouts - both areas we want to build more robust product coverage. Handling tax and VAT edge cases are coming up on our roadmap. We want to offer a merchant of record service soon, and eventually make it so that you can steer
46.
by 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
47.
by 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. Th
48.
by agreeahmed 11mo ago
Gotta say we admire both teams, and have a lot of respect for anyone trying to make progress in this space. As far as differences: both are an additional service you need to bolt-on in addition to signing up for Stripe. We're aiming to
49.
by agreeahmed 11mo ago
Stripe Billing handles subscriptions and usage based billing now. Most software products fall in one of those two categories, or sometimes both. As a result, most software companies are paying more than 2.9% + $0.30 for Stripe, closer to 3.
50.
by agreeahmed 11mo ago
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
51.
by agreeahmed 11mo ago
That's definitely the gameplan. We believe very sincerely that developers deserve more choice when it comes to payments than they currently have. It's a central reason why we started building this. It just takes longer to make pro
52.
by agreeahmed 11mo ago
It ain't by much, but we're a tiny bit cheaper than Stripe when you consider how much they charge for Billing (.7% for them vs .65% for us). And pretty much every Stripe integration uses Stripe Billing (unless they pair with a 3rd
53.
by agreeahmed 11mo ago
Closer-to-the metal integrations with providers is definitely a big headache. Solving that problem takes a bit longer because you need bank partnerships, in many cases have to pass compliance screens, etc. We're aiming to tackle the mo
54.
by 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.
55.
by agreeahmed 11mo ago
Currently we're using Stripe to process payments, so you get all the benefits they provide for antifraud etc. baked in. You don't need to provide a Stripe API key, you just go through a Stripe Connect account creation through us.
56.
Show HN: We built an open source, zero webhooks payment processor(github.com)
405 points by agreeahmed 11mo ago|223 comments
57.
Platform as a Reflection of Values – Bryan Cantrill (2017) [video](youtube.com)
4 points by agreeahmed 2y ago|0 comments
58.
How Hansa Merchants Built Northern Europe's First Long Distance Trade Network(worksinprogress.co)
6 points by agreeahmed 2y ago|0 comments
59.
by agreeahmed 2y ago
Vibe coding has been such a full behavior change that people are vibe coding even sensitive mission-critical parts of their app, like payments. Which, I agree, means a lot more can go wrong. We're building an SDK that makes it easier v
60.
by agreeahmed 2y ago
And the first $1,000 you process every month are at-cost, 0% surcharge. For comparison, Stripe's Billing productcomes with a .7% surcharge on top of their standard processing fees. I've been somewhat surprised since starting Flowg

More ›