Wallets beyond Apple Pay and Google Pay

Apple Pay and Google Pay are card wallets: they present a tokenised version of a card the customer already has, over the same contactless interface your terminal already reads. Nothing extra is required on your side. The wallets that need a decision are the other kind — apps backed by a balance, a bank link, or a separate network, which reach a physical counter through a QR code, a card product, or an integration with your point-of-sale.

The question to ask about any of them is the same: how does the money get to my bank account, and what happens when something goes wrong.

Which ones actually work at a counter?

Broadly three shapes. Apps that issue a physical or virtual card, which you accept exactly like any other card and often cannot distinguish from one. Apps that present a QR code, which need either a static code or an integration. And apps that plug into specific point-of-sale platforms, which work if your platform is on the list and do not exist for you if it is not.

The first shape requires nothing of you and is how most of these reach small stores in practice.

What should you check before agreeing to accept one?

Settlement timing, fees, dispute process, and what happens if the provider decides to hold funds. Card processing is heavily standardised; these are not, and the variation between providers is large.

Pay particular attention to the dispute question. Card networks have decades of established rules and a defined process. A balance-based app may have a support queue and a policy page, which is a very different thing to rely on when a few hundred dollars is in question.

Is a separate app worth the counter complexity?

Usually only when customers are asking for it specifically. Every additional acceptance method adds a settlement schedule to reconcile, a statement to read, a support number to find and a thing for cashiers to learn.

A useful test: if fewer than one customer a day asks, the reconciliation cost probably exceeds the sales. If several do, and they are the customers you want, it is worth a look.

How do these differ from a card at the terminal?

In where the money sits before it reaches you. A card transaction settles through a regulated chain into your merchant account. A balance-based app may hold funds in an account belonging to the provider until you move them, which is a different arrangement with different risks.

That is not a reason to avoid them. It is a reason to move balances to your bank regularly rather than letting them accumulate, and to know whose balance sheet your money is on.

What about customers who ask for a person-to-person transfer?

Be careful. Accepting a personal transfer app as a store payment method usually falls outside the provider's business terms, offers you no seller protection, and gives you no record that reconciles to a sale.

It also tends to arrive at the moment when a customer's card has declined, which is not the moment to accept a payment method with no recourse. A store that wants to accept an app should accept its business product deliberately, not its personal one by improvisation.

What is the safe default?

Accept contactless properly and you have already covered the great majority of phone payments, because card wallets present as contactless cards. Add anything beyond that on evidence — a count of how many people asked, over a month — rather than on a sales conversation.

The mobile payment landscape changes faster than terminal hardware does, which is another argument for a default that does not need updating.