Thread

Banks and Credit Unions to Team Up Against Apple Pay Fees

127 points · 133 comments · Brajeshwar

havaloc · 1790442549 · focus · HN ↗
I get why the banks are not happy, but I can tell them that I am not going to use Chase Wallet, Bank of America Wallet, Citi Wallet...just pay the fee and be thankful for the reduced payment friction, which they invariably make money from. PS: Nobody is going to use Paze (yet another half baked wallet), other than to collect the free $10 to sign up for it.
Somewhat related, even Walmart relented and now supports Apple Pay/Contactless. Every big merchant has now relented (Kroger, Home Depot, Walmart).
1. syvolt · 1790444937 · focus · HN ↗
  Or Apple Pay can just be like Google Wallet is on Android? The alternative is not multiple apps.
  1. add-sub-mul-div · 1790448179 · focus · HN ↗
    Another alternative (in the US, at least) is tapping a piece of plastic instead of your phone and not inviting any of the tech giants into your transactions at all. What an unforced error, to shovel more of your data at them needlessly.
    Elfener · 1790448444 · focus · HN ↗
    That is much better, but you're still paying visa/mastercard some percentage fee for a service which should be provided by e.g. the central bank.
    MBCook · 1790451957 · focus · HN ↗
    Yeah. But this is the US. This is all we’ve got. Having the central bank do it would be communism, and that’s bad. I learned about it from Saturday morning cartoons.
    AnthonyMouse · 1790454691 · focus · HN ↗
    Ironically it's the central bank (and associated regulations) that cause these intermediaries to exist to begin with.
    A protocol to support decentralized payments is a hobby project for an individual. You give each institution an identifier (e.g. their domain name) and each institution gives each customer an account number. If you're account 123 at Chase then you sign in as #123@chase.com, tell Chase you want to send $5 to #456@bankofamerica.com, they send the money and Bank of America tells their customer they have a new deposit. If you want to collect money from someone, you tell your bank to send their bank a payment request and they can either approve it manually (e.g. so you can deliver the goods for a one-time purchase) or configure some rules for which accounts get approved automatically up to some threshold amount (e.g. for recurring payments). Also no reason for banks in different countries not to all support the same protocol.
    That doesn't require a central bank or any centralized third party payments intermediary. All it requires is for banks to know how to send money to other banks, which they obviously already do and the specific implementation of that isn't even relevant to the customer-facing payments protocol. So how does this not exist? It can't be that no one wants it, so it's got to be that someone (e.g. Visa/MasterCard) doesn't want it.
    fragmede · 1790455346 · focus · HN ↗
    The banks all got together and created Zelle, so it exists. No Visa/Mastercard conspiracy needed.
    AnthonyMouse · 1790456278 · focus · HN ↗
    Zelle is an app rather than a protocol, which is why e.g. PoS terminals and web checkouts don't support it.
    notpushkin · 1790457324 · focus · HN ↗
    Zelle, from my understanding, is a “protocol” – many banks support it in their own apps. (Scare quotes because I’m not entirely sure it’s a proper well-defined protocol.)
    And there’s nothing preventing PoS from supporting individual wallet apps – see e.g. WeChat Pay / Alipay in China. (Alipay+ is also a “protocol”, i.e. other banks and wallets support it.)
    AnthonyMouse · 1790491623 · focus · HN ↗
    What I mean by protocol is that there is an RFC or equivalent and anyone who implements the spec and has a bank account can then talk to their bank using the standardized protocol. If that exists for Zelle then where's the spec?
    fragmede · 1790545239 · focus · HN ↗
    <a href="https://api.payments.jackhenry.com/docs/zelle/overview/" rel="nofollow">https://api.payments.jackhenry.com/docs/zelle/overview/ Is a white label api that you, as a bank, can implement/hit. Just like your local small business vendor can choose to also take Venmo and CashApp, they can also choose to take Zelle. I've bought a burrito with Zelle before.
    AnthonyMouse · 1790760824 · focus · HN ↗
    That seems to be the protocol that banks use to talk to other banks. The missing piece is the protocol for merchants to use to talk to their own bank (regardless of which bank it is), so that support can be added into generic point of sale terminals or web shopping carts etc.
    Having the merchant manually process every payment using the bank-specific app on their personal phone isn't it.
    notpushkin · 1790772657 · focus · HN ↗
    > so that support can be added into generic point of sale terminals or web shopping carts etc
    We don’t have a single protocol for acquiring (online) card payments either, and this hasn’t been an issue. Everything just uses plugins or custom integrations.
    Not sure about in-person payments. From my experience, banks program their own firmware into the terminal, but it may support some standardized API over USB / Serial. Even then, any given bank can implement some subset of features, and supports only a bunch of models (so if you decide to switch banks and your terminal isn’t “blessed”, you’ll have to buy a new one; thankfully, they’re fairly cheap used).
    It’d be nice to have a unified protocol for all payment types IMO, but I’m not sure that’s realistic. Some Chinese payment processors have something like that, with a couple Alipay gateways emulating one protocol established by another gateway, so you can just swap out the API endpoint in case you want to switch. But even that’s just for the simplest case (you have to redirect the user to the processor’s page).

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.