Wow, talk about too little too late. This kind of late to the party strategy is why startups will always be needed to lead innovation.
The irony is the highest ranking person at AmEx who really understands this is probably a pretty smart guy who had to fight and lobby for years to rally enough support to make this happen.
edit: Its worse than I thought. A quick search shows they brought in high level talent from Google, Amazon, etc. I'm willing to bet these guys pitched some cool ideas before leaving frustrated after their short tenures.
I've heard how Amex can be from a friend who has them as a client. They refuse to let her host their instance of her product on AWS because Amex's security team supposedly hasn't vetted AWS yet. This despite the kinds of customers Amazon already hosts on AWS (the CIA comes to mind). Not to mention that she has several other very large banks as clients that don't have a problem at all being hosted on AWS. Or that exactly zero of the data she deals with is in any way related to sensitive customer data because the product is used by Amex's marketing department.
As an Amex customer I'm glad to know they have strict requirements but the fact is, they're shunning a massive cloud infrastructure service like AWS over a piddly little local co-locted hosting company.
This is the story of many "enterprise" companies sadly. Some I work for, and while they are slowly changing, I would not say their own data centers (yes, read: data centers) are "little co-located hosting" companies. Usually they are entire departments, with entire budgets and multiple facilities, with many peoples jobs within that.
So while for the developer, moving things to AWS is a no-brainer, a time-saver, and a money-saver to the company, the amount of politics, and change, is so large these behemoths of companies are the last to consider it.
Security is a valid piece, but also a political move to keep the money from changing hands too rapidly.
"But where labor efficiency is greater than [400 VMs per engineer], OpenStack becomes more financially attractive. In fact, past this tipping point, all private cloud options are cheaper than both public cloud and managed private cloud options."
This study does ignore the services supplied on top of basic compute, however.
Disregarding cost (haha) is OpenStack actually attractive to use? I was under the impression it was a bit of a bear to deploy and operate (my previous employer gave up, though I strongly suspect the project was never resourced properly in the first place).
Hmm. I've heard that also with AWS you can collect quite hefty bills easily. In fact I've heard stories that some startups have failed or had lots of problems because they've been using AWS too carelessly.
Certainly, although that's bound to happen with anything that offers easy scaling. If you put your build artifacts on S3, it just works... all the way up into petabytes. You skip all the intermediate steps you'd otherwise have (like having to get purchase orders signed for petabytes worth of hard drives).
Also, in AWS' defense, you won't hear stories about startups using them and having expensive developers sitting on their hands waiting for hardware. Probably a lot of startups only start (or get funding) because of the low barrier to entry AWS provides.
I'm pretty sure Amazon built an isolated region specifically for sensitive government workloads. I don't think public cloud security or regulatory compliance is a given even though the workloads you talk about seem fine for it.
As I understand it there are actually two Us government AWS clouds. GovCloud is for ITAR-regulated stuff that can still connect to the public internet (non-classified or confidential). The CIA stuff is hosted in a separate airgapped facility (called C2S) for the US Intelligence Community with connections to various airgapped networks. One can get their software listed in the marketplace for either or both, but to get listed in the latter you have to do a bunch of extra work.
I work in finance and this is frustrating for sure. Unfortunately if Netflix loses account data who cares. But if we lose customer account data it's off to the races to see how much money regulators can drum out of us for not being secure enough. Even if that isn't a real threat, it's a real fear. Now I'm not arguing for or against regulation here, but just you wait until Mint.com or one of these new investment apps get hacked and watch what happens.
I'm going to call BS. At least in the UK banks screw up all the time and never get more than a slap on the wrist. The mobile apps put out are hilariously insecure and get hacked. Payment processors go down. [0]
Often, it seems like the only defence is that skiddies don't have a clue about mainframes that's saving these idiots.
Service failure and data breach are two separate matters. If a UK bank were to suffer a major breach they would be fined heavily by the ICO. Right now limits are at £500k but with the new General Data Protection Regulation potential fine levels will increase steeply...
What, like TalkTalk? Or the police for that matter, who routinely lose sensitive information.
I agree, as long as fines are lower than the CEOs salary + bonuses, these "fines" remain laughable. But based on these other cases, it's unlikely that the ICO would or could do anything to severely impact how a bank operates, which makes them toothless.
As for telling the ICO, well the deputy director of the National Cyber Security Centre (NCSC, part of GCHQ) explicitly said he won't tell ICO if people report breaches to him... so I wouldn't cross my fingers.
I know the lawyer who likely makes those kinds of calls for Amex. Let's just say he's not someone I would hire. It's generally a really bad place in my experience, which is from a number of angles and timeframes. I left them as a customer years ago after getting a glimpse of what's happening inside.
Not just Amex, I work for HSBC in investments. I've been desperately fighting to get even access to AWS as I need to run some machine learning GPU instances and would also love to have a much better server environment for some of my other internal apps here (which are shockingly supported by our outsourced, under-resourced and utterly useless IT function)...
Unfortunately, even though my department are more than happy to budget any money for AWS, IT, Internal Security, Risk etc. are all blocking the path saying they haven't vetted or onboarded Amazon, and that they're working on their own internal cloud so that we can do similar things (I've tried this "internal cloud", it's beyond useless. Slow and locked down more than guantanamo so you can't actually do anything with it).
Payment processing industry is very heavily regulated, moving your infrastructure to a new solution is extremely costly from the audit/compliance perspective and in some cases it's downright impossible to move to "the cloud" because of the physical access restrictions etc. To my knowledge all of the big boys - V, MC, AmEx, Discover host their own infrastructure (or partner with certified data centers).
That "piddly little local co-locted hosting company" (whoever they are) is subject to some pretty intense level of scrutiny and has to pass gazillions of tests outside of your normal hosting SLA stuff just to claim that they are compliant.
> They refuse to let her host their instance of her product on AWS because Amex's security team supposedly hasn't vetted AWS yet. This despite the kinds of customers Amazon already hosts on AWS (the CIA comes to mind).
From my dealings with pharma companies, I will point out one thing.
For things where they have to follow regulations around privacy, they won't let you host your software on AWS for them to use.
They will have their in house team set up your software on AWS for them to use.
Setting it up themselves allows them to guarantee all the regulatory requirements are being met. The CIA isn't using Joe Schmoe's amazon instance, they spin up their own machines and install the software there.
Well, they aren't THAT late :)
Visa, for example launched something like this just few months back.
I'm also not sure what kind of impact these APIs have in the "real world", I'd venture to guess vast majority of the merchants is sticking with one-stop-shop payment processors instead of switching to point-to-point integrations with card networks.
Stripe was founded in 2011. Regardless of whether or not AmEx sees Stripe as a competitor/threat, they wasted 5 years not building out similar tech after the blueprint was laid out at their feet.
Payment processors like First Data and Cybersource have had these types of APIs available to their merchants since the late 90s actually.
Since you mentioned Stripe - they are actually one of the cheapest options to process AmEx, depending on the volumes and CC/Debit breakdown even cheaper then going through AmEx directly in some cases.
So again this is more of a business driver vs. the available tech thing.
At first, it's just Amex. Then, to remain competitive, other major card vendors do something similar. Most of us (developers) still use something like Stripe for simplicity, but libraries start popping up that abstract away the vendor-specific APIs and make it easy to use them.
Long term, though, as more and more payments are handled electronically and online, this opens the door for a more competitive credit card market. Now, to compete with Visa or Mastercard, all I need is to get my API into those popular libraries and merchants can accept my card just as easily as theirs--except I charge a lower rate.
You'll start seeing cards that are virtual only--allowing them to cut fees below what companies handling physical cards can do. With the payment process being decentralized, now even requiring a card number is unnecessary. Users specify the ways they'd like to pay for things in their payment client (browser? phone?) and this is negotiated behind the scenes with the payment types the merchant will accept.
Users and merchants can directly decide between more traditional payment means (centralized / fiat currency) and upcoming ones (decentralized / cryptocurrency). The limiting factor is no longer what the PoS (point of service) machine will accept, but what the popular payment processing libraries support (and the merchant has configured them to allow).
I don't expect we'll see Visa or Mastercard do this, but this could be a key first step toward a more competitive payment processing market (which has had the same entrenched players for decades).
Visa/Mastercard may well be forced to try something like this in order to survive. Banks are opening up their own API's for P2P payments (at least within the EU due to legislation). This could completely negate the need for intermediate "payment networks" (except the following).
However - I don't think you'll see a proliferation of new payment methods. The biggest problem here would be fraud mitigation, so it'd need to be a payment provider the merchant deems trustworthy enough.
Interesting times ahead. Amex are just doing the bare minimum to keep up here.
I'll play devils advocate. If your Netflix and this direct Amex integration saves you 1/2 percent per transaction that makes a <strike>huge</strike> difference to your bottom line.
Netflix current subscribers 83 million and average revenue per subscriber per month is $10.32.
$83M * $10.32 = $857M total revenue per month.
Assume 10% of transactions are Amex. $857M * .10 = $86M per month.
Finally 1/2 percent of $86M is a savings $430,000 per month.
UPDATE: I originally thought it was a savings of $430,000 a year, but it is actually a savings of $430,000 a month.
ORIGINAL: I think I just talked myself out of my own argument. That $430,000 savings is basically the cost of one Netflix engineer. The technical debt to maintain separate Amex billing easily would exceed $430,000 a year.
why does the "cost of an engineer" continue to keep going massively up whenever these comparisons are made?
$430k? are netflix engineers that special?
glassdoor shows sr engineers around $200k - i can't tell if they're including stock/bonus in that or not. Range start in $120k range. Yes, taxes, yes benefits, but... $430k?
I'm pretty sure at this scale they are not getting standard rates for all of their payments. Actually I know that for a fact (Amex is a customer of mine).
430k a month is not "<strike>huge</strike>", it is a modest sum at best, and for 5m USD a year you can bet your bottom dollar that Visa/Mastercard will match/beat Amex. This is definitely not enough money for a big entity like Netflix to consider a strategic relationship which might subvert existential relationships.
Visa/MasterCard won't beat Amex for Amex cards. Amex can charge whatever they want because they completely own the card network (as opposed to transactions going through the traditional traditional interchange for Visa and MasterCard). Because of that you have to work with them to accept Amex cards, and while an acquirer can help, the only real way to save on fees is to work directly with Amex.
Hmm. For the typical card-not-present (online) use case, stripe.com and paypal do a pretty darn good job of processing AMEX payment cards, as well as the others.
Tokenization is vital in this age of cybermiscreants. Ya don't want customer payment card data in your dbms.
The stripe.com API offers tokenization, and it offers the ability to send and validate data like zip/postcode, cvv and street address to cut fraud. They have an api for chargeback disputes, too. (The business I serve doesn't use it, instead we use the forms on their web site. We have dozens of disputes per decade, not worth programming.)
Squareup.com (Square) does a good job with card-present transactions.
And these service providers offer predictable processing fees.
I wonder what's special about the AMEX APIs? Maybe somebody from AMEX can explain? Some of us are always looking for better ways to serve customers and handle payments efficiently.
I booked some museum visits in Italy this past summer. On a few of the sites I'd be sent to AMEX and enter some verification codes before the payment would process.
Never seen it in the US but it would be nice. I feel more comfortable going directly to AMEX first. Some website payment systems are shady feeling.
A SaaS business I know of switched TO stripe.com from a more traditional processor / acquirer scheme for payment card processing, and saved a bundle. The traditional scheme had several layers of fees; the payment processor and then Visa / MC / AMEX, then the bank. Different card flavors (rewards cards, etc) offered different fee levels. Predicting fee levels was a probabilistic task.
Switching to Stripe, they got a two-tier one layer fee scheme. One tier for AMEX and a lower tier for MC/VISA.
The fee burden was noticeably lower with Stripe, too. the business I mention requested a fee discount and got it based on annual volume. But it was cheaper even without the discount.
Not sure why this is downvoted, but it's a fair point. I know of a small business with a lot of subscriptions and this became a big issue for them when provider quality declined.
It's tempting to think this ship has already sailed and they're late to the party, but I'm actually more concerned.
Recently, we saw MasterCard announcing APIs; ultimately the card issuers are the real gatekeepers of their own data and their own integrations, and as more of them move to gain the control back that they ceded with their lack of public developer engagement, the role of payment processors becomes less clear.
Sure, for the near future, a payment processor can continue to abstract away from the actual card issuer; but as richer APIs surface, those may siphon away marketshare from payment processors.
Developers are still more likely to implement the one API that provides n payment methods than implement n APIs to get n payment methods.
That is, a payment processor like Stripe that provides AMEX, MC, Bitcoin or what ever is often more valuable than by being able to reduce complexity in the integration of services.
One quibble: MasterCard and Visa are associations, not issuers. (AmEx is sort of both - iPhone to Visa's and MasterCard's Android.)
I don't know that processors have a lot to worry about here. It's been a few years since I was in the space, but from a dev perspective, there'd have to be some really compelling reasons to implement (and pay fees for!) an integration per card type, rather than one integration for all payment cards.
Less than 10% of our customers pay with Amex. Can someone shed some light on why a developer would implement this for Amex payments vs just using Stripe, Auth.net or another payment gateway that supports Amex?
I am trying to understand the value here and how this will benefit the developer and/or consumer.
It's probably cheaper. If it saves you 1/2% it may be worth it if you're doing >$1mil.
(Note that I have no idea how much cheaper it is because they don't seem to have prices anywhere. Which makes me irrationally angry and looking forward to their all-but-inevitable demise over the next decade).
I would bet it's more expensive than Stripe. AmEX is known for being much more expensive than Visa and MC, and I wouldn't be surprised if Stripe loses money on every AmEx transaction (but makes it up on other cards).
The Pay With Points feature could be interesting, allowing customers to buy products online using their Amex Membership Rewards points. I didn't see if it was possible to implement just that without also implementing the other payments processing.
To be honest, that code is pretty bad anyway. "If an arbitrary attribute table doesn't exist, ignore this row and process the next one", no exceptions thrown, no attempt to rectify the situation, no logging, no state change, just ignore it. I can't really think of a situation where you both don't care and don't want to know if your transaction completes.
That aside, this actually looks like it might even contain a SQL injection vulnerability. I'm no Drupal 7 expert (which this code seems to be) but having looked in to the code being ran here, db_table_exists seems to call down to `$this->connection->queryRange("SELECT 1 FROM {" . $table . "}", 0, 1);` in `DatabaseSchema_mysql::tableExists`, which contains an unescaped PDO query. I feel like anyone running this code is going to have a very bad day and it makes me untrusting of the rest of the work they're putting out.
I LOVE going around to websites and seeing their stock images for code. It's usually insanely unrelated, e.g. hadoop vendors with some random HTML/CSS pictures.
IDK, I've used Amex in Australia for >50% of my credit card spend. All major supermarkets, department stores, most petrol stations and fast food chains accept it. I assume outside of those categories it really depends where you are though - the cafe across the road from my office accepts Amex with no surcharge and no minimum, but I'm in CBR in the heart of public service territory, so...
Most merchants that also accept AMEX have a little sticker in their window. There are actually a lot more businesses that allow you to use an AMEX without a surcharge than there used to be: https://maps.americanexpress.com/aushopsmall#/
If you get time to watch the cycle of logos on the Paypass terminal while you're waiting, it will usually display whether it accepts Amex or not (and also logos now for Apple Pay & Android Pay too).
Checking out on Delta via my Delta AmEx allows me to simply login to my AmEx account (saved via a password manager) and checkout without entering my actual card info. The convenience factor there is definitely nice.
Depending on what they mean by "Customized Experience", and what data does this allow access to, it may mean better integration with a number of consumer finance apps, such as Mint, YNAB, etc. Doesn't seem like it from the description in the website, though.
Generally, our public APIs follow a standard set of best practices:
- All APIs follow REST principles.
- JSON is the standard payload. Some APIs may include additional formats such as XML and in such cases media type headers are used to specify your preference.
- Due to the sensitive nature of most data that is exchanged with American Express, you will commonly find HTTP POST methods used where you may expect to find either GET or DELETE methods used. The primary purpose is to prevent sensitive search criteria from being used in the Query string, moving it instead to the Body.
----------------
So they claim to be RESTful yet not support GET or DELETE calls. Do they even realize what they are saying?
This seems neat but not what I was expecting. I am writing a small django app to track my finances. This is just an app I am writing for myself to use personally. I would love to be able to get transactions directly from a credit card, I know it is possible there are other services (like mint.com) that can do it. Can anyone point me the right direction? If could get my Amex transactions as json or xml that would be great. As a personal project I wouldn't be willing to spend much money to get access to an API like what I am describing (if fees are associated with it).
This is interesting, but if you need card present payments and EMV, something like CardFlight's SDK https://cardflight.com/sdk/ is going to be a better fit.
Disclaimer: My friend works there and has told me all about it.
So can someone explain to me why one would use amex over stripe or braintree? Or why would one use mastercard's API or Visa's? They all have similar APIs right?
The biggest reason would be price. I don't know the amex payment pricing or how it differs from stripe/braintree, but cutting out the middle man has got to be cheaper.
I run a small business using stripe and cc processing fees are a big hit. The service and support is amazing and it's so easy to use, but it's not cheap. They charge the same for every card type when the card providers charge in-person merchants much different (and lower) rates.
Are you doing card-not-present? That's going to be a fee hit over card-present regardless of processor.
If you're doing card-present, look into traditional acquirers and also chip-and-PIN. You'll pay considerably more up front, but less over time due to the fee difference, and you'll also no longer need to sweat being on the wrong end of the EMV liability shift.
AMEX is closed loop network. The advantage possibly would be huge troves of data about customer spending habits, if they expose those in future(obviously without PII)
The irony is the highest ranking person at AmEx who really understands this is probably a pretty smart guy who had to fight and lobby for years to rally enough support to make this happen.
edit: Its worse than I thought. A quick search shows they brought in high level talent from Google, Amazon, etc. I'm willing to bet these guys pitched some cool ideas before leaving frustrated after their short tenures.