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. :)
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. :)