Your merchants are asking for it. Somewhere in your base, a merchant just got a competitor's invoice that added three percent for paying by card, did the math on their own processing bill, and emailed your support team to ask why your platform cannot do the same. Multiply that by a few hundred merchants and surcharging stops being a feature request and starts being a retention question.
For the merchant, surcharging is simple: pass the card fee to the customer who chose to pay by card, and keep more of the sale. For the platform sitting underneath them, it is not simple at all. Surcharging is one of the most heavily regulated things you can switch on in a payments program, the rules differ by card network and by state, and most of the compliance risk lands on whoever configured it. That is usually you. This piece is what a software platform actually takes on when it offers surcharging, and how to think about whether it is worth it.
Why a platform should care at all
Surcharging is rarely a revenue line for the platform itself. The fee offsets the merchant's cost of acceptance, so the money mostly moves from cardholder to merchant, not to you. The reason to care is what it does to the two numbers that actually drive a platform payments program: retention and attach.
A merchant who keeps an extra two or three percent of card volume is a merchant who is materially better off on your platform than off it. That is the cleanest retention lever in embedded payments, and it costs you a configuration, not a discount. It is also an activation lever. Merchants who were sitting on the sidelines of your payments product because the rate felt high will turn it on once the rate effectively goes to zero for them. If you have read the merchant activation playbook, surcharging is one of the few features that moves the activation number and the retention number at the same time. That is why it is worth the compliance load, when it is worth it.
The trap is treating it as a pure win. Offered badly, surcharging generates chargebacks, angry cardholders and in a few states a legal problem, and every one of those routes back to your support queue and your risk exposure, not the merchant's. The value is real and so is the downside. The job is to capture the first without the second.
What surcharging actually is, and what it is not
Three things get lumped together and they are not the same.
A surcharge is an added fee on credit card transactions specifically. It is capped, it has to be registered with the card networks, and it follows a detailed rulebook. A convenience fee is a flat charge for using an alternative payment channel, like paying online instead of in person, and it lives under different rules entirely. Cash discounting flips the framing: the posted price is the card price, and customers who pay cash get a discount, which sidesteps most surcharge rules but changes how every price on the merchant's site or invoice has to be displayed. Platforms reach for cash discounting precisely because it avoids the surcharge rulebook, but it carries its own disclosure burden and is easy to implement in a way that quietly breaks network rules.
If you are building a feature, you are almost always building surcharging in the strict sense, which means you are signing up for the strict rulebook. The rest of this piece is that rulebook, in the form a platform has to operationalize it.
The compliance traps, in the order they bite
None of these are exotic. They are the standard requirements, and platforms miss them because the demo makes surcharging look like a percentage field.
The caps, and the "lesser of" rule
Visa caps credit card surcharges at 3 percent. Mastercard caps at 4 percent. But the cap that actually binds is the one underneath both: a surcharge can never exceed the merchant's real cost of acceptance. If a merchant's effective rate is 2.6 percent, the most they can surcharge is 2.6 percent, not 3. That means your system has to know each merchant's actual cost, per merchant, and enforce the lower number automatically. A flat "3 percent surcharge" toggle that ignores the merchant's true rate is a compliance violation waiting for an audit.
Debit and prepaid are off limits
You cannot surcharge debit or prepaid cards, ever, even when a customer runs a debit card as credit. That requires real-time card-type detection at the point of payment, and getting it wrong is one of the fastest ways to generate both a regulatory problem and a wave of disputes. This is a build requirement, not a policy line in a contract.
Registration and notice
Before a merchant surcharges a single transaction, the surcharging entity has to give its acquirer, and through them the card networks, advance notice, typically 30 days. In a platform model, the question of who registers, you or each merchant, is not a detail. It shapes whether you can turn this on for your base centrally or whether every merchant has to file on their own, and the answer depends on your processor and your model.
Disclosure
The surcharge has to be disclosed clearly at the point of entry, at the point of sale, and itemized as a separate line on the receipt. In an embedded checkout that you control, the disclosure is your UI problem to solve correctly, in every flow, including the ones your merchants build on top of your API.
The state patchwork
Surcharging is permitted in most states, but a handful ban it outright and a few cap it below the network limit, as low as 1 to 2 percent, and that list moves by legislation and by court decision rather than staying put. For a platform with merchants in many states, that is not a one-time legal review. It is a per-state configuration that has to be maintained as the law changes, which is exactly the kind of ongoing burden a single merchant can ignore and a platform serving thousands cannot.
Who owns what
This is the part that separates a platform decision from a merchant one. When a single merchant surcharges, they own their own compliance. When you offer surcharging as a platform feature, you are building the mechanism that hundreds of merchants rely on, and the failures are systemic. If your cap logic is wrong, it is wrong for everyone. If your debit detection misfires, it misfires at scale. If a state changes its rules and your configuration lags, every merchant in that state is now out of compliance through no action of their own.
That is the real cost, and it does not appear in the feature spec. It is the cost of carrying the rulebook on behalf of your base: the engineering to enforce caps and card types correctly, the legal monitoring to keep state configuration current, the support load when a cardholder disputes a surcharge, and the share of chargeback risk that follows. Whether you take that on, or push it down to merchants, or lean on your processor to carry it, is a genuine strategic choice and it depends heavily on your model and your appetite. It is also the kind of cost that belongs in the same conversation as the rest of what embedded payments actually cost and the broader question of how SaaS platforms make money from payments, because surcharging changes the economics for your merchants without obviously changing them for you.
Surcharging moves the activation number and the retention number at the same time. It also moves the compliance risk onto whoever built it. For a platform, that is you.
So should you offer it?
The honest answer is the one I give every platform that asks: it depends. It depends on where your merchants are, how your processor handles registration, whether your checkout can enforce caps and card types correctly, and how much compliance load you are willing to carry to win the retention. For a platform with merchants concentrated in surcharge-friendly states, a processor that registers centrally, and a checkout you fully control, it can be one of the highest-leverage features you ship this year. For a platform with a fifty-state footprint, merchant-built checkout flows, and a thin risk function, it can be a liability you turned on by accident.
The framework is the same one any platform can use: weigh the retention and activation upside against the engineering, legal and risk load of carrying the rulebook for your base, and configure for the worst case, not the demo. Where your specific platform lands on that, and how to roll it out without lighting up your support queue or your risk exposure, is the part that only resolves against your actual merchant base and model. If you are weighing surcharging right now, that is the conversation worth having before you build it. Reach out and we will work through yours.