Restaurant and Food Service Payment Processing in 2026: Tip Adjustment, Pay-at-the-Table, and Delivery Settlement

Call 866-305-6454 to review restaurant payment processing, POS configuration, and settlement workflows.

Restaurant payments move through different paths. A guest paying at a dining-room table is not the same as a customer ordering online for delivery. Tip adjustments, merchant category codes, debit routing, delivery platforms, PCI scope, and late-night batch closing all affect how those payments are recorded and reconciled.

The operating goal is to keep each step traceable: the order, the authorization, the customer-approved amount, the cleared transaction, and the deposit. Start with the restaurant’s actual transaction mix. Then configure the terminal, gateway, account, and reporting around it.

Dining-room tips change the final payment amount

A restaurant often authorizes a card before the customer decides on a tip. The final amount may therefore differ from the original authorization.

A typical table-service sequence is:

1. The POS totals the check before the tip.
2. The customer presents a card at the table or at a register.
3. The terminal sends an authorization request for the pre-tip amount.
4. The customer enters or writes a tip.
5. Staff records the tip in the POS.
6. The final amount is submitted for clearing when the restaurant closes its batch.

Authorization is the issuer’s approval of the requested amount. Clearing is the later submission of the completed transaction. Settlement and funding occur after the transaction data moves through the payment system and the merchant’s acquiring arrangement.

The gap between authorization and final clearing is a control point. If an employee enters the wrong tip, alters the tip, or links a tip to the wrong check, the cleared amount may not match what the customer intended. That can lead to a dispute about an incorrect amount, even when the original card-present authorization was valid.

Keep the tip record connected to the check

Retain the original check, itemized receipt, authorization record, customer-entered tip, any later edits, and final cleared amount. The records should use the same order or transaction reference where the systems support it.

Limit who can edit tips after the initial entry. Record the user, time, and reason for an adjustment. If a correction is required, preserve the original entry rather than overwriting it without an audit trail.

The goal is not only to show that a card was presented. The restaurant should be able to show the check total, the tip selection, and how the final transaction amount was calculated.

Visa and Mastercard tip adjustments are not interchangeable

Visa’s restaurant acceptance guidance describes a tip allowance where the merchant authorizes the transaction amount only and the customer’s tip is added into the amount the merchant deposits afterward. Visa’s guidance states that up to 20% may be added to the authorization amount without liability for authorization-related disputes, and that this applies to MCC 5812 eating places and restaurants, MCC 5813 drinking places, and MCC 5814 fast food restaurants. The 20% allowance and its MCC scope come from Visa’s restaurant guidance, not from a general cross-brand rule, and the merchant must confirm current program terms and the applicable MCC assignments with the acquirer before relying on it.Visa Core Rules and Visa Product and Service Rules · Visa Chip Payment Acceptance for Restaurant Merchants

Visa’s guidance also makes two operating points clear. First, the merchant must not add an estimated tip amount to the authorization request. The allowance applies only to a tip the customer actually adds. Second, Visa notes that an issuer may hold an additional 20% above the authorized amount to cover an allowed tip. That can confuse a cardholder reviewing available funds, so it should be treated as a customer-experience consideration rather than a fee.

Nothing in this section should be read as a Mastercard allowance. The figure discussed here is brand-specific to Visa.

Do not apply Visa’s allowance to Mastercard. Mastercard’s public rules require valid, accurate, complete, and consistent transaction data. They also direct users to applicable transaction-processing standards. Confirm the current Mastercard tip-adjustment handling with the acquirer or processor before configuring the POS. The restaurant’s operating region, transaction type, and processor configuration may matter.Mastercard Rules

Where the terminal collects the tip before the authorization request, the tip can be included in the amount submitted for authorization. That avoids a later tip adjustment, provided the customer has confirmed the amount. Pay-at-the-table can support this type of flow.

Avoid a single system setting that assumes every card brand, payment environment, or transaction type has the same adjustment rule.

Pay-at-the-table and contactless are card-present flows

When the customer and card or payment device are physically present and the transaction is completed at an acceptance device, the payment is generally card-present. That remains true whether the terminal sits at a fixed counter or the server brings a handheld terminal to the table, subject to the applicable network definitions and transaction conditions.

A tableside flow can let the customer review the check, select a tip, and complete the payment without handing the card to staff. Contactless acceptance can support a tap from a card or compatible device. The terminal still needs to submit the correct transaction type and amount.

For a restaurant, the distinction matters operationally:

• A guest tapping at the table is not the same flow as entering card details on an online ordering page.
• A card-present terminal transaction uses the terminal and in-person acceptance process.
• An online order paid on a website or in an app is typically card-not-present, even if the customer later picks up the food.
• A delivery payment taken remotely remains distinct from a payment accepted in person by a courier using an approved terminal.

Do not classify a transaction by how the food is fulfilled alone. Classify it by the actual payment acceptance flow.

Bridge’s retail credit card processing page describes card-present terminal options, including countertop, wireless, and smart POS devices. Restaurants should verify that the selected hardware supports the required receipt, tip, contactless, and debit functions for their deployment.

PIN debit routing has a separate cost and routing structure

Debit routing and PIN entry involve different questions. The customer authentication method is one factor. The network route is another. A terminal that accepts PIN debit does not, by itself, ensure that every eligible debit transaction will be routed as the merchant expects.

Regulation II requires covered debit transactions to be capable of routing over at least two unaffiliated networks. The rule also prohibits network or issuer restrictions that prevent the merchant from directing routing among available networks. A restaurant should confirm how its acquirer and POS handle eligible debit routing, including contactless debit transactions and any PIN-entry prompts.Regulation II, 12 CFR Part 235

For issuers covered by the interchange standard, the maximum interchange fee structure is $0.21 plus 0.05% of the transaction value. An eligible issuer may receive an additional $0.01 fraud-prevention adjustment if it meets the regulation’s requirements. These are issuer interchange limits, not the restaurant’s full processing price. They do not include every processor, acquirer, network, equipment, or gateway cost.Federal Reserve: Average Debit Card Interchange Fee by Payment Card Network · Regulation II, § 235.3 and § 235.4

Ask the processor to explain how PIN debit is identified on statements. Compare the route and total debit-related cost using actual merchant statements, not a general assumption that a particular entry method always produces the lowest cost.

Restaurant MCC coding can affect interchange qualification

Merchant category codes describe the merchant’s business. Visa’s April 2026 Merchant Data Standards Manual defines MCC 5812 as eating places and restaurants. It defines MCC 5814 as fast food restaurants, including qualifying quick-service operations. The manual says the acquirer must assign the MCC that most accurately describes the merchant’s primary business. It also states that separate lines of business may require separate MCCs in certain circumstances.Visa Merchant Data Standards Manual

An MCC is not a discount setting. A restaurant should not request a code solely because it believes the code will secure a preferred rate. The acquirer determines the appropriate classification based on the business and network rules.

MCC can affect how a transaction is assessed against interchange program criteria. But using a restaurant MCC does not guarantee a particular interchange category or price. Qualification may depend on other program requirements and transaction data. Table service, fast food, catering, bars, pickup, and delivery models may not all fit the same category.

Use a processor review if the merchant has multiple distinct operations. A hotel restaurant, separate bar, catering division, food truck, or online-only food business may require additional analysis. Keep the merchant account description, website, application, POS setup, and actual business activity consistent.

For pricing comparisons, review itemized charges and the underlying transaction mix. Bridge’s transparent credit card processing pricing page describes Bridge’s published pricing model; use the merchant agreement and account-specific schedule to confirm applicable terms.

Counter-service and quick-service flows behave differently from table service

At a counter or in a fast-casual flow, the tip prompt usually appears before the authorization request. The customer selects a tip or declines the tip screen, and the terminal submits one amount for authorization. In that setup, the gratuity is already inside the authorized amount. No later post-authorization tip adjustment is usually needed if the customer-approved total is what goes up for authorization.

That changes the control point. In a dining-room flow, the main risk often sits in the gap between the original authorization and the later cleared amount. In a counter flow, the main risk shifts toward prompt design, staff handling, and lane procedure. The restaurant should confirm that the screen presents the total clearly, that the customer can decline the tip prompt without confusion, and that staff do not interfere with the customer’s selection. If the restaurant trains staff to turn the screen, skip prompts, or move quickly past customer review steps, it creates avoidable dispute risk even when no later tip edit occurs.

The Visa Merchant Data Standards Manual separates MCC 5814 fast food restaurants from MCC 5812 eating places and restaurants.Visa Merchant Data Standards Manual A concept that mixes counter ordering, pickup shelves, and table service should not assume that the merchant can simply pick the preferred code. The manual states that the acquirer assigns the MCC that best describes the merchant’s primary business. If the restaurant runs more than one distinct line of business, the acquirer may need to determine whether a separate classification or account structure is required. That is an underwriting and network-rules question, not a self-selected pricing option.

This matters when a brand has a dining room but also operates a separate quick-service line. The payment flow may be different even when the menu and trade name are the same. A tableside terminal may authorize before the tip is known. A counter terminal may present the tip first and authorize the full amount at once. The reporting, device prompts, and exception handling can therefore differ by lane, even inside one location.

High-throughput counter environments add another layer. Contactless tap is common where line speed matters. When a restaurant is processing a large number of small and medium tickets in a short window, terminal configuration becomes important. Eligible debit transactions still have routing requirements under Regulation II, and the merchant should confirm how the terminal, processor, and POS handle available routing options in a contactless environment.Regulation II, 12 CFR Part 235 Speed at the counter does not remove the need to understand how debit is routed or what settings are enabled on the account.

A restaurant also should not assume that a configuration built for the dining room is correct for a separate quick-service line of business. The prompt sequence, receipt flow, default tender behavior, cashier permissions, and debit handling may need different settings. Review each acceptance point on its own terms: table service, bar, host stand, takeout counter, drive-through, kiosk, and any mobile line-busting device. If the operational model differs, the payment controls should be reviewed separately.

Online ordering and delivery create a separate payment path

An online order paid on a website or in an app is usually card-not-present. That remains true if the customer picks up the order at the counter. Delivery orders paid remotely are also distinct from dining-room payments accepted on a terminal.

Online flows commonly involve several parties:

• The restaurant that prepares the order.
• The ordering website or marketplace.
• A payment facilitator or gateway.
• The acquirer and processor.
• The delivery provider or courier.
• The customer’s card issuer.

The party that appears as the merchant in payment records may differ across platforms. Visa’s merchant data manual distinguishes merchants, marketplaces, and payment facilitators, including scenarios where a marketplace processes and receives settlement on behalf of sellers. Do not assume that every delivery app processes a restaurant’s orders the same way.

Before launch, determine who is merchant of record for each order flow, whose name appears on the statement, which entity receives the payment, and who is contractually responsible for chargeback handling and losses. Network dispute rights and the acquirer’s obligations still depend on how the transaction is actually registered and processed. A commercial agreement can allocate costs between the platform and restaurant, but that alone does not establish how the card transaction appears to the issuer.

Descriptor confusion can turn a fulfilled order into a dispute

A customer may recognize the restaurant but not the platform descriptor, or recognize the platform but not the restaurant name shown on the receipt. Confusion can lead to a claim that the transaction was unauthorized or unrecognized.

Review the descriptor customers will see. Match order confirmations, receipts, help information, and refund notices to that descriptor. Use consistent merchant identification across the ordering page and customer communications.

For a delivery dispute, keep records that directly address the allegation:

• Platform order number and restaurant order number.
• Itemized order and amount.
• Authorization and capture records.
• Customer-facing receipt and descriptor.
• Delivery address and handoff record, where available.
• Platform settlement statement.
• Refund, credit, or cancellation record.
• Relevant customer and platform communications.

Do not rely on a receipt alone if the allegation concerns a missing delivery, wrong amount, duplicate charge, or unprocessed refund. Build the evidence file around the specific dispute reason and the party responsible for responding.

Bridge’s payment gateway integration information can help restaurants assess gateway options for online checkout and integrations. Restaurants should confirm how the gateway, POS, ordering platform, and delivery marketplace exchange order IDs, transaction status, refunds, and settlement data. Review merchant account features for Bridge-published descriptions of reporting and chargeback support.

PCI scope includes restaurant POS and online payment pages

PCI DSS scope depends on the systems and service providers involved in storing, processing, or transmitting cardholder data, and on systems that can affect the security of that environment. It is not automatically one independent scope per restaurant address. A multi-location business needs to map which systems connect across locations and which payment functions are outsourced.

A restaurant location may have POS terminals, back-office computers, network equipment, Wi-Fi, kitchen display systems, and vendor connections. Online ordering can add web pages, payment forms, scripts, hosted checkout, and third-party integrations. The restaurant should document the actual architecture and confirm its validation requirements with its acquirer or qualified assessor.

PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 apply to payment pages and scripts in the customer’s browser. Requirement 6.4.3 addresses managing payment-page scripts, including authorization, integrity, and an inventory with written justification. Requirement 11.6.1 addresses a change-and-tamper-detection mechanism for payment pages, including detecting unauthorized changes to security-impacting headers and payment-page contents as received by the browser.PCI Security Standards Council: PCI DSS v4.0.1 and supporting documents

For restaurant online ordering, maintain an inventory of scripts on payment pages. Include analytics, tag managers, loyalty tools, chat widgets, delivery integrations, and payment scripts when they apply. Assign an owner and purpose to each script. Control additions and changes. Configure alerts so staff can investigate changes to relevant payment-page content and headers.

Outsourcing checkout to a gateway or marketplace does not automatically remove the restaurant’s PCI responsibilities. It may change the systems in scope. Confirm responsibilities and scope boundaries in writing with the provider and acquirer.

Per-location isolation can help clarify the environment, but it does not automatically create separate compliance scope. Shared networks, remote access, centralized POS management, and shared payment applications can connect locations. Document the boundaries before treating one site as isolated.

Batch close requires a clear restaurant business date

Restaurants with late-night service face a simple but important reconciliation issue: the business day and the calendar day may differ. A check may be opened before midnight, tipped after midnight, entered in the POS after a shift change, and included in a batch that closes later.

Use consistent records for:

• Service or business date.
• Order open and close time.
• Authorization time.
• Tip-entry time.
• Final capture amount.
• Batch-close time.
• Processor settlement and funding records.

Batch closing rules and cutoffs depend on the processor, acquirer, and POS configuration. Do not assume a universal close time. Confirm what happens when a batch is left open, whether a late-night closing process crosses the calendar date, and how transactions appear in reports and deposits.

Close and reconcile the batch according to the merchant’s agreed schedule. Review pending authorizations, captures, tip edits, voids, and refunds. Compare POS totals with the processor’s batch record, then compare processor settlement with the funding report and bank deposit. Resolve mismatches promptly.

For a restaurant open overnight, document the process for assigning transactions to the correct service date even when batch submission occurs on the following calendar date. Train managers and closers to follow the same process across locations.

Bridge’s ACH payment processing for small business information covers a different payment rail. ACH may suit certain invoices or business payments, but it does not replace card authorization, restaurant tip adjustment, or card-network settlement procedures.

What to get in writing from the processor

Treat activation as a documentation exercise, not only a pricing exercise. Before go-live and again after activation, a restaurant owner should collect written confirmation of how the account is configured and how exceptions are handled. This is an operating checklist, not legal advice.

Get these items in writing:

• The authorization-to-clearing tolerance for gratuity adjustments, stated by card brand rather than as one number for all transactions.
• The batch close cutoff times, including what happens if a batch crosses midnight or is left open.
• How eligible debit transactions are routed, and which routing options are enabled on the account.
• The exact descriptor or descriptors the customer will see for each channel, including online ordering and any marketplace flow.
• Which entity is the chargeback contact of record for each payment channel.
• Which systems fall inside PCI scope and which payment functions are outsourced.
• How tip edits are logged, including who can make them and where the audit trail appears.
• How settlement and funding reports are expected to reconcile to POS totals.

Do not accept a verbal summary if the restaurant has more than one payment path. Dining-room payments, quick-service counter payments, online ordering, delivery marketplaces, and keyed orders may not all follow the same rules inside one account setup. A short written confirmation from the processor or acquirer can reduce confusion later when a manager is trying to reconcile a batch, answer a chargeback, or explain a customer complaint.

After activation, re-check the live setup against the written summary. Confirm that terminal prompts match the intended flow. Confirm that the descriptor shown in customer communications matches the descriptor that actually appears in processing records. Confirm that reporting access is in place before the first busy weekend, not after a funding mismatch appears.

In the first month, re-verify:

• One test authorization with a tip adjustment.
• One test refund.
• One controlled decline.
• One recurring or stored-credential transaction, if offered.
• The descriptor as it appears on a real statement.
• The funding report against the POS batch total.

Review the restaurant’s payment flow before changing processors

Map each payment path separately:

• Dining-room terminal payments.
• Counter and quick-service payments.
• Contactless card and wallet payments.
• PIN debit transactions.
• Online pickup orders.
• Delivery orders through the restaurant’s website.
• Orders processed through third-party marketplaces.
• Phone orders or keyed transactions.
• Catering deposits and invoice payments.

For each path, confirm the merchant of record, MCC, card-present or card-not-present status, authorization amount, tip handling, capture timing, descriptor, refund owner, chargeback contact, PCI responsibility, and reporting reference.

Do not force unlike transactions into one configuration. Dining-room tips, online delivery disputes, debit routing, and late-night batch settlement have different operational controls. A clear map helps identify where the restaurant, marketplace, gateway, processor, and acquirer each act.

Call 866-305-6454 to review restaurant payment flows, POS and gateway integrations, pricing, and settlement reconciliation with Bridge Capital Partners.