from Hacker News

Amex for Developers

by titomc on 10/18/16, 10:57 PM with 86 comments

  • by WhitneyLand on 10/19/16, 12:42 AM

    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.

  • by moduspwnens14 on 10/19/16, 1:29 PM

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

  • by nodesocket on 10/19/16, 3:30 AM

    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.

  • by OliverJones on 10/19/16, 12:40 AM

    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.

  • by niftich on 10/19/16, 1:03 AM

    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.

  • by 20years on 10/19/16, 1:37 AM

    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.

  • by vitobeto on 10/19/16, 12:46 AM

    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!

  • by locusm on 10/19/16, 2:02 AM

    AMEX in Australia: Maybe 1 in 10 merchants even accept it, for that 1 you pay a much higher surcharge.

  • by kkirsche on 10/19/16, 12:26 AM

    It's interesting for sure, but as a consumer rather than a business, is there a use case for this?

  • by emodendroket on 10/19/16, 3:09 AM

    Gotta try and make those lost Costco bucks somehow.

  • by reubano on 10/20/16, 7:00 AM

    API Standard Practices

    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?

  • by VT_Drew on 10/19/16, 2:53 PM

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

  • by rubyfan on 10/19/16, 11:56 AM

    "Data Intelligence" is an ATM locator. This is not my idea of Data Intelligence.

    Perhaps a better heading is called for there.

  • by OJFord on 10/19/16, 7:22 AM

        > passionate American Express developers who are adding new code regularly.
    "adding new code"

  • by programminggeek on 10/19/16, 3:06 AM

    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.

  • by brianbreslin on 10/19/16, 1:56 AM

    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?

  • by arenaninja on 10/19/16, 12:12 PM

    Slightly off-topic, but what a strong week for PHP -- the code in the Mac image is PHP code

  • by princetontiger on 10/19/16, 12:44 AM

    This is hilarious. 20 years late? Nothing to see here, move along.

    WhitneyLand is correct.