The developer blog and portal of Mastercard, covering its APIs for payments, fraud scoring, blockchain and billing, plus a post on why it avoids OAuth 2.0.
HN commenters mention it as Mastercard's API program, noting that production access requires being a verified partner or sponsored, and praise its hackathons and sample ideas.
This isn't new and has existed for nearly 20 years. Visa's implementation is called VAU (Visa Account Updater[1]) and Mastercard's is ABU (Automatic Billing Updater[2]).
Issuers (banks) have to provide the details of these new cards to Visa/Mastercard, and the systems are certainly capable of updating the details of debit cards. It sounds like TD had a bug where they sent updates for cards which they shouldn't have. ie: TD broke their own rule about only enrolling credit cards.
Card details which do not automatically update are really frustrating for customers – especially on services like Uber. In nearly all cases the customer is going to go and give the merchant their new card details anyway. My understanding is that if card is compromised (as opposed to being lost) then banks should not provide the new details. There isn't really much _additional_ privacy or security risk here beyond those posed by merchants/acquirers holding onto card details already – provided banks do it right.
Though zooming out a little, long-lived payment tokens shared among every merchant a user shops with being the way things are still done is crazy. How long it has took to roll out EMV (chip cards), especially in the US, shows how hard it is to effect change in vast, three+ sided marketplaces like card networks.
[1] https://developer.visa.com/capabilities/vau
[2] https://developer.mastercard.com/product/automatic-billing-updater
Disclosure: I work for a bank.
No, on all of timelines, finality, and who makes the final call. You're making very confident statements about a complicated process you don't seem to know all that much of.
> After a week, if the merchant doesn't object, the funds are released to the issuing bank. [...] it's ultimately the issuing bank (i.e. the customer's) that makes the final call
The funds are moved immediately, but within a given timeframe (depending on the network, but usually much more than a single week), the merchant has the option of clawing them back once again. That's called a "second presentment" (see for example [1] or [2]).
The issuer then has the option to submit a second chargeback if they still believe they are in the right, and depending on the type of chargeback, the acquirer (and by extension merchant) might get one more chance to send yet another response. If they are still disagreeing at the end of these steps, the case can be brought to the network, which then makes a final ruling, but that's very expensive (and the losing party pays), so it's usually avoided.
The money moves from issuer to acquirer and back for all of these steps. Only if the issuer makes the last move, and the acquirer does not challenge it, is the chargeback considered "won". All of that is usually hidden from at least cardholders via the provisional credit mechanism mentioned above.
In any case, your assertion that the issuing bank has the last word is simply not true.
[1]…
Visa® Account Updater for Merchants exists precisely for this reason:
https://developer.visa.com/capabilities/vau
https://developer.mastercard.com/product/automatic-billing-updater-abu/
https://stripe.com/resources/more/what-is-a-card-account-updater-what-businesses-need-to-know
I'm super annoyed by any hosting or telco provider that has failed to implement it, I think it amounts to negligence, especially if they stop and completely erase your entire portfolio only a couple of days after payment failure, which some officially do.
I lost my Online.net Scaleway test servers this way, because they have failed to implement the updater. Of course, their support will always blame the customer.
BTW, these Account Updaters are also the reason why changing a card number will not prevent any recurring charges, either; it's by design.
I can confirm that Amazon Prime, Visible and 123-Reg have no issues with VAU and equivalents. Your monthly Amazon Prime in the US will continue getting billed to an expired credit card without any issues, for example. Same with Visible and even the annual renewals on 123-Reg. They all don't show the new card in the interface, and still DO issue warnings that the card is expired, yet, on the billing date, it all just bills as if nothing has happened.
T-Mobile US may lack support, and Callcentric, Hetzner and Online.net, don't seem to implement an Account Updater, either, not sure about OVH.
It really depends on who you are sending money to. Assuming your sending to people with bank accounts a remittance service would work, like transfer-to (recently renamed Thunes) [1] and EMQ (sea only) [4]. There are several services like this, and its how mobile wallets and remittance agents (electronic ones) send cash. You may need several to provide maximum coverage if operating globally.
Each country also has their own remittance providers [2] so if you are serving a specific country it would be worth digging to find out who has the best APIs. Mastercard has a service [3] that supports 80 countries but your recipients require a card. Note if your recipient is a business with an EDC machine there is a nifty way to send them cash using MC VCNs (what some global hotel booking sites use).
Most remittance providers now send to wallets in addition to bank accounts, which can be used to send cash to non-banked users. Though in practice this could be a pain for them and coverage is limited and the mobile wallets vary in quality and KYC restrictions.
1. https://www.thunes.com/
2. Only use licensed ones! Spotted this one operating in us: https://www.dwolla.com/
3. https://developer.mastercard.com/product/mastercard-send
4. https://www.emq.com/
> Payment failure
Visa now has Visa Account Updater [1], and Mastercard has Mastercard Automatic Billing Updater [2]. It looks like American Express has their own too [3].
If one configures some form of automatic payment on their cards (AutoPay in the US; direct debits or GIRO in other parts of the world), along with using a "wallet" comprising multiple cards or bank accounts like PayPal [4] — it feels like paying for services would go on for longer than expected.
[1] https://usa.visa.com/dam/VCOM/download/merchants/visa-account-updater-product-information-fact-sheet-for-merchants.pdf
[2] https://developer.mastercard.com/product/automatic-billing-updater-abu/
[3] https://www.godaddy.com/help/about-credit-card-account-updater-programs-7334
[4] PayPal's more than happy to also take money from your bank accounts without your consent if your cards fail, if you have the accounts added, just to keep your bills paid.
On technical level - nothing. Thing is, that payment card is basically private key, that's derived from master key controlled by the bank. This key signs your transactions. Tokenization adds some extra steps (eg. single use keys), but it's fundamentally the same.
What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.
If you want to go deeper into this rabbit hole I can recommend two sources:
* https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization
* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.
If you ever decide to try - ping me, I happen to know a few guys there :-)