Deciding that dual pricing makes sense for your business is the easy part. The rollout is where the actual questions come up: what has to change at the register, what you're required to disclose, and how to introduce it without it landing on customers as a surprise price hike.
Here's what implementation actually looks like, start to finish.
What has to change at the point of sale
Dual pricing requires your POS system or terminal to be programmed to display two prices, the cash price and the card price, at the point of sale, not calculated after the fact. This isn't a setting you flip yourself in most cases; it's a configuration step your processor handles as part of setup, and it needs to be done correctly before you go live, not discovered as broken on day one.
Depending on your current system, this can mean a straightforward reprogramming or, in some cases, updated terminal software or hardware. Either way, this is a "before you flip the switch" step, not something to sort out after customers start seeing dual pricing at checkout.
Signage and disclosure
Compliance isn't optional here, and it isn't complicated either. It's about making sure customers know what they're going to pay before they pay it. That generally means:
Signage at the point of sale, visible before a customer commits to a purchase, showing that a price difference applies based on payment method
Both prices reflected clearly on the printed or digital receipt
Consistent application. Every customer sees the same structure, every time, not a discretionary discount handed out selectively
Get the disclosure right and dual pricing is fully compliant and unremarkable. Get it wrong (vague signage, no receipt disclosure, inconsistent application) and you've created real exposure instead of savings.
One detail that trips up implementation more than people expect: surcharging and dual pricing aren't the same thing, and the rules for each treat debit differently. Card network rules ban surcharging on debit cards outright, there's no cap to negotiate, it's simply not allowed, and cap credit card surcharges at whichever is lower: 3%, or the merchant's actual cost of acceptance. Dual pricing, because it's structured as a cash discount rather than a card fee, doesn't run into that wall, which is exactly why it can apply across your whole customer base, debit included, where surcharging can't. This is exactly why terminal programming needs to be done by someone who understands the distinction: a generic setup that treats every card the same can create a compliance gap without anyone realizing it until a network flags it.
Customer communication
The rollout that goes smoothly is the one where customers don't feel surprised. A few things that make the difference:
Timing. Announce the change before it happens, not the moment someone's standing at the register with two prices in front of them for the first time.
In-store messaging. A simple sign or note explaining that the business now reflects card processing costs in pricing, with a cash discount available, goes a long way toward framing this as normal rather than a targeted price increase.
Staff readiness. Your team needs a simple, consistent explanation they can give without hesitation. The explanation itself is short, "we offer a discount for cash" covers most of it, but someone has to be ready to say it confidently the first time a customer asks.
The businesses that get pushback on dual pricing are usually the ones that didn't prepare staff or didn't say anything ahead of time. The mechanics are the same either way; the experience for the customer is very different.
Week one, realistically
Even a well-planned rollout has a few bumps in the first week. The most common ones:
A confused customer who didn't see the signage and asks why the price is different than expected. This is a staff-readiness issue, not a system failure. A quick, calm explanation usually resolves it on the spot.
A mis-programmed terminal showing the wrong price on one item or category. This gets caught fast if someone's specifically checking transactions against expected totals during the first few days, and it's a quick fix once flagged.
A regular customer who's used to paying by card and isn't thrilled about the change. This is the moment staff readiness matters most. A short, friendly explanation almost always de-escalates it.
None of this is unusual, and none of it means the program isn't working. It means the first week needs a little extra attention before things settle into a routine.
Who does what
Your processor handles the technical setup: terminal programming, compliant signage templates, and making sure the pricing structure meets card network rules and any state-specific requirements. What falls on you is the customer-facing side: choosing your announcement timing, briefing your staff, and putting up the signage your processor provides somewhere customers will actually see it before they check out.
Neither side of that can skip the other. A perfectly programmed terminal with no signage is a compliance problem. Great signage with a mis-programmed terminal is a customer complaint waiting to happen.
Where this fits for you
If you've decided dual pricing makes sense and you're not sure what the actual rollout looks like for your specific setup, I'm happy to walk through it: the technical steps, the compliance requirements, and a realistic timeline for going live.
Reach out directly: diane@fraiettafinancialgroup.com | fraiettafinancialgroup.com
