>I'm just a tiny merchant, whereas they are either one of the world's largest merchants or a payment processing firm depending on which angle you are looking at

>I'm just a tiny merchant, whereas they are either one of the world's largest merchants or a payment processing firm depending on which angle you are looking at them from And, therein lies the problem. Paypal suffers from the same. Do you want to help me charge a card? Or, do you want me to help you grow/leverage your ecosystem? Because when you do the latter, you expose me to added complexity and risk, when I just want to charge a card. This stuff is exhausting. It's not building reusable rockets. It's just payments. Everything doesn't have to be integrated with everything. I think this is why companies like Balanced and Stripe exist. I don't want to issue a call, redirect to multiple URLs, then receive a callback at a URL that I then have to parse, then deal with the fact that this is happening asynchronously and I must manage/notify the user. I just want to charge a card. I don't want to integrate deeply with your login and expose myself to your internal missives/process changes, etc. I just want to charge a card. I don't want the increased risk that stems from the baggage that exists because you don't want to be a pure play payment gateway, but instead want my customers to engage in your ecosystem whenever they want to pay me. I just want to charge a card. I don't want to become a de facto merchant on the Amazon Marketplace. I just want to charge a card. A while back we looked at Amazon Payments, and it was a complete turnoff, starting with the documentation. Simple questions like, "how do we get paid?" and "do customers have to open an Amazon account?" took too much effort to answer. From my recollection, the doc was written starting from the middle. Too much was assumed. Seriously, go look at the doc now and figure out what you need to do to just charge a card. Just the number of payment services (some of which you listed) will give you a migraine. It's like a parody with the similar-sounding names, feature lists, and suitability tips. I just want to charge a card. Now, go look, at Balanced. You will be charging cards within hours. PayPal is/was similar, but not as complex. Their addition of simple NVP calls, while non-standard, was a good move away from SOAP, and their offerings aren't as confusing. But, while implementing as a merchant processing solution, I always resented that they forced giving customers the "Pay with PayPal" choice. It required that you implement their wacky Instant Payment Notification, which required far more code than just charging a card. There was the additional user flow management, as well as capturing and processing all of the variables that could be posted back. Why should a merchant who is paying significant fees be required to bend over backwards in order to promote PayPal to its own customers? Shouldn't the merchant at least have the choice, and maybe receive a discount on fees if he/she opts in? I think it's similar with Amazon Payments. They should decide whether they want to be a pure payment processor or they're just trying to leverage existing hooks that they already have in customers and/or are just using payments as another means of bringing customers into their ecosystem/marketplace. If it's not about pure payments, then cool. But, just say it and know that it gives plenty of room for pure-plays like Stripe and Balanced to claim some serious share. We've done a test integration with Balanced and If I had to choose on a project now, I wouldn't even blink before going with a simple, pure-play solution like it that only wants to help me get cards charged as easily as possible. Give me a little higher fee instead of a hidden tax in the form of a ton more code, added dependencies/risk, and maybe even new internal processes to manage. BTW, I am an Amazon fan--both as a personal consumer and a user of various other AWS offerings, so this is by no means an anti-Amazon rant!