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.
I agree with them, your original post lacked clarity. I propose that the reason these types of conversations are less likely in person is because there is typically no log of exactly what was said and people tend to get defensive and narratives change. This makes it a pointless endeavor.
I would suggest, rather than wondering why people on the internet point things like this out, maybe wonder how many people in real life never bothered and just write you off.
"This behavior is a function of the core AI technology we use, we are unable to resolve this issue with a standard software patch or update at this time.
For the time being this issue can be mitigated by not asking about seahorse emoji.
We are closing this support ticket as the issue is an inherent limitation of the underlying technology and not a bug in our specific implementation."
>Claude sometimes thinks in a conceptual space that is shared between languages, suggesting it has a kind of universal “language of thought.” We show this by translating simple sentences into multiple languages and tracing the overlap in how Claude processes them.
It's because you aren't looking at 20 year old EULA's
>3.4 Benchmark Testing. The Software may contain the Microsoft .NET Framework. You may not disclose the results of any benchmark test of the .NET Framework component of the Software to any third party without Microsoft’s prior written approval.
This person is not likely familiar with the history of the .net framework and .net core because they decided a long time ago they were never going to use it.
As long as it's your deployment target and nothing else. For development, both macOS and Linux continue to be second class citizens, and I don't see this changing as it goes against their interests. In most .NET shops around me, the development and deployment tooling is so closely tied to VS that you can't really not use it.
It's fine if you stick to JetBrains and pay for their IDE (or do non-commercial projects only), and either work in a shop which isn't closely tied to VS (basically non-existent in my area), or work by yourself.
> The development and deployment tooling is so closely tied to VS that you can't really not use it.
Development tooling: It's 50-50. Some use Visual Studio, some use Rider. It's fine. The only drawback is that VS Live Share and the Jetbrains equivalent don't interoperate.
deployment tooling: There is deployment tooling tied to the IDE? No-one uses that, it seems like a poor idea. I see automated build/test/deploy pipelines in GitHib Actions, and in Octopus Deploy. TeamCity still gets used, I guess.
It's true though that the most common development OS is Windows by far (with Mac as second) and the most common deployment target by far is Linux.
However the fact that there is close to no friction in this dev vs deploy changeover means that the cross-platform stuff just works. At least for server-side things such as HTTP request and queue message processing. I know that the GUI toolkit story is more complex and difficult, but I don't have to deal with it at all so I don't have details or recommendations.
VS has the “Publish” functionality for direct deployment to targets. It works well for doing that and nothing else. As you said, CI/CD keeps deployment IDE agnostic and has far more capabilities (e.g. Azure DevOps, GitHub Actions).
No. My entire office is Linux and macOS. Not a single windows machine. Mixture of people using VS Code and Rider. No issues building and deploying to Linux. We pay for rider. Pay nothing for vscode.
Yeah? Ncurses still a thing? I only ask because that's the only api name I remember from forever ago.
I worked on a mud on linux right after high school for awhile. Spent most of the time on the school's bsdi server prior to that though.
Then I went java, and as they got less permissive and .net got more permissive I switched at some point. I've really loved the direction C# has gone merging in functional programming idioms and have stuck with it for most personal projects but I am currently learning gdscript for some reason even though godot has C# as an option.
The only thing that has become "less permissive" is Oracle's proprietary OpenJDK build, which isn't really needed or recommended in 99.9% of cases (except for when the vendor of your proprietary application requires it to provide support).
The rest of the ecosystem is "more permissive" than .NET since there are far more FOSS libraries for every task under the sun (which don't routinely go commercial without warnings), and fully open / really cross-platform development tooling, including proper IDEs.
The fact that you even need to be very careful when choosing a JDK is a lot bigger problem than some simple easily replaceable library is going commercial (not that this has not happend also in Java land). Also .NET is fully open and really cross-platform for a long time already and it includes more batteries than Java out of the box, you may not even need to include any third party dependencies (although there are also plenty to choose - 440k packages in Nuget). .NET has also proper IDEs or is Jetbrains Rider not a proper IDE for you?
Funny, because one the libraries I was using at the time went hyper commercial (javafxports). Java burned me on two fronts at the very same time and lost me. Ymmv I guess. It's always a good time to try something new anyway... I also moved to kotlin on android and couldn't be happier with it, it's a clearly superior language.
It's phrased weirdly, but the op is describing an idealized status quo as would be seen from a corporate standpoint. It was meant to contradict itself and thus:
>We need to pick a lane.
I imagine op would likely agree it isn't actually that monotoned and this was done for rhetorical purposes.
Given my skillset at age 22? Yeah, I'll take 1995. I was old enough to grow up hearing how great the world was going to be if I learned computer programming just to enter the job force at the start of the dotcom bubble burst. 1995 would have been a major upgrade.
Also, knocking that almost decade off my birthday would assure that I spent most of my adult life with the luxury of thinking that energy didn't have negative externalities that were being forced on later generations.
We had Chomsky-esq "any major world power is kind of fascist if you think about it" instead of literal talk by politicians about putting people in camps if they don't like your diet or country of origin.
TV was pretty bad I guess but music was great and I read more back then.
There was a lot of huffing and puffing about gang violence. I grew up on the street the local gang named themselves after and it only marginally touched my life at all.
Housing was dirt cheap, food was dirt cheap, gas was dirt cheap. There was undeveloped land everywhere around the city I live in and it gave a general sense of potential.
Yes, the US was in a particularly prosperous and exciting period compared to much of the rest of the world in 1995. If you’re, say, Chinese, chances are you find life in 2025 much more appealing
Overall, life is better in 2025 for the vast majority of humans. Life expectancy, child mortality, health (despite the obesity epidemic, which is a result of an abundance that has eliminated hunger and food insecurity from large swathes of the globe), purchasing power, access to technology and entertainment, etc, etc…
That some people in the US are feeling disillusioned because housing has become more unaffordable (partly because of regulations and technological advancements that have improved their quality and safety) and that they don’t have the same incredible economic trajectory as the preceding generations, especially since WWII, doesn’t negate that. A run like that can’t last forever, especially since it to a large extent depends on having a relative advantage over the rest of the world - at some point, they’ll start to catch up
A quick look shows not much has been found CVE wise with godot, and not anything on the 4.x version of the engine. There is an interesting case of it being used to build a malware loader.
I've actually been playing with it a bit recently and have had a couple mysterious crashes in their ide. It's likely ripe fruit for a curious security researcher.
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.