It would be interesting to see if they plan to link Amazon Coins to this somehow. They could try to aggressively go after PayPal by offering 1% cashback in Amazon Coins for all purchases through "Login and Pay with Amazon" and lock users into the Amazon currency.
Yep, I thought it would be of interest to the HN community, but most importantly I was interested about the comments/feedback/criticism of those who would potentially be using it.
I don't know what fraction of AWS users are outside of the US, but I'm sure it's not a completely trivial number. Please, find a way for us to use services like this. I know there's legal and accounting headaches involved, but they can't be any worse than the headaches involved in buying land and building datacenters, and you manage to do that just fine.
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.
Yeah, there is a real opportunity here not to just read saurik's well-thought out reply, but respond to it. I have no doubt that he has sent very detailed emails to them, speaking as one engineer to another, and there is no better way to turn someone off than to ignore them after they go through such pains to make your product better.
I would love to have a minute to talk to you about this.
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.
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?
Amazon already offered the login feature (this was launched earlier this year), and they already offered an API-based payments platform (Amazon Flexible Payments, launched in 2008). Rather than just allow you to pass login tokens to Flexible Payments, however, they have decided to provide a completely incompatible API with a new set of endpoints, a completely incompatible accounting system, and even completely new terminology to describe the same set of steps. As someone who has invested heavily in Amazon Payments solution over the last four and a half years (for a long time I had been their largest customer doing mobile payments, and when jailbreaks come around I still leap upward in their charts), I frankly look at this as a massive "fuck you", and not any kind of reasonable step forward :(.
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 :(.
FWIW, when Stripe launched they did not have any way to correlate chargebacks at all, nor did they offer separate authorization/capture phases (which is required to ship physical goods: you are not allowed to actually charge someone's credit card for a purchase you are shipping until you're about to actually ship the product). They also had rather weak webhook retry support (it would retry a couple times over short periods of time, if I remember correctly). They have since fixed these issues, but in the mean time their main benefits have been cloned by PayPal (easier to read documentation, and a JSON-based API that can be used from a browser).
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.
I can't speak for anyone else, but the reasons we've chosen other providers over PayPal had nothing to do with their fees. I expect I'd pay 5% and shift all my existing business in a heartbeat, given a payment service that had:
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.
Sure. I was responding to "It surprises me that anybody uses Amazon or PayPal when Stripe and Balanced exist.", not attempting to make the argument "It surprises me that anybody uses Stripe or Balanced when Amazon and PayPal exist.". You are welcome to make the choices you want to make, and if Stripe actually manages to accomplish that first bullet point for your use case, that's awesome (seriously). However, treeface was making the argument that the opposite was not true: that working with PayPal and Amazon never made sense due to the offerings of Balanced and Stripe being somehow better; I was explaining (with a "FWIW" even) why companies would want to choose these solutions.
Apologies if I misunderstood your point. You seemed to emphasize fees above almost anything else in your earlier posts, including suggesting that this would probably be the deciding factor in a PayPal vs. Stripe choice at a certain price point. I was only trying to point out that for the kinds of small business that a lot of these payment services are chasing, the rate they charge isn't necessarily the only relevant factor, nor even the most important one.
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.)
You certainly don't do any real volume, because you can't pass 5% onto customers and if you absorbed it and did any real business it would be huge $$$.
Just curious, what do people do when part of their order can be shipped out now, and part of their order is being shipped by someone else in a different state and can't be shipped yet? And you might not know all this at the time of the order?
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.
You are going to hate me for this, but: I guess you switch to PayPal ;P. The DoCapture API has a field CompleteType that can be set to NotComplete (as opposed to Complete) that lets you implement partial capture functionality.
1) Use a payment processor that supports partial capture.
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.
> PayPal will offer the same service to you with "micropayments" pricing
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'll have to agree with this. Don't get me wrong PayPal is not great and the horror stories are well horrifying BUT it has a pretty global adoption and customers are fairly likely to know it.
In fact in Germany (which I think is one of the most "anti credit card" countries) I know many people that will only buy stuff online if they can pay via bank transfer or PayPal because PayPal is simple and has a recognizable brand name.
I own a CC but there have been times where I had checked out stuff and didn't buy in the end because it was CC only.
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.
I use both Amazon and PayPal but not Stripe or Balanced, mostly because I already have accounts set up with Amazon and PayPal. This is a huge barrier for new payment companies. To succeed, they need to both (1) be so much better than the competition that it's worth the hassle of making a new account and (2) communicate that to millions of people. These are not small problems.
I use Stripe for Draft, and I know I'm losing money. I get emails everyday from people outside the US who can't use a credit card or they don't trust any vendor with their CC. I'm probably going to have to add Paypal too :/
> I use Stripe for Draft, and I know I'm losing money. I get emails everyday from people outside the US who can't use a credit card or they don't trust any vendor with their CC.
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.
I am a developer, in Mexico. I have to jump through hurdles to pay some sites (Browserstack, dnsimple). I want to give you my money and even though I loathe PayPal it's the only solution that always works.
I agree with the other reply. Stripe would be ideal but when looking for international solutions, they just aren't there yet. We are looking into payment solutions to cover our LatAm customers and it is very difficult right now.
As a game developer who sells virtual goods, I don't care how hard it is to implement my payment solution. I care how easy it is for my users to use and how many will use it. Stripe claims they are easier to implement. I don't care. They have to show more people will buy if I use Stripe instead of PayPal and that just isn't true. PayPal has far more people who already have accounts and who just have to type in a pin or password to pay. Compared to typing in a whole card, the increased number of users who will buy is really big. Make your users have to do anything difficult and they just won't most of the time. That's the facts of life on mobile. They especially don't like to type.
> "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."
I would also happily believe that they just lost those engineers during 2010-2012; there was this massive deadzone during which improvements were not made to older products while new products were also not yet being released. The earliest documentation I can find for Amazon Payments Advanced (from a random S3 bucket that Google indexed for some reason) also has rather weird branding at the top, but that might just be their CMS solution?
I don't know about anyone else but I only ever use Amazon Payments in Cydia because of limitations in Cydia.
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.
Yay! In fact, PayPal now offers that same "leave details on file" feature, but an even more powerful version; I intend to have that integrated before I'd make drastic changes. (Also, of course, do something about the back grounding thing. Woah, and a really simple fix for that just hit me: almost all of the critical "let this background" requests come up while inside of the login and payment flow... I can easily make that part background!)
Awesome, that's great to hear. Nice to see you're still excited by the Cydia project. I've had gripes with it in the past but your enthusiasm gives me hope.
>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!
Humble Bundle started offering 'Pay with Amazon' a couple of years ago and it is very slowly expanding, in the UK at least.
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?
It looks like the distinction for this new service is that you get an API and can keep them on your site (without redirecting to amazon.com), so I'm thinking this is closer to Stripe than to PayPal.
Apparently sellers get your name, email address, and postal code as soon as you log in.
I'm Europe-based, I feel your pain. Every time I read about some new potentially awesome payment service, but only for the US-audience it consistently manages to make me grumpy all day thinking about all the lost business possibilities.
Random numbers are not that meaningful but the US has 300 million habitants, the EU 500 million. Comparing GDP the EU states grouped together are a bit less than a tenth bigger than the US.
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 ?
The EU has more people, but they're spread through 28 countries, each of which probably has different laws regulating financial transactions and payment processing, making it a lot more work.
From the little I know US has 51 states with each their little twist on different subjects like taxation or company laws. EU has a set of global rules, no trade barriers between the countries, and financial transactions and payment also should belong to a unified space thanks to the SEPA.
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.
Yeah, because without using amazon for payments you'd be completely safe with competing with amazon on a product by product basis on cost...
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.
Why would you voluntarily give Amazon all of your sales data? They'll aggregate it, mine it, then use it to optimize their store / pricing / products. At least with PayPal, I know they won't be using my sales data against me.
You didn't read what I said. If you're selling cheaper socks, you're going to lose to amazon and walmart. If you sell new innovative products, you aren't going to lose to them.
Also, with paypal, they get your sales data, sell it to others, AND then just keep your money and close your account.
This is going to be tough. A lot of merchants won't want a competitor (Amazon) to be anywhere near their site - especially at checkout. "Oh yeah, pay by Amazon. I wonder if they have this item cheaper there" Typically PayPal and Apple don't have that conflict
Can Amazon develop a "21st century" payment system for its associate affiliates that doesn't involve receiving checks 4 months later? It's such a ridiculously obsolete system for one of the biggest web/digital companies.
You think they are not technically savvy to understand that the system is obsolete. It is deliberate. They defer payments, so they can hold up the cash for a few weeks; This gives them a working cash-flow pipeline they can dip into. There is a technical term for it. Erudite folk on HN can throw more light on this practice.
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.
Most payment companies aren't able to (due to regulations) do anything particularly high-yield with funds they steward for their merchants. The amount of float a company like Amazon is able to make may factor into their revenue model, but I imagine they hold on to funds more for regulatory and risk mitigation reasons.
thanks for the links. I can't speculate at what their requirements are for affiliate payments. I only know the requirements Balanced is placed under as a PSP. I imagine Amazon must follow similar guidelines.
Yes, I get why they wait the first 2 months before they even send the money (Google waits 23 days), but it takes at least as much afterwards with the sending and processing of the check, which has nothing to do with Amazon. They get nothing out of that in terms of cashflow, since they've already sent the money after 2 months. But as I said, it takes another 2-3 months, before I can actually have that money (on top of Amazon's first 2 months).
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.
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).
Let's not forget about affiliate fraud and valid, legitimate refunds/returns/chargebacks. You really shouldn't get credit for your affiliate sales until Amazon is sure they're going to get to keep the money.
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...
Part of the waiting period is waiting to see if people return stuff. It's far easier to pay the correct amount 4 months later than to pay and then claw back payment (how?) when people return their purchases.
Yes that's anachronistic. As an Amazon Seller my receipts are disbursed directly into my bank account every two weeks ( though usually £0.00 as I only sell books casually ).
I wonder if there are tax / legal reasons why they don't do that with affiliates?
I really have no idea what this comment even means. The entire ordering and sign in pipeline has been https forever. Once you are on https it stays https until you explicitly got to http://, iirc. Lastly theres no content, that im aware of, that is available plaintext and not https.
A couple of years back I set up a payments system for a web application offering a choice of Amazon Payments, PayPal, or Google Checkout. Amazon was by far the easiest, best-documented API to work with. I think it would be best for everybody else if they became the dominant player in this space.
I'm afraid I don't own the IP and I've since changed employers. There are drop-in options (a brief search yielded fortune3.com, as an example), but I did not use any and can't really comment on them.
Do you really want Paypal completely ousted ? It seems to me that having viable competitors around is what's going to keep whoever's on top trying hard to keep customers happy.
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.
We're working on logins with payments for SASS apps at http://authic.com
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 think ultimately the big identity services will basically be how we pay for things on the internet. That's this Pay with Amazon one-click button, where pay with GMail will go, and what Facebook will eventually come to if they ever care about payments. This causes some problems as your accounts become all the more valuable, but why should I ever have to enter my credit card info on the web more than once?
This is a smart move (ignoring their half assed attempts earlier in their lives).
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.
Someone mentioned that this doesn't support purchasing of digital products/services, so if when you write "Subscriptions" you mean "SASS app subscriptions" I think the answer is no. (Happy to be corrected)
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
So is this just an few-click OAuth thing? Click the button on a 3rd party website, and if you're logged in to Amazon, they send over your details, charge you, and you're done?
How do I (the seller) get my money? I didn't see anything about their sending regular payments to my business' bank account (but I may have missed it).
I have bad experiences with Amazon, so I don't think I would ever use this service.
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.
Amazon is a big company with a lot of customers, so even if it's not that exciting as a product in and of itself, it has the possibility to be a big player. I actually use their payment system for LiberWriter, and since my customers have to sign up with them anyway, it's perfect. Also, they're pretty pleasant to deal with, by and large.
It's pretty significant when a top player does a 'me too' product. For one, amazon is providing more validation AND competition to the login and payment infrastructure area. I'm sure many entrepreneurial devs will find this interesting.
The difference is subtle. Currently, social companies like Facebook offer login/identify services, and different companies like PayPal offer payment. But do consumers trust Facebook for anything other than social (like shopping)?
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.
https://payments.amazon.com/business/pricingPlan