Who’s who in a card payment

The short version

Every card payment has two sides. The issuer stands behind the cardholder, and the acquirer stands behind the merchant. The card scheme connects them and sets the rules.

Processors, PSPs and payment facilitators run the technology and sign up merchants. These names describe roles, not companies, and one company often holds several.

For anyone building on payments, the key question is not “which provider?” but “who holds each role?”

1. Four parties, one network

Almost every card payment in Europe follows the four-party model. The cardholder and the merchant each have their own institution: the issuer on one side, the acquirer on the other. Visa, Mastercard or a domestic scheme connects the two. Around this core, PSPs and payment facilitators sign up merchants and provide the technology.

Figure 1. Each role has its own contract and its own part of the fee.

In the three-party model (classic American Express or Diners Club), the scheme is the issuer and the acquirer at the same time. Today these schemes also work with partner banks in many markets, so the line is less sharp than it used to be.

2. The six roles at a glance

Two words need care. “Processor” is often used for any company that “processes payments”, so ask whether it holds the licence or only runs the systems. “PSP” is also a legal term in the EU’s Payment Services Directive (PSD2), where it covers every licensed payment provider, issuers and acquirers included.

3. One tap, step by step

Each role acts at a different moment. The numbers below match Figure 2.

Figure 2. Messages move in seconds. Money follows later.

1. Tap. The terminal or SoftPOS app reads the card and sends the encrypted data to the PSP.
2. Request. The PSP passes it to the acquirer. The acquirer, or its processor, sends it through the card scheme to the issuer.
3. Decision. The issuer checks the card, the available funds, the authentication (PIN, phone biometrics or 3-D Secure online) and its fraud signals.
4. Answer. “Approved” or “Declined” travels back the same way, in about two seconds.
5. Clearing. Later that day, the acquirer sends the final transaction records through the scheme. Fees are calculated.
6. Settlement. The issuer pays the acquirer €50, minus interchange and scheme fees.
7. Payout. The acquirer or PSP pays the merchant, minus the acquiring fee, usually one or two working days later.

The fees themselves are explained in part 01 of this series.

4. Who pays when something goes wrong

The roles show their real weight in a dispute. A cardholder who doesn’t recognise a payment, or never received the goods, complains to the issuer. The dispute (a chargeback) then travels through the scheme and the acquirer to the merchant, under the scheme’s rules.

Figure 3. The acquirer always answers to the scheme, so it sits at the end of the line.

If the merchant loses the dispute but has gone out of business, someone else must pay. A payment facilitator pays first for its sub-merchants. The acquirer pays if the PayFac can’t. That is why acquirers and PayFacs check businesses before signing them (KYC, “know your customer”), monitor them afterwards and sometimes hold a reserve.

5. Same roles, different companies

The roles are fixed, but how they are split between companies is not. Three set-ups cover most of the market:

Figure 4. The company the merchant signs with is highlighted.

• A. PSP with a partner acquirer. The PSP runs the technology and the relationship. A licensed partner holds the scheme membership and often the funds. It is quick to launch and can cover many countries through the partner.
• B. Acquiring PSP. One company is PSP, acquirer and usually processor. Decisions are faster and there are fewer handovers.
• C. Payment facilitator. A marketplace or software platform signs up its own users as sub-merchants. It is the step from “we refer our customers to a PSP” to “payments are part of our product”. In Europe, holding sub-merchants’ funds generally needs a payment institution or e-money licence, or a licensed partner that holds them. Take legal advice early.

Some of the names you will meet in Europe, many of them in more than one role:

6. Six questions before you sign

1. Who is the acquirer of record? Its rules and risk appetite shape your merchants’ experience.
2. Who signs and checks your merchants, and how fast?
3. Who holds the money between payment and payout? This affects payout timing, reserves and what happens if a partner fails.
4. Who handles chargebacks, and who pays if a merchant can’t?
5. Who is responsible for security and certification? For terminals and SoftPOS apps, ask which parts of the card data path are PCI-certified, and by whom.
6. Who do you call when payments fail? One contact who can see the whole chain is worth more than it looks on a pricing sheet.

7. Where Tapaya fits

Tapaya sits on the merchant’s side of the map. Integrators, POS providers and payment providers use it to build card acceptance into the devices and apps their customers already use.

• Any Android phone becomes a terminal. SoftPOS turns an NFC-enabled Android phone or tablet into a contactless terminal, with no extra hardware.
• One partner for every channel. SoftPOS SDK in your app, terminals and online payments, on one platform. The SDK and APIs are documented at docs.tapaya.com.
• Live in days, not months. Short integration means lower set-up costs and earlier revenue.
• Pricing that fits your model. IC++, blended or a mix, matched to how you sell to your merchants.
• Local details built in. Fiscalisation in Czechia and Slovakia, tipping and fast merchant onboarding.
• Across Europe, with people you can reach. You talk directly to the team that builds the product.

When we start with a new partner, we draw this map together. If you’d like to see it for your platform, we’ll draw it with you. Developers can start straight away in the Tapaya documentation.

Glossary