The Acquiring Contract

Behind every transaction lies a silent agreement between the merchant and their acquiring bank — the acquiring contract. It's the legal and commercial framework that defines how payments are processed, what they cost, and when the merchant gets paid.

At first glance, it looks simple: "We pay X % per transaction". But behind that neat line sit risk models, scheme rules, and long negotiations over who carries what liability. The contract governs the entire relationship: how refunds work, how disputes are handled, what data is exchanged, and how settlement happens.

What an Acquiring Contract Actually Covers

At its core, the contract covers four dimensions:

• Commercial terms — pricing model, settlement currency, payout schedule, and reserve (if any).
• Operational details — how transactions are submitted, captured, refunded, and reconciled.
• Risk and compliance — chargeback handling, PCI DSS obligations, KYC requirements, and anti-money-laundering clauses.
• Termination and liability — what happens if the merchant breaches rules or stops trading.

For smaller businesses, these details are often hidden inside standard PSP terms and conditions. For large enterprises, they're carefully negotiated — every percentage point matters when you process billions.

Negotiating the Deal

When volumes grow, merchants start negotiating. They compare multiple acquirers, benchmark fees, and push for volume-based discounts. Rates depend on:

• Processing volume and average ticket size — more transactions usually mean better pricing.
• Risk profile and business model — travel, gambling, and crypto are high-risk, hence higher fees and rolling reserves.
• Regions and card mix — domestic debit is cheap; cross-border premium credit is not.
• Integration model — direct acquiring relationships often get better economics than aggregator setups.

In continental Europe, you might still hear the term Disagio — the traditional German word for the acquirer's commission. It's the percentage difference between what the consumer pays and what the merchant receives, covering interchange, scheme fees, and acquirer margin. Modern contracts just call it "merchant service charge", but the logic is the same: the Disagio is where the acquirer earns their living.

The Blended Model

The blended pricing model wraps everything: interchange, scheme fees, and acquirer margin — into a single, all-inclusive rate. As an example, a merchant might have a contract where they pay 2.9% flat + CHF 0.30 per transaction. This means every card payment costs exactly that rate, regardless of whether it's a domestic debit card or an international premium credit card.

Blended pricing is designed for simplicity. You always know what you'll pay, which makes forecasting easy and reconciliation straightforward. It's especially common with PSPs or aggregators serving small to mid-size businesses. Think of Stripe, Square, or SumUp.

But simplicity has a price. Since the rate averages multiple cost types, merchants often end up overpaying on low-cost transactions to offset high-cost ones. You also lose visibility into what portion of the fee goes to the card issuer, the scheme, or your acquirer. In short: easy to understand, but not necessarily the best value for high volumes or mixed traffic.

The Interchange++ (IC++) Model

Interchange++ breaks that single rate into its real components:

• Interchange fee: goes to the issuing bank.
• Scheme fee: goes to the card network (Visa, Mastercard, etc.).
• Acquirer margin: goes to your acquiring bank or PSP.

Each transaction is priced based on its actual characteristics: card type, region, and processing method. Example: Interchange (0.3%) + Scheme (0.2%) + Acquirer (0.25%) → Total: 0.75% for that specific transaction.

This structure is transparent and fair, since you see the real breakdown of costs. Larger or cross-border merchants prefer IC++ because it allows them to analyze payment mix, negotiate margins, and optimize routing. The downside? It's way more complex. Costs fluctuate depending on the cards customers use, and reconciliation requires careful reporting. Honestly, it's a wild ride if you want to understand the full nature of IC++. You can almost doctorate in that topic alone.