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.
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.
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.
Here it is: https://aws.amazon.com/govcloud-us/
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).
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.
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.
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.
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).
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.
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.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.
$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?
Big assumption. Amex is not commonly used outside the US. I reckon you could safely cut that to 5%, if not less.
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.
Also I've seen Amex offer login/auth verification, where you a service can verify you as the actual Amex user, and possibly trust you more that way.
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.
The only people I've ever met that recommend Stripe are developers.
The only people I'd recommend Square to are merchants whose avg ticket is less than $5 or are borderline hobbyists.
The number of hardcore PP users has dropped significantly in the last 5 years, in my experience, to less than 10%.
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.
So, where are the lower fees?
s/tokenization/lockin/ # devil's advocate
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.
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.
It's Stripe vs. implementing 10ish card or payment APIs. The choice is easy and will continue to be for most consumer facing scenarios.
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.
I am trying to understand the value here and how this will benefit the developer and/or consumer.
(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).
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.
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?
Perhaps a better heading is called for there.
> passionate American Express developers who are adding new code regularly.
Disclaimer: My friend works there and has told me all about it.
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.
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.
WhitneyLand is correct.