How Payments Actually Work

Most software platforms touch payments every day without ever seeing the machinery underneath. A customer taps a card, the charge clears, money lands in a bank account, and it feels like one instant event. It isn't. Behind that tap is a chain of companies, each taking a small cut, running on rules most people never read.

You don't need to become a payments company to benefit from understanding this. But if payments run through your software, the economics of that chain are partly your economics, whether you take part in them or hand them away. What follows is a plain walk through how the money moves, who gets paid along the way, and where a software platform fits.

The four-party model

Almost every card transaction runs on what the industry calls the four-party model. The four parties are the cardholder, the merchant, the issuer, and the acquirer, with a card network like Visa or Mastercard in the middle holding it together.

The cardholder is the customer paying for something. The merchant is the business getting paid. The issuer is the cardholder's bank, the one that gave them the card and that fronts or guarantees the money. The acquirer is the merchant's bank, the institution that accepts the card for the merchant and makes sure funds reach the merchant's account.

The merchant only ever talks to its acquirer. The cardholder only ever talks to their issuer. The two banks never deal with each other directly. The card network connects them and plays referee, setting the rules and routing the messages. That separation is the point. Banks compete to issue cards to consumers, acquirers compete to win merchant business, and one shared network lets any card work at any merchant.

Follow the money

When a card is tapped, two things happen, and they are not the same thing.

First is authorization. In a second or two, the request travels from the merchant through the acquirer to the network to the issuer, which checks the account for funds, fraud signals, and limits, then sends back an approve or a decline. Nothing has moved yet. The issuer has only promised the money is good.

Then comes clearing and settlement, usually batched at the end of the day. This is when the money actually changes hands. The issuer pays the acquirer, the acquirer pays the merchant, and the network reconciles who owes what. That gap between authorization and settlement is why a refund can feel instant to you but take days to show up on a customer's statement, and why a hotel can place a hold at check-in and capture a different amount at checkout.

Who takes a cut

The price a merchant pays to accept a card is bundled into the merchant discount: the difference between the sticker price of the sale and what actually lands in the merchant's account. That discount splits three ways.

The biggest piece is interchange, which flows from the acquirer to the issuer on every transaction. The issuer carries most of the risk, since it fronted the money and eats the loss on fraud or a dispute, so interchange is its compensation. The card network sets interchange, not the issuer, and the rate moves with card type, how the card was entered, and the merchant's category. A rewards credit card keyed in over the phone costs far more than a debit card tapped in person.

The second piece is the network assessment, sometimes called the scheme fee. That is Visa's or Mastercard's own cut for running the rails and the rulebook. Smaller than interchange, but it is the network's direct revenue.

The third piece is the processor and acquirer markup. This is the part that is actually negotiable, and it is where most of the competition and most of the confusion live. Interchange and assessments are the same for everyone. The markup on top is where one provider's pricing differs from another's, and where bundled, opaque pricing hides how much a merchant is really paying.

The supporting cast

A few more players sit in the flow and are worth naming, because the marketing around payments tends to blur them together. The gateway is the technology that captures card details and passes them securely into the system, the on-ramp. The processor handles the back-end communication with the networks, moving authorization and settlement messages. The acquirer, again, is the licensed bank that holds the merchant relationship and the risk. One company often wears several of these hats at once, which is why the labels get muddy.

Where software platforms have historically fit

For most of the last two decades, a software platform that wanted payments inside its product had two realistic options, and both had a ceiling.

The first was the referral, often through an Independent Sales Organization, or ISO. The platform points its customers at a processor, the processor signs and underwrites each merchant, and the platform collects a thin referral cut, usually a handful of basis points. The processor owns the merchant, the experience, and the economics. The platform is a lead source.

The second was to do it yourself and become a full payment facilitator. Historically that meant registering with the card networks, putting up serious capital, building underwriting and compliance and risk operations, and waiting a year or more to go live. The reward was real ownership of the payment experience and the revenue. The cost of entry kept almost everyone out.

The PayFac model and what changed

The payment facilitator, or PayFac, model rewired the merchant side of this. Instead of every business getting its own dedicated merchant account, a PayFac holds one master account and onboards each business as a sub-merchant underneath it. The PayFac handles the application, the underwriting, and the compliance itself, which is why a new merchant can go from sign-up to accepting payments in minutes instead of the days or weeks an ISO referral takes. In exchange, the PayFac takes on the underwriting and the risk the processor used to hold.

That model has grown fast. Payment facilitators are on track to process well over four trillion dollars in gross payment volume, and the embedded payments market sat around twenty-five billion dollars in 2024, projected to compound at roughly thirty percent a year into the early 2030s.

What's genuinely new is PayFac-as-a-Service. It gives a software platform the ownership and economics of the PayFac model without the registration, the capital, or the year of build. A licensed partner carries the heavy compliance and risk obligations, while the platform keeps brand ownership, pricing control, and the margin on volume that used to be handed away. A multi-year, million-dollar project collapses into weeks.

What this means for your platform

The practical part is simple. Your customers already pay the merchant discount on every transaction they run through your software. That money is already leaving their accounts. The only open question is who collects the markup on top of interchange and assessments: an outside processor you referred them to, or you.

Under the old referral math, you earned a few basis points and someone else owned the relationship. Under a managed PayFac model, the same volume can return many times more, because you keep the markup instead of forwarding it. On real volume, that is the difference between payments being a rounding error and payments being one of your largest revenue lines.

You no longer have to build a bank to get there. You do have to decide whether the payments already moving through your product are something you take part in or something you keep giving away.