Accepting Samsung Pay as a merchant

Samsung Pay is a tokenised wallet on Samsung devices. Like the other device wallets, it sits on top of the card networks: the customer’s card number never reaches you, a device token does, and the transaction still runs through your existing acquiring relationship.

Acceptance

How to accept Samsung Pay as a merchant

You do not integrate a new payment method in any meaningful sense. Acceptance follows from accepting contactless cards at the terminal and from wallet support in your online checkout through your PSP. In practice most merchants already accept it without having made a decision about it, which is fine, but it means nobody has looked at what it costs.

A wallet adds a party, it does not remove interchange

This is the structural point that applies across every device wallet. Underneath, the transaction remains a card transaction carrying card economics, with a wallet layer added on top. Whether the total is competitive depends on how that layer was priced in your agreement and whether the card cost beneath it is passed through or absorbed into a blend. Under blended pricing the two are indistinguishable, which suits exactly one party.

Tokens

Tokenisation changes fraud and authorisation, not just security

Device tokens generally authorise better than keyed card entry, and depending on the network and region they can shift fraud liability from the merchant to the issuer. Both effects carry money. Whether your PSP reports which transactions qualified is a question worth asking, because the answer affects your chargeback line rather than your fee line.

Blend

The wallet is the best argument you have against a blend

The section above says that under blended pricing the wallet layer and the card cost beneath it are indistinguishable, which suits exactly one party. That is usually where the conversation stops. It does not have to, because a wallet hands you a test that a card on its own does not.

Ask for one month of wallet transactions and one month of contactless card transactions from the same acquiring line, matched on similar ticket sizes, and compare the effective rate on each. If the two are identical to the basis point, the wallet layer is inside the blend and you are paying an amount nobody in the building can state. If they differ, the difference is the wallet layer, and it now has a number, which is the first moment it can be argued about at all.

That test is also the cleanest case for interchange plus plus pricing you will ever have to hand, because it makes the argument with your own data rather than in the abstract. A structure that shows interchange, scheme fees and your provider’s margin as three separate figures answers the question permanently, and wallet volume is where the difference between the two structures is easiest to see.

Which payment provider supports Samsung Pay?

Datatrans, Braintree and Online Payment Platform all document Samsung Pay, as do most other providers. The useful questions are what you pay on wallet volume, whether the underlying card cost is visible, how wallet transactions authorise against your card average, and whether liability shift eligibility is reported to you at all.

Parity

Device parity, and the gap it exposes

Samsung Pay is available on Samsung devices, which means its share of your revenue is not a question of customer preference in the abstract. It is a function of your own traffic mix, and you already hold that number.

Put two figures side by side. From your analytics, the share of sessions on Android devices. From your payments reporting, the share of revenue on each wallet. Take 6 million euros of revenue with 35 per cent of sessions on Android, so roughly 2.1 million euros of Android-originated revenue. If Apple Pay carries 22 per cent of your iOS revenue while the Android wallets together carry 2 per cent of your Android revenue, that gap is not preference. It is availability, or ordering in the selector, or a wallet that fails quietly on those devices and sends the customer to manual card entry.

Twenty points of 2.1 million euros is roughly 420,000 euros a year currently going through keyed entry that could go through a token. What that is worth comes from two numbers in your own reporting rather than from anybody’s deck: the authorisation rate on tokenised transactions against keyed entry, and the fraud write-off on each. A two-point authorisation difference on 420,000 euros is 8,400 euros of attempted revenue a year, and offering a customer the wallet their device already carries costs nothing to fix.

Reviewing what card acceptance costs you

What you pay is set in your acquiring contract, not by the scheme. Start by establishing whether you are overpaying your PSP, or look at what payment performance optimisation does to authorisation rate and cardmix, which is where a wallet earns or costs you money.

Relevant markets: global