[NateThePirate]

I worked on a project where the client wanted to switch to Authorize.net from Stripe midway through because of Stripe’s cost. From a developer perspective, it was a lot more miserable to work with than Stripe. Other projects I’ve worked on have had a similar motivation for not using Stripe.

Annoyingly, the cost of implementing the replacement and getting it working with React Native (which involved creating native modules for iOS and Android) ended up costing them as much as several years of fees. Also the client was a startup that went bust, so they never really got the value out of it that they hoped.

[bobwall]

Yea, when companies really want to lower the cost, they implement directly with the bank, like say JP Morgan. That makes authorize.net even seem good. Stripe is really a pleasure to work with as a developer.

[hakfoo]

Interestingly, I tended to prefer Authorize.net to other alternatives. But a lot of that is likely a 'moment in time" thing when I got into development.

There were a few years where Authnet was the "default" gateway. Other gateways offered compatibility modes for their SIM and AIM APIs, and if you had some random off-the-shelf cart, it probably spoke AIM out of the box.

Part of the difference in experience is also likely due to their model. The Authnet model was very much "take direct card data and relay it to your server and then to us", and the Stripe model is very much "JavaScript up your checkout process to do tokenization, so you never see the card number." If you're at a point in time when JavaScript is a bit sketchy (the IE6-is-the-dominant-browser era), you might be more willing to go for a worse PCI compliance scope in exchange for the comparative bulletproofness of doing things server-side.

Now I work for a firm competing with both of them, so I can hardly express a preference today. :)