Merchant Authentication

Merchant authentication is the process by which a merchant, or the software acting for it, proves its identity to a payment gateway, processor, acquirer or card network before submitting payments, issuing refunds or reading account data. Every request a merchant's system sends, whether to authorise a card, capture funds or check a transaction, is accepted only if it carries valid merchant credentials. Without this control, anyone who discovered the gateway's address could send fraudulent charges or refunds in the merchant's name.

Merchant authentication should not be confused with cardholder authentication, which checks that the person paying is the genuine cardholder. The two often happen in the same transaction: the merchant's system authenticates itself to the gateway, and the cardholder is authenticated by the issuer through methods such as 3-D Secure. The phrase is also used informally for the steps a merchant takes to verify its own customers, but in payments infrastructure it normally means authenticating the merchant itself.

Payment providers use a range of methods, often in combination:

• API keys and secrets. Most modern gateways issue each merchant a pair of keys for its application programming interface: a publishable key used in the browser or app, and a secret key used only on the merchant's servers.
• Merchant identifiers and passwords. Older gateways and terminals identify the merchant by a merchant identification number and terminal ID, combined with a password or transaction key.
• Digital certificates. High-volume merchants and payment facilitators may connect using a digital certificate, sometimes with mutual authentication, so that both sides of the connection prove who they are.
• Signed requests and tokens. Some providers require each request to be signed with a private key or use short-lived access tokens, so a captured request cannot simply be replayed.
• Webhook verification. When the gateway sends notifications back to the merchant, it signs them so the merchant can confirm they are genuine.

All of these are sent over encrypted connections using Transport Layer Security.

In online card payments, the merchant must also be identified to the card networks for authentication programmes. Under 3-D Secure 2, the merchant's 3DS server sends the merchant name, acquirer details and merchant identifiers to the network's directory server, which checks that the merchant is enrolled through a participating acquirer before passing the request to the issuer. Accurate merchant data allows the issuer to assess risk and show the cardholder a recognisable merchant name. In some programmes, networks and issuers allow trusted merchants or wallets to perform delegated authentication of the cardholder, which depends on strong assurance about the merchant's own identity and controls.

Because merchant credentials effectively act as the keys to a merchant's revenue, providers and card industry standards recommend several practices. Secret keys should be stored in secure vaults or environment settings, never in website code, mobile apps or public code repositories. Keys should have the minimum permissions needed, for example separating keys that can issue refunds from those that only create payments. They should be changed regularly and immediately after staff leave or a leak is suspected, following a key rotation policy. Access to the merchant's online dashboard should be protected with multi-factor authentication.

Gateways add their own protections, such as allowing requests only from registered server addresses, limiting the rate of requests and alerting merchants to unusual activity. These measures fall within wider payment application security requirements.

Stolen merchant credentials can be used in several ways. Criminals may issue refunds to their own cards, run card testing attacks through the merchant's account, or extract transaction data. Leaked API keys found in public code repositories are a recurring cause of losses. A compromised merchant account can also lead to chargebacks, scheme fines and the loss of acquiring services. For payment facilitators and platforms that act for many sub-merchants, a single compromised platform credential can affect thousands of businesses, which is why such platforms are held to higher authentication standards by their acquirers.

In shops, terminals authenticate to the acquirer's host rather than relying on keys typed in by staff. Each terminal is registered to a specific merchant and terminal ID, and encryption keys loaded into it during secure set-up let the host recognise genuine terminals. A terminal that has been stolen or tampered with can be disabled remotely, so that it can no longer send transactions in the merchant's name.