Skip to main content
Merchant SupportAgent Login
AMP Payment Systems
Menu

Verification-sensitive guide

Dual Pricing vs. Cash Discount

Distinguish two posted prices from a genuine reduction to a regular posted price, and verify the real checkout behavior instead of relying on program labels.

Author
Organization author.
Review status
Primary sources checked; no legal or compliance review is claimed. Current network, provider, and jurisdiction requirements must be verified before use.
Published
Last reviewed

Direct answer

Dual pricing generally presents a card price and a lower cash price before the customer chooses how to pay. A cash discount generally starts with a genuine regular posted price and reduces that price for cash. Labels do not control the result: signage, shelf or menu prices, terminal logic, receipt presentation, debit handling, advertising, and staff explanations must match the actual program. These structures can implicate network, processor, consumer-disclosure, tax, and jurisdiction-specific requirements. This guide does not conclude that either structure is lawful for a particular merchant. Obtain a written program design, identify every payment method’s treatment, and verify current requirements with the processor, applicable networks, and qualified local advisers before launch.

Map the customer journey

Photograph or mock up every price display: website, menu board, shelf label, invoice, estimate, entrance sign, checkout screen, and receipt. Write the amount a customer sees at each stage for cash, credit, signature debit, PIN debit, prepaid, gift card, mobile wallet, and split tender. Confirm whether taxes and tips are calculated consistently and whether refunds return the amount actually paid. Ask whether the terminal identifies the funding type reliably and what happens offline. Staff should describe the two amounts factually and never improvise claims such as “the bank requires this fee.” Review advertising so a lower cash price is not presented as the only price if a different card price is routinely charged. Recheck after menu, catalog, tax, or software changes.

Price-display example

A merchant wants to receive $100 before tax. One proposed display shows “Cash $100.00 / Card $103.00” at the point where the customer chooses. Another displays only $100.00 and adds $3.00 after a card is presented. Those are materially different customer experiences even if a vendor gives both the same marketing name. If a genuine regular price is $103.00 and an eligible cash customer receives a $3.00 reduction, the receipt and refund logic should reflect that sequence. This arithmetic does not establish compliance, the permitted amount, or correct tax treatment. The merchant must test every tender, confirm debit and prepaid handling, and obtain advice on price display, receipts, taxes, and local restrictions.

Build a topic-specific comparison

For cash and card price presentation across the customer journey, compare like with like and retain the evidence behind every score. Collect photographs of advertised and posted prices from the operating business, label its date and owner, and note whether it represents a fact, requirement, assumption, or unresolved dependency. Compare terminal configuration under the same locations, channels, volume period, user roles, and exception conditions; reject a demonstration that changes the scenario between providers. Define an acceptance result for receipt samples, identify which document or reproducible test proves it, and record limitations instead of reducing the result to yes or no. Ask who supplies, configures, bills, supports, and can change refund behavior; preserve the answer with the controlling proposal or agreement rather than relying on a meeting note. Test every tender type with ordinary and difficult cases from this business, including a correction or failure path, so the comparison reflects daily work instead of a sales script. Score online checkout separately for current fit, implementation effort, continuing ownership, and exit risk; a strong feature can still create an unacceptable operational dependency. Collect tax treatment from the operating business, label its date and owner, and note whether it represents a fact, requirement, assumption, or unresolved dependency. Compare approved staff language under the same locations, channels, volume period, user roles, and exception conditions; reject a demonstration that changes the scenario between providers.

Calculate the relevant costs

The cost model for cash and card price presentation across the customer journey should expose dollars, timing, uncertainty, and operational effort. Quantify menu or catalog updates as one-time, recurring, usage-based, loss-related, or internal labor, and state the time period and transaction assumptions behind the amount. Model signage at low, expected, and stressed activity, because a fixed monthly price and a per-event price behave differently as volume changes. Trace terminal programming to a proposal line, contract term, invoice, operating record, or documented estimate; leave it marked unknown when the evidence is incomplete. Identify which party controls payment expense that remains, what can trigger a change, whether notice is required, and whether the expense continues during migration or termination. Measure customer-service time separately from revenue or gross payment volume so a percentage headline does not hide dollars, staff effort, customer loss, or cash-flow timing. Reconcile actual refunds after launch to the approved model, investigate the variance, and update the forecast without retroactively changing the original assumptions. Quantify tax configuration as one-time, recurring, usage-based, loss-related, or internal labor, and state the time period and transaction assumptions behind the amount. Model software subscriptions at low, expected, and stressed activity, because a fixed monthly price and a per-event price behave differently as volume changes. Trace monitoring for display drift to a proposal line, contract term, invoice, operating record, or documented estimate; leave it marked unknown when the evidence is incomplete.

Common mistakes

Use these failure patterns as review prompts, then document the control or owner that addresses each one.

  • Trusting a vendor’s program name without testing checkout behavior.
  • Showing one advertised price and revealing another only after tender can create avoidable customer and compliance risk.
  • Treating debit like credit because the card carries a network brand can conflict with applicable program rules.
  • Failing to update online menus, delivery listings, shelf labels, and receipts creates inconsistent disclosure.
  • Describing shifted costs as free processing is inaccurate because the business still bears software, hardware, operational, refund, and other costs.

Implement and test this topic

Implementation for cash and card price presentation across the customer journey is complete only when topic-specific success and failure paths have passed. Turn this into a witnessed acceptance test: buy and refund with cash. Record the starting configuration, expected result, actual result, identifiers, owner, and follow-up for any exception. Assign a trained role to credit, restrict permissions to what that role needs, and document the exact point where staff must stop and escalate. Exercise PIN and signature debit in normal operation and under a realistic failure, correction, timeout, or duplicate condition; a single successful attempt is not adequate evidence. Pilot prepaid with limited exposure where practical, preserve a continuity or rollback path, and name the person authorized to pause the launch. Verify reporting and reconciliation after wallets, because a customer-facing success message does not prove settlement, downstream synchronization, or correct accounting. Revisit split tender after the first operating cycle and look for manual workarounds, support delays, configuration drift, customer confusion, or terms that differed from implementation. Turn this into a witnessed acceptance test: tips. Record the starting configuration, expected result, actual result, identifiers, owner, and follow-up for any exception. Assign a trained role to offline behavior while comparing every displayed amount, restrict permissions to what that role needs, and document the exact point where staff must stop and escalate.

Verify the decision

Verify cash and card price presentation across the customer journey with current, appropriately authoritative material and reproducible business records. Use current processor program documents for the claims it is positioned to support, save its publication or version date, and distinguish direct evidence from interpretation. Cross-check Visa and Mastercard materials against the implemented configuration and the controlling agreement; general documentation may not describe negotiated terms or enabled features. Record who reviewed the federal cash-discount provision, when it was reviewed, what question it answered, and which material uncertainty remains before a decision can be approved. Recheck qualified jurisdiction-specific guidance for advertising whenever the provider, network rule, jurisdiction, product version, sales channel, or business workflow changes materially. Preserve tax with related correspondence and test results so another reviewer can reproduce the conclusion without depending on memory or vendor assurances. Escalate beyond consumer rules when a legal, tax, accounting, employment, or security conclusion is needed; this resource does not supply professional advice.

Verification checklist

  • Document both posted prices.
  • Test credit, debit, prepaid, cash, and wallets.
  • Verify signage at every sales channel.
  • Review receipts and refund amounts.
  • Confirm tax and tip configuration.
  • Obtain processor approval in writing.
  • Check current network publications.
  • Check applicable jurisdiction requirements.
  • Train staff with approved language.
  • Schedule recurring configuration reviews.

Primary and authoritative sources

Links were accessed 2026-09-08. Confirm the current version before relying on a rule or requirement.

  1. Credit and Debit Card SurchargesVisa
  2. Merchant Surcharge RulesMastercard
  3. 15 U.S.C. § 1666f — Discounts for payments in cashU.S. House Office of the Law Revision Counsel

Related quick answers

Questions to resolve next

Browse all answers

Merchant processing options

Tell us how your business accepts payments

Secure request

Draft saved

Do not submit SSNs, full bank account numbers, passwords, or cardholder data. Information is used to respond to your request.