Introducing Login and Pay with Amazon
payments.amazon.com
payments.amazon.com
We are watching ;)
I am a happy user of Amazon Simple Payments, which is, as promised, simple, works well, and has good support. As another user posts though, I'm a bit confused at the role the various payment solutions play. In other words, we now have Login and Pay, but also Amazon FPS. What's what?
Seriously, my startup (tarsnap) is almost entirely AWS-based (the other exception is email -- I use sendgrid because SES is incompatible with public mailing lists) and I'd love to offer Amazon Payments as an option to my customers, but because I'm based in Canada it's not an option.
I recently took over a new but quickly growing webstore. Just two weeks ago we decided that we want to add "Payments by Amazon" as an option for our customers. We run a Magento Enterprise platform, so I was certain there is an extension for this.
Welcome to the rabbit hole... Do I want Checkout by Amazon or Payments by Amazon? Not clear as advantages of either or why I'd go with one over the other. After spending a few hours reading the differences I gave up and called friends until I got a contact at Amazon payments. Spoke with a super nice rep who explained to me why I shouldn't bother with CBA and look at Payments API instead... "But, I see there is a CBA Magento extension," I protested, can't I drop that in and be on my way? Turns out the extension is maintained by a 3rd party, and as far as I could tell and the rep confirmed it isn't really maintained at all, so even if we spent the money on it, no one could guarantee that it will work.
Fine, let's talk about payments, if Amazon is pushing payments api for merchants, there must be something for Magento users. I get told sorry, maybe there is something in the works but if I want anything up and running for the holiday season, I have to roll my own, and by the way please sign up for another Amazon service (I accidentally signed up for CBA, because it wasn't clear which I service I needed).
So here we are… building our own implementation for Magento. I know it's not Amazon's problem to support how payments are used, but if you want e-commerce merchants to take you up on this offering, some love for the ecosystem will go a long way and some clarity that CBA isn't being promoted anymore.
But I have to give Amazon credit, I've spoken to reps over at Selling on Amazon, FBA, Payments and they are all sharp, knowledgeable and eager to help. I can't say a single bad word about the people that interact with your business customers.
You're the CTO of Amazon, the revenue you're going to get from my business isn't even going to justify a rounding error on the balance sheet, but if you want to hear from the merchants, I'm happy to give you a view from the trenches.
Seriously: integrating payment processing is never the hard part; instead, it is integrating all of the accounting backends from different providers so you have all of the charges, fees, fines, refunds, disputes, etc. all being calculated and scraped in a way such that despite processing millions of transactions you are in a position to, for example, file things like VAT and income tax. It can take months of experience to figure out "oh, this API is failing to correlate chargebacks in these specific circumstances, but I can work around the issue like this" or to learn what all the different kinds of error messages that a user can end up seeing so you can provide support. It might even be worth it occasionally to rewrite everything if the new services always provided a superset of the functionality from the old ones and there was some kind of migration path, but Amazon just keeps making entirely unrelated solutions.
After the way Amazon has treated their FPS platform (they seem incapable of making even trivial changes: even just fixing wording in e-mails that they agree is flawed and confusing to users), I cannot imagine ever investing in another Amazon Payments product again (and I have tons of more reasons why I've come to this position, which I'm probably going to be putting together into a blog post soon, largely having to do with the lack of any reasonable payment fraud prevention model for third-party products). I honestly get the impression that they outsource all of their development for Amazon Payments and no longer have any expertise in-house required to actually maintain the software once deployed. (If nothing else, from having the opportunity to speak with a couple Payments developers working out of Amazon's India offices, I know that they are not running development for these products out of Seattle; the time zone differences might just be horribly brutal attempting to coordinate?)
To be clear: I tried very hard to work with them, having tons of meetings with greater and greater numbers of people on their side, putting together more and more detailed descriptions of what is going wrong on their end (even teaching them some things about payment fraud, which simply should not happen: I should not ever have anything insightful to say about payment fraud that they haven't already spent years thinking about... 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 ;P), before finally giving up a few months ago (I've just resolved to remove them entirely from my stack and replace them with more reasonable solutions).
Somehow PayPal manages, every few months, to provide interesting new functionality--even provide entirely new API layers--and it all maps back to the same accounting backends, old code continues to work with minimal changes, and the UI keeps improving (slowly, but surely). Amazon FPS in 2008 far surpassed similar offerings, but in the last five years PayPal simply built up the same functionality (better) while Amazon let theirs rot. It isn't even clear how this new Login and Pay with Amazon service is connected with Amazon Payments: they mention a random subset of the now-numerous Amazon payments-related products in the documentation as being incompatible with this (including Checkout by Amazon), but they don't even bother to mention a whole host of others (including Flexible Payments and Simple Pay). I've found an older version of the documentation (using Google Cache) that references Amazon Payments Advanced (another Amazon Payments offering that seemed targeted, ironically, at less advanced use cases), but the new integration guide limits the scope to just payments made via this service. They seriously have so many incompatible solutions now that it doesn't even seem worthwhile attempting to document how they relate :(.
I'd love to use Stripe if I could, but they're nowhere even remotely international enough.
Last I checked, one were restricted to Paypal, if using a Brazilian checking account.
Amazon has that same brand name advantage if it's easy to use for customers they have a good shot imo.
Stripe is still in private beta or non existent in many countries. I'm rooting for them but there are already clones coming out in countries where they are not available which might not be great for them long term.
Their prices were also fixed at the highest end of PayPal's fees (2.9% + $0.30), and while they now mention you can get volume discounts, they make it clear you shouldn't even attempt to discuss this with them until you are looking at over a million dollars processed every year. PayPal and Amazon, in comparison, list discount pricing on their websites for volumes as low as forty thousand dollars a year. Meanwhile, if your average receipt price is less than about $12, you probably aren't even considering Stripe, because PayPal will offer the same service to you with "micropayments" pricing: on a $1 purchase this will save you over 20% of revenue on processing fees.
I have not evaluated Balanced as a payments provider (I only remember them being usable for outgoing payments, not incoming ones; is this feature new? regardless, their pricing is as high as Stripe), but for the purpose of payouts you are looking at a tradeoff: they charge $0.25 per transaction, with $1 if the payment fails; in comparison, using PayPal MassPay costs 2% of the transaction cost, but is capped at $1. If you are building a large marketplace, and end up having to do a lot of dinky payouts, PayPal is going to be more cost effective. You also will have to file less paperwork using PayPal (you don't need to 1099-MISC someone if you use a third-party payment network, as PayPal will send a 1099-K instead, but you do if you use ACH), and will more easily be able to support international merchants.
1. a data model that wasn't oversimplified or awkwardly reported,
2. a decent API that also supported comprehensive automated integration tests, and
3. solid documentation and customer support.
No large, established company would pay 5%, obviously, but running small, on-line businesses without physical products, our priorities are different. A couple of percent of profit margin either way is nothing compared to the pain caused by accounting hassles and the lack of confidence if it's not possible to test an integration properly. In a small company, we're all doing everything, so any time we have to spend on accounting details or manual testing before we roll out an update is time we're not spending on things like marketing or feature development that actually make money.
Sadly, I have yet to find a payment service that is anywhere close to meeting all of my three criteria, and that includes many of those that get mentioned a lot on HN. That is why if anyone made one, they would have my companies' business faster than you can say "integration". For now, we settle for a combination of helpful customer service and APIs that we can make work with enough effort, and we hope that in time the services offering those things will improve their limited reporting and testing facilities.
As for the underlying data models that most of these services use, I'm afraid most of those are probably beyond redemption, and sooner or later I can see that being a significant liability to the kinds of service that are useful primarily because they're low-hassle and let you get on with other stuff. (Friendly advice to payment services: If you bundle up a charge to my customer, any tax we have to charge them that you may or may not record, any fees you charge on that transaction, any tax you're including with those fees, any refunds that may be made on a later date and therefore in a different tax reporting period, any tax to my customer included in those refunds, any fees we get back as a result, any tax that no longer applies on those fees, any chargebacks that occur, any tax that no longer applies to my customer as a result of the charge back, any fees you're no longer collecting, any tax on those fees, any chargeback-related fees and how much you're spending on my Christmas present for putting up with this lot all in the same single transaction record in your database/API, then our accountants probably don't like you, and neither do the guys here who have to reverse engineer all of the real data that we need to do real accounts in order to make our accountants happy again. There is simple, and then there is too simple.)
Authorize.net doesn't support partial captures on an authorization.
Is the best alternative to store their credit card and use that saved card to capture partial amounts? This would mean you couldn't do a full authorization upfront to ensure the customer has the funds available.
2) Only capture when the shipping is complete.
3) Do a full capture, and refund promptly if you/seller can't ship the rest. This is technically not allowed but some merchants/platforms get away with it. The "prompt refund" part is very important, you don't want to end up with chargebacks.
Just a warning to anyone that reads this: Last I tried (February 2013), micropayments were completely broken. Payments would fail for any customer that didn't have enough to cover the transaction as positive PayPal balance (eg. everybody - I never have more than $0 in my PayPal account).
I think you need to make a judgement (in the absence of hard data, which you often won't have before launching something!) on the types of users that might use your service.
For example: I'm building a service where the sole demographic is developers, and typically fairly savvy ones at that. I feel that I can get away with Stripe (credit cards) being the only payment option available because most of my users aren't going to be particularly averse to buying things online.
If I were selling physical goods, or SaaS with a diverse userbase, then I would certainly consider other options.
Nope.
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!
I would prefer to use PayPal but because Cydia doesn't allow for proper backgrounding, auto-login/password saving for PayPal accounts, or auto-login/password saving for saving Cydia accounts, I get stuck in a situation where I need to pull two generated passwords (IE, so complex I would never even try to commit them to memory.) from 1Password. One for my Cydia account (via Google), one for my PayPal account.
Swap to 1Password, pull one, swap to Cydia, login, swap out again, pull my PayPal password, and the payment flow is lost and I'm logged out of my Cydia account.
I'm sure there are reasonable technical excuses for all of this but I figured it was worth mentioning. This may not be a very common use-case but I'm sure the basics of "I use Amazon on Cydia because I can pre-authorize $50 and not have to re-enter my password every time" apply to many people.
I looked into it last year and from the merchant perspective you have to try do the maths up front. There is a trade-off between micropayments and 'standard' amounts, with the fee and per centage varying. There are discounts for higher volumes but not automatically applied. All in all it reminded me of trying to calculate AWS bills up-front; not trivial and prone to assumptions.
I'd say it targets an interesting niche the folk whom I know use it prefer Amazon's name to Paypal, and they are mostly higher-than-average salaried. I wonder what the comparison with other payment methods' demographics is?
Apparently sellers get your name, email address, and postal code as soon as you log in.
I think there can plenty of reasons to start a business in the US first (looser regulations and local talent are what comesto my first to mind) but would you lose business starting in a bigger market ?
Doing payment cross europe may have it's difficulties I don't know, but on the paper that's not so different from the US, and as a customer I don't feel friction dealing with other countries merchants.
For the language question, if you're building a payment processor, localization of your interface won't be your biggest problem. BtoB documentation and support is OK in english, customer facing interface should be localized, but even supporting the main 3 or 4 languages should let you access most of the market.
Except this is on your web-site and you would be making your customer Amazon's customer.
There is a deep conflict in this solution, and no doubt some people will jump for it not deliberating on what it could mean for them.
For me this represents a shift away from payment processing (Stripe, or even PayPal), and towards ownership of the set of master records that power an online commerce business. There is a fine but clear line between helping to process a payment and taking over the ownership of the customer. This is your customer, not Amazon's, and the master record should be in your hand and leveraged by you, not Amazon. I would be very hesitant to walk this path.
However if you're providing novel solutions that aren't low cost solutions, and are innovative "disrupting" "gamechanging" "social" products, why do you care that amazon is your payments provider, or for that matter, anyone. Other than what they actually provide and their service that is.
Also, with paypal, they get your sales data, sell it to others, AND then just keep your money and close your account.
I wonder if there are tax / legal reasons why they don't do that with affiliates?
EDIT: I am not specifically sure what they do with affiliates. I am talking about the general principle they operate on - They typically delay paying their vendors/suppliers, so there is a delay-pipeline of cash flow which Wall-Street analysts deem as a good thing business wise.
It's typically called the "float". Applies any time you receive a payment but take a while to pass it on.
... which was inspired, in part, by Eugene Wei's thoughts on how Amazon's float gives them leverage: http://www.eugenewei.com/blog/2012/11/28/amazon-and-margins
a) use it in case of emegencies
b) make more money (interest)
Maybe a good business idea but still shady practice. Google's AdWords does the same.
So why can't they just send them to my credit card or bank account, like normal companies do, after those 2 months in which they hold the money? At least it would only take a week or a few days to get the money after that.
I just don't see what Amazon has to gain by not partnering up with credit card companies. It's certainly a terrible deal for their affiliates. Not only do you get the money 2-3 months after Amazon sends it, but it's also like 10 percent fee, when the credit card company gets only like 3 percent. So yeah, I really don't get them here, and I think they're just being lazy, and used to the status quo.
http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...
In that podcast, they show money being transferred between UK bank accounts in a matter of seconds - which makes me wonder about some of the comments on HN re: the Amazon system not being offered in Europe.
There must be differences between a fast money transfer system and a payment system?
There was some speculation at the end regarding the lack of upgrade of the ACH system, and that large banks might not want competition with fees from other money transfer methods (e.g. wire tfrs).
We have an affiliate program and had to switch to 60 days (our chargeback window) because of credit card fraud. If it were not for this, I'd just as soon push out instant payments...
Off topic, I know, but come on. It's the last major service I use that doesn't even support it.
I feel like I'm either blind, stupid, or looking at the wrong website (or all of the above).
To get started for free, sign up for an Amazon Payments seller account. You will need your legal business name, contact information, a US credit card, and a US address. After you sign up, you'll be able to use our tools to create HTML that you can copy and paste into your website code to show our button and start accepting payments.
>> at this time it does not support payments for digital goods or services.
~B
Getting email addresses is the key. That doesn't happen with most 3rd party-login/OAuth implementers.
"Rates for Micropayments: For transactions less than or equal to $9.99, we offer a fee of 5.0% + $0.05 per transaction."
These micropayment rates match Paypal and is better than Stripe.
I'm keeping an eye on this.
That said, our offering is pretty different from what Amazon is doing. We are more about letting apps customizing their login/payment experience so that customers don't realize they are not interacting with the app.
We let you integrate with your Braintree account (Stripe support on it's way). Our aim is to make take away the common developer drudgery of setting up signup, signin, password reset, recurring payments and sending out pdf receipts that are common to building SASS webapps.
I want to know basic things like how would I - as a developer - get my money when people pay me.
Why is that so hard to find?
1. Vertical integration with merchants that sell on amazon and their own websites 2. Encourage merchants to inventory, and fulfill and transact via amazon 3. Enable a Global marketplace for their merchants 4. Next step, subscriptions and data.
But it all hinges on execution...
If that is what you are looking for a service that supports SASS login/subscriptions, perhaps you might be interested in my startup http://authic.com
"You can withdraw funds from your Amazon Payments account at any time. Transfer can be made to a verified bank account or an Amazon.com Gift Card."
https://payments.amazon.com/help/Marketplace-Seller-and-Kick...
A couple of years ago, I was a seller on the Amazon marketplace. My account got banned and there was absolutely no way to talk to a real person to try to resolve the issue.
They shuffled me around to different customer service reps (all through email, no phone support) who would give me cookie-cutter responses. Eventually, they just stopped answering my emails and told me not to contact them anymore.
Luckily, I got my remaining account balance back in 90 days.
they also overban customers.
Please eat the people who keep giving Jeff Bezos more money inciting him to become an even bigger jerk last.
Thank you. I remain, as always,
Your humble Cultist, Mike
(but you knew I was going to say that)
Conversion is everything for online merchants. Identifying customers early in the shopping experience allows better marketing, better engagement, and higher conversion. Plus, to be able to pay again in 1-click is huge (no additional login, no entering credit cards). So ultimately it means more $$ for merchants.
Yea. It's Amazon. They're kind of a big deal.