Re open source: the SaaS is under AGPLv3, and the rest is MIT.
Re “processor”: often when payment providers first get started they don’t fit into one of the established payment vendor categories because they need to piggyback off someone else’s infrastructure. We figured it would be better to make clear that we’re not a billing SaaS, but also providing payments processing - even if for now that’s through Stripe Connect.
Eg we are aligned with our merchants in worrying chargebacks in a way that “bring your Stripe key” billing SaaS is not, because our setup means their chargebacks are a concern for us similar to how they’re a concern for Stripe.
About the „processor“: IANAL, but I would assume that a payment processor has liabilities and regulations similar to that of a bank - line it’s the case for PayPal or Stripe. On the other hand, no one would raise a concern of you were forwarding transactions to Visa or some huge bank, so this is probably just a communication issue that you might want to tackle upfront.
This thread has been eye opening for revealing how much more clearly we could be explaining the funds flow story. Thank you for your feedback!
Since we’re the payments provider (using Stripe under the hood), we’re not currently able to support “bring your own provider” unfortunately.
They use Clover’s platform to provide devices and APIs (you could in theory use another vendor’s devices if you really wanted to).
In general, I don’t want someone else to be my payments provider since we do a lot of subscriptions, which would leave me completely locked in to a provider. Already been there done that with PayPal.
For folks who just want to get set up and get going quickly and don't mind working with a payfac to do so, we feel they should have more options, especially when it comes to DX.
Pasting the full root license file below: — Flowglad is fully open source.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3
From what I can tell, any time you use this to check something like the customer's subscription state (or anything else payment-related) - either from the front end or the back end - it's going to perform an API request to Flowglad's servers. If you care about responsiveness, I'm not sure that's a good idea. Of course, you can cache that state if you need to access it frequently, but then it kind of defeats the purpose of this layer.
Stripe integration can be tricky, but if you don't want to store anything locally, you might as well just hit Stripe's APIs without the middleman. For the payment systems I've worked on, having cached state in the database is actually really nice, even if it's a bit more work. Want to do a complicated query on your customers based on payment/subscription state and a bunch of other criteria? It's just a DB query. With this, I think you'll be hoping they expose an API to query what you need and how you need it. Otherwise, you'll be stuck waiting for a thousand API requests to fetch the state of each of your customers.
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's APIs, you will need to maintain mappings of price ids to your plans, your plans to what features you grant for each, stripe customer ids to your customer ids, etc. That's the kind of grunt work and maintenance burden we'd like to eliminate.
Plus, Stripe is explicitly designed to be a write-optimized system, and discourages[0] using them as a realtime read layer. We're super early in the journey but that's the problem we want to solve: how can we give software devs the same unified money movement + value movement experience that Shopify has availed to DTC brands for nearly 20 years?
I very much relate to the problems you're trying to solve, so much so that I have created a Stripe integration library [0] that has very similar DX to flowgrad! (not nearly as feature rich however). I've also written a blog post as to why I built it[1].
Key difference is where the final billing information is stored, our library also ships db schemas and the webhook handlers write to that local db.
You should also check out our (open source, MIT) library[1] this is built on, it could be useful for you guys!
[0]: https://fragno.dev/docs/stripe/quickstart
As a relatively new developer, I'm curious why the dependancy on React?
Was there no way to get the UI you wanted without implementing a framework like React?
We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
We started with React because that’s what we knew best and the community we were most embedded in.
We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
> customPreactRootRenderFunction(document.getElementById("outlet"))
E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.
How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration.
If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.
To be fair, chosing Svelte over React explicitly means that - if the React installed/userbase is 10-50x as big, you will be frustrated with this a lot. But in the end I don't get the frustration, in the end react is not a framework and you can render any component into a single HTML node that is part of your Svelte system. If the external library is encapsulated well, you shouldn't even notice that is react based.
And the problem goes substantially beyond billing UI. There's all the unseen tedium that devs need to implement in order to derive proper app behavior based on their customers' billing state. Most of this work is transposing billing state (and its derivatives) and then lugging it to the client where it will be used to show upgrade buttons, gate feature access, show outstanding usage balances, etc.
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.
From a technical perspective, building it on framer was pretty easy, though, it has some limitations with more complex SVG imports. I mirrored the Shadcn global.css color variables from the portal on the website for a more consistent vibe. Definitely recommend that.
From a design perspective, I wanted something radically simple, with taste. The narrow width visually demonstrates simplicity at a glance. I love narrow sites. Instinctually feel amazing. The double dashed borders will eventually turn into “flowing” lines. Which is a Flow of funds reference. We also worked with primary studio to help us choose some colors, typography, and patterns we’ll likely introduce later.
Hope this helps!
Now I might have to spin up a whole area of infrastructure I may not yet have to track eg usage, subscription tier, cancellations etc
In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify has webhooks but they are not the primary load bearing site of payment integration for most storefronts.
Payments webhooks were, from what I can tell in the history, a hack for side stepping gnarly problems in domain modeling and read optimization.
But payments are event-driven in reality. Credit card charges can be disputed, some transactions only succeed after a delay, or transactions or refunds you thought were successful turn out to actually have failed. Some payment methods are more susceptible than others, but even credit cards are affected by some of this.
The point is, stuff will happen to your payments without you initiating the change, and out of your control. Like, you know, events. Now you will need to become aware of them, and either you keep polling updates for a lot of your payments to catch the one that changed, or you have the information pushed to you.
Webhooks are great for that.
(Edited because a word was missing.)
Eventually we want to get to a place where we are embedded deeper on the payments side. But for now that's the flow.
For all I could see this is no different than any other payment gateway service. Well, it is different in one important way: you'll pay a higher percentage per transaction, since the middle man needs to make money somehow.
We’re not really trying to compete on cost. But we certainly aren’t more expensive once you include the cost of Stripe Billing.
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.
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.
How can any of this work without dealing with credit card payment processors
This is a frontend for Stripe, so it's even a bit of a stretch to call it a Payment Service Provider. Payment gateway maybe, but really it's a Stripe frontend.
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.
Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
Did I misunderstand something? Or is this about a different angle?
With Flowglad’s hooks and server SDK, we get that data to your frontend and backend. So you can read it from us wherever you need it.
Stripe would likely change their ToS and then revoke their API keys before they could get anywhere near that level of dominance.
The processing happens through our Stripe Connect platform, through which you currently have to set up a Stripe account. Over time, these details will be more abstracted away, much like Vercel is reselling AWS under the hood but doesn't require you to hand over AWS keys.
Right now, the reason this feels more like a "wrapper" than Vercel is that we haven't yet built out our own onboarding and KYC flow. We wanted to first deliver an amazing developer experience - something we're still working towards.
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 weren't able to debit the existing accounts.
Our Stripe flow is different from the run of the mill billing SaaS because we're involved in the movement of money (rather than simply using your Stripe key to steer API requests on your behalf).
We know that makes us look a bit like a fish with legs while we grow towards where we want to be.
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.
It's very likely at this point that the supermajority of future programmers will have almost no formal computer science education. They'll want tools that don't require a deep understanding of the prior generations' layer of abstraction. That's kinda the world we're preparing for - builders who don't need to be deeply technically involved in the details of their vendors in order to build successful software companies
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.
This is much more common than you might think.
I ask them to protect themselves by logging what data they will need to troubleshoot a new feature.
Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs.
It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit.
Days long anxiety-filled shit storms for absolutely no reason.
I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...
In amy case why does a dev need to understand a (yet another) poor DX complex API (stripe) in addition to the other 20 they need to deal with. What is wrong with taking something off the plate. It is like daying dont use high level languages, use Rust, don't use a library to make http calls roll your own etc.
But to reply to your point, there is no way out of this. You either understand the tools you work with, or you end up vendor locked to tools like vercel/next (the target audience of OPs tool, as it seems), which promise simplification, but end up being their own monsters.
The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
It’s a sad world.
-- actual (retired) full-stack engineer
Imo you can trace a lot of how devtools, particularly webdev tools, have evolved to this. They are more React-brained. Specifically they try to take state management responsibilities off their users' plates.
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/ 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.
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.
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.
Issuing side (the side that "issues" the cards) is usually the one that people describe as "all of the value", while acquiring (the side that "acquires" merchants) usually is that one that needs to bring substantial volumes to market.
For context to anyone not familiar with payments, about 60-70% of the card revenue in a transaction goes to the customer's / issuing side because they are the side that assumes credit risk for the consumer. The merchant's / acquiring side has significantly tighter margins and usually needs substantial volume before it can become an interesting business. One way that entrants on the merchant side of the stack monetize is by bundling value-add software.
E.g. Stripe does this with Billing (+.7%) and Connect (+.25%).
Fwiw I agree that most people will find this tech extremely un-fun. But I'm a "payments rail guy" in the way that others might be "train guys". My inner child lights up at the thought of payment rails. My Substack, Vivid Leaves, is basically a bunch of essays about historical payment systems - some we worked with in Kenya, and others I studied from the USSR. I wrote all this before I had any idea I'd be starting a payments company: https://agree.substack.com
We know it's going to be a schlep, and we're going to have a blast schlepping through it.
* vocab fyis for anyone reading this not familiar with payments.
> Issuing side (the side that "issues" the cards) is usually the one that people describe as "all of the value"
In theory you could argue "all of the value" may be there, but that is locked up across issuing banks and the credit card companies themselves. You basically cannot compete there unless you have some novel way of creating a credit card that isn't Visa, MC or AMEX. There is also a reason banks haven't consolidated on the issuing side because it's an uninteresting business for them, otherwise they would. Hence the credit card side is all about volume and hence all of the value for software providers is on the acquiring side.
> The merchant's / acquiring side has significantly tighter margins and usually needs substantial volume before it can become an interesting business.
You're myopically looking at one part of the acquiring side. Controlling the merchant relationship means theoretically unlimited upside, versus the issuing side that is usually capped by regulated interchange fees or market pressure. There are thousands of providers that sit on top of Stripe (and other similar providers) and charge 4%~7% and capture the residuals (which is a higher BPS than Stripe itself), hence this is where the value is. Stripe et al compete on volume because they themselves get volume discounts on the underlying providers (e.g. if you have a high enough volume Stripe will charge you less than the rack rate...just like everyone else that provides a software gateway). I would argue the economic value created by providers sitting on top of Stripe is greater than the value Stripe generates for themselves.
> My inner child lights up at the thought of payment rails.
Payment rails for Visa/MC/AMEX is very different than your experience with moving money at banks in Kenya/Russia. I've actually seen the tech that runs the rails for payments in the US. If anyone thinks the Paypal dev experience is bad, wait until you see this shit.
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.
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.
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.
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
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.
fewers bugs = happier customers not getting charged for shit they didn't agree to be charged for
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!
Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
(Apologies if I am misreading the site.)
Either way, thank you for the feedback. We're still refining how we explain it.
> it's granting entitlements
This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space.
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.
I'm wondering - is there some overhead required to keep operations up? Or Flowglad takes care of everything between code and compliance
Also, sick sweater I have the same one XD
And then we, alongside the processing partners we use on the backend (currently Stripe, soon hopefully beyond) handle the rest.
Re the sweater: great minds ;)
- How are you handling tax/VAT and edge cases? Like usage backfills or retroactive credit grants, etc. etc.
- What’s the failure mode if your service is down?
Either way, refreshing to see someone go after this with the opinionated DX!
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 the funds flow at a per-transaction level.
We monitor our uptime closely[0], but we're also working on giving more options to self-host the source of truth component of our offering for people who want to be more in control of their certainty.
What if there was some standard API interface for payment processors? Basically AWS S3 API, but for payment processors.
The idea being that migration between payment providers should be low friction and standardized. If you're in Stripe jail or banned, start using paypal (or something else) just by changing endpoints + credentials.
Since Stripe is the gold standard, we could standardize on that (like how cloud providers standardized on S3).
I think India has implemented something to this effect.
Thoughts?
You can kind of get something that approximates this with a PCI vault or a payments orchestrator, but it's really hard -- maybe impossible -- to fully abstract away all the differences.
What you want already exists though, and it's called a payment orchestrator. They integrate with different payment providers and provide you one API. You pay for that by getting a much smaller feature set.
Instead of having to implement all that yourself, you just read the latest billing and entitlement state for each of your customers from Flowglad:
const billing = flowglad(user.id).getBilling()
const hasFastGen = billing.checkFeatureAccess(‘fast_generations’)
What are you using to manage your workflows on your backend?
What differentiates you from competitors like Lago and Autumn?
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 consolidate onboarding as a single provider that both processes. A lot of work still to do on our side, but that's where we want to end up: that you get your dream devex without needing to sign up for 2 products.
Both are essentially billing-only services where you bring your API key. We have a billing engine that we built from scratch, and are actually processing the payments, currently using Stripe Connect under the hood.
Lago seems to still require you to deal with webhooks - if not theirs, then Stripe's - and is focused on "billing as write operation" (their first-class concern is producing a correct, well-formed charge or invoice object). We want to solve both the "read" (what features can my customer access, what balance does their usage meter have?) and the "write" more conventional billing operations like charges, prorations, converting free trials to paid, etc.
With Autumn we're tackling a similar problem but they currently still require you to use Stripe Billing + your API key. So you'll be paying for Stripe Billing + Autumn (unless you self host). Overtime as we get deeper into the money movement side of things our paths will look more different, as more of our devex will include smoother ways to handle funds flows, tax compliance, etc.
And compared to both, at least from what I can tell from the outside, we're putting relatively larger share of our brain cycles towards making our SDK and docs deeply intuitive for coding agents.
We want to design our default integration path around the assumption that you will have a coding agent doing most of the actual work. As a result we've got some features like e.g. an MCP-first integration path that makes it easy for your coding agent to ask our docs pointed questions that may come up as it integrates Flowglad. And a dynamically generated integration guide md file that considers both your codebase context. A lot of that is the result of our own trial and error trying to integrate payments with coding agents, and we're going to be investing a lot more time and care into that experience going forward.
Is this the case with Flowglad? We have a SaaS with a monthly team seat fee + usage fees, but we also offer a bespoke service where we may bill per hour or bill per project (for work done and delivered inside of the SaaS). So these would be higher ticket.
Would you support this?
When we begin our merchant of record offering, you will not be able to use it to sell human services. That’s not a Stripe regulation but has to do with the merchant of record offering and the compliance posture you need to build for that service.
What's your approach to 3DS and related race-conditions for subscriptions? In my experience 3DS is by far the biggest problem for subscription integrations - not the webhooks.
There's a lot of work to do to make that behavior more configurable, because every merchant has a different policy.
For 3DS we're working on getting more explicit coverage for. Not quite 3DS but related: we currently have it set up so that if your customer successfully adds a payment method but the first charge fails, we also won't grant entitlements in that case.
Lots of weird payments edge cases to work through still.
* inflexible subscription system
* unreliable web component for gathering credit card information
* unreliable 3DSecure implementation
* incompetent support (these four are the main reasons why I switched from Braintree to Stripe)
* complex and untestable flows for non-mainstream payment types (e.g. SEPA direct debit, IDEAL, etc — Stripe makes you think they will just work, while you need to implement complex logic in your system to make them work)
* PCI compliance (Braintree hires SecureMetrics, they audit everyone even if you are below PCI thresholds, and the audits are idiotic; they complain about ssh version numbers on Ubuntu LTS systems which have all current security patches, etc)
* US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid)
* lack of B2B subscription billing using proforma invoices
Things that would worry me looking towards the future if I were to switch a payment processor now:
* pricing (this matters in spite of what HN often says)
* lock-in (Stripe Billing was free, then 0.5% of revenue, then 1% of revenue, what's next?)
* reliability of 3DSecure, as problems here are extremely difficult to debug and easy to blame on "customer's bank"
You might note that this list contains mostly non-technical items.
But overall I'm very happy to see competition in this field. Payment processing is in a sad state and there are not nearly enough companies doing this.
This sounds strange. I don't think there's anything US-centric about considering an invoice to be a payment request — which makes issuing them after payment nonsensical.
Most EU countries use an accrual-based VAT system, where taxes are owed on any invoice issued, paid or unpaid.
This makes issuing them before payment nonsensical, because you will end up paying taxes on invoices that will never be paid, thus ruining your business.
A proforma invoice exists specifically for the purposes of quoting and requesting payment.
Full disclosure: I'm a dev at a fintech startup and we're currently working on these two things so I'm curious how our direction lines up with your thoughts
For example, Braintree can't switch from monthly to annual billing (or the other way around). You have to delete the subscription and recreate it with a different billing period.
I want my customers to be able to switch plans, billing periods, currency, and buy additional items (user slots), all with proration.
> what you would like to see from a 3DSecure implementation
I would like not to see anything, really. I want to forget 3DSecure even exists. Stripe largely gets this right. Braintree required me to do many rather bizarre things, pass additional data, and then rewrite the entire flow once every couple of years or so. With the last rewrite, I was told that in my case (SaaS subscriptions) I would need to drag the customer through 3DSecure TWICE and that there is no other way. So I switched to Stripe, because I value my customers' time.
Also, 3DSecure with braintree would fail every once in a while and I would get customers from various countries telling me they are unable to subscribe. Braintree support, after a week or two, would inquire and either tell me it's the customer's bank (not helpful), or tell me that I have to rewrite my integration to a New Way of Doing Things, which was usually so far off the mark for my use case it wasn't even funny. I just checked my E-mail archives quickly for "Braintree support", over the years I'm up to around ~400 E-mails exchanged.
(IANA I am not an accountant) but how is it legal? as a customer you want to pay against an invoice, and AFAIK it is required by law in most places.
But in general, this is why proforma invoices exist.
Over time, we'd like to go deeper on that layer of the stack. But it's a long journey and we're still super early.
Recharge Payments looks cool, also seems more focused on Shopify stores?
Copy pasting the front page:
> We provide a payment system that makes privacy-friendly online transactions fast and
> Payments without registration
> Data protection by default
> Fraud eliminated by design
> Not a new currency!
> Empowers communities to run their own payment infrastructure
> Free Software
let's say a customer has found your website and wants to buy something. they first have to install a third party wallet app, fund the wallet by buying coins thru an exchange, then use the app to make a payment to the merchant.
it's the same UX problem crypto has tried (and failed) to work around, but with extra friction since it still depends on local currencies and has an unnecessarily obtuse deposit fees formula that emulates physical coins.
Obviously you have to install the app, that's true for any app. But you only have to do it the first time around.
Are you just saying that this payment app has the first time friction of downloading the app. That's the same for all apps. Are you just saying that friction exists, and is a barrier to entry?
The part that buckles first is always the billing logic. Not the API calls, but the lifecycle math behind experiments… and the experiments never stop now.
So anything that lets teams iterate without rewiring state machines every week is going to find an audience. Most people just want to ship, test, adjust, repeat, without their billing layer collapsing under the pace of AI.
Nice launch!
It turns out that the architectural changes that make that easier also make the tool generally easier to use for a bunch of different use cases.
In urban planning they have a name for this: the “curb cut effect”, whereby urban planners found that curb cuts, that had been made for a specific accessibility need such as people in wheelchairs, ended up being useful to all kinds of people: cyclists, people walking at night, pedestrians with weaker joints.
Devtools seem to benefit from a similar curb cut effect, where gains in a tool’s usability for one domain generalizes across many others.
It makes it very clear, and easy to understand.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3
Seems like just another entry into this space. Also, you should probably change the title of this post because this isn't a payment processor, you are not processing payments in any way at all. You're just a middleman with a UI, and a nice UI can be good, but it's not more than that.
And serverless
Just have the client redirect to your checkout flow, and it redirects back with a signed payload. Like oauth. Done.
Make an HTTP interface that’s easy to curl, as well as a Javascript library to assemble the request and verify the result.
Client JS can handle own postbacks. Maybe not even to their own domain.
Or maybe client server will read that querystring in the resulting request and verify signature.
Totally up to the customer.
Finally, have the sdk also have an option to load an iframe (eg in a dialog) instead of redirect, and use postMessage for securely sending signed result. Just make sure to use Intersection Observer v2 in that case https://web.dev/articles/intersectionobserver-v2
DONE
PS: Hire me ;-)
While you do the banking side, I can integrate a ton of web3-enabled stuff for you including invoices across blockchains, recurring subscriptions, as well as contests and auctions for price discovery. See https://intercoin.org/applications
Payments are getting slightly more asynchronous, not less.
Very expensive!
Isn't Stripe Billing only for subscriptions?
To only pay Stripe 2.9% + $.30 they'd need to only use Stripe just for charges, and either build their own billing engine (usually poor use of time) or use a 3rd party SaaS.
As we approach Black Friday in the US, I'm thinking of the giant volume of e-commerce transactions that are not subscriptions (or usage-based), and of which Stripe gets a cut. It sounds like you are not angling for that part of the market?
We where never even close to 2.9% on credit cards, and we'd certainly never consider paying 30¢. Part of that is working out of the EU, that caps your credit card fee, so around 1% and 0.10EUR per transaction is closer to the standard. Then you can start negotiating lower raters from there, depending on the number of transaction you make.
thank you, very productive reply
It just takes longer to make progress on that problem because of all the institutions involved.
[see https://news.ycombinator.com/item?id=45988611 for explanation]
FWIW your claim here is false: "Everything you have commented on this post has been negative". I don't think this comment of mine was negative: "the landing page is one of the most beautifully designed things I have seen in a long time". Also note that when someone criticized the level of fees, I responded to that comment by saying that the fees were "standard" (as opposed to high). So just to set the record straight, not "everything" I commented here was negative.