[niftich]

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.

[master5o1]

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.

[rubyfan]

Right, it's not a choice of picking MasterCard's one API vs. Stripe (as an example)

It's Stripe vs. implementing 10ish card or payment APIs. The choice is easy and will continue to be for most consumer facing scenarios.

[throwanem]

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.