This also opens up the door to more secure payments. The "basic card" handler is one where the browser might just store your raw card number. But you can imagine that your bank might implement a payment handler that requires you to enter a 2fa code before using your card.

When it comes down to it, a credit card number is kind of serving double as a username and password for online payments right now. This new API has the potential to significantly improve upon the security of raw PANs.

Just a clarification, a credit card number is an iin, pan, and checksum.

http://jimkeener.com/posts/everyday-numbers-1

Interesting that the post says the term BIN (vs. IIN) isn't commonly used anymore, but it's practically the only thing I've heard them called in the last 10+ years of ecomm dev.

I've seen both. When I wrote the post all the docs from the gateways I had access to called then iin with a historical note on bin. I done have access to those docs anymore though.

I've seen both. When I wrote the post all the docs from the gateways I had access to called it the iin with a historical note on bin. I don't have access to those docs anymore, though.

Edit: I really need to check when posting from my phone

I don't doubt you, but as an example, the recent notification of BIN/IIN prefix additions for Mastercard uses BIN 19 times and IIN 2 times.

https://www.mastercard.us/en-us/issuers/get-support/2-series...

Interesting, maybe I should update that page then.

That would be welcome. Half of the payment process on websites don't survive an adblocker and blocking third party cookies.

Maybe this helps too:

https://developers.google.com/web/fundamentals/discovery-and...