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.
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/ to see it done well.
Also, adding another layer like this, you better have an early plan to staff a support desk.
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.
> We want to go as "close to the metal" as we realistically could as soon as we could.
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.
Unless I'm misunderstanding, I think you might have gotten sides mixed up?
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.
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
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!
