Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Amex for Developers

developer.americanexpress.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: Amex for Developers

#81

Post by moduspwnens14 »

repomies691 wrote: post #75
spotman wrote: post #54

Earlier quoted context omitted.

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…

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.

Re: Amex for Developers

#82

Post by sschueller »

WhitneyLand wrote: post #5

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 Goog…

They may be late but this is probably not good for stripe and co. AMEX, VISA/MC etc are essentially able to cut out the middleman (Stripe).

Re: Amex for Developers

#83

Post by bpicolo »

Shanea93 wrote: post #27
vitobeto wrote: post #9

On the landing page you may see a computer screen with PHP code, but they just offer JAVA and .NET SDK right now, fun fact!

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 SQ…

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.

Re: Amex for Developers

#84

Post by moduspwnens14 »

Imagine this potential future with me.

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).

Re: Amex for Developers

#85

Post by wil421 »

enra wrote: post #6
OliverJones wrote: post #4

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. T…

One benefit can be that you access / pay with Amex points, which I think Stripe doesn't offer. 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.

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.

Re: Amex for Developers

#86

Post by guitarbill »

grabeh wrote: post #77
guitarbill wrote: post #70

Earlier quoted context omitted.

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. [0] e.g. http://search.theregister.co.uk/?q=rbs

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.

Re: Amex for Developers

#87

Post by ChemicalWarfare »

WhitneyLand wrote: post #62
ChemicalWarfare wrote: post #31

Earlier quoted context omitted.

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.

Re: Amex for Developers

#88

Post by ChemicalWarfare »

Zelphyr wrote: post #23
WhitneyLand wrote: post #5

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 Goog…

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 exac…

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.

Re: Amex for Developers

#89

Post by VT_Drew »

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).

Re: Amex for Developers

#90

Post by ryan-c »

muninn_ wrote: post #69
ryan-c wrote: post #42

Earlier quoted context omitted.

Salary + health care + payroll taxes + equipment + space + other overhead, etc.

As a general rule of thumb a full time employee costs a company twice their salary.

I've heard that as well, but didn't want to dig up a citation.
Post reply on HN