Use card-present payment when the guest and card are available at a working terminal. Consider keyed entry for an exception, such as a phone order, only after confirming that your processor permits the workflow and that an authorized employee can enter the details securely. Keyed payments may have different fees and fraud exposure, so compare the full process, not just the rate.
Start with the moments when staff actually need to take payment: at the counter, at a table, over the phone or after a terminal problem. For each one, identify who takes the payment, which device they use and what happens if authorization is declined. Then ask vendors to demonstrate those steps in the configuration they would sell you.
Define when keyed entry is needed
Card-present generally means the guest presents a card or payment device to the terminal. A keyed payment means someone manually enters card details rather than presenting the card to the terminal. The distinction matters even if both payments settle into the same restaurant account: the processor may quote and handle them differently.
List your likely exceptions before asking for a quote. A restaurant taking occasional phone orders has a different need from one that routinely accepts payment before a large catering pickup. Decide whether the guest can use another approved payment method instead and whether the extra handling is worth it.
Write down the intended staff role for each situation. For example, a counter employee might handle ordinary terminal payments while a shift manager handles permitted phone payments. That is a policy choice, not a guarantee that a particular POS can enforce those roles. Ask how permissions are assigned, who can change them and whether individual staff actions appear in the payment record.
Also map the systems involved. Does the employee enter the order into the POS first? Where is the payment entered? Can staff see the authorization result beside the order, or must they check another screen? The answers affect both service speed and the chance that an unpaid order is mistaken for a paid one.
Review the proposed restaurant hardware alongside the software. Ask what staff should do if a terminal is unavailable, and whether keyed entry is permitted in that situation. Do not assume a payment will work offline or that a manual entry will be approved simply because a terminal is down.
Compare quotes for the same payment
Ask each vendor for written card-present and keyed-entry quotes using the same transaction amount. Request the percentage and per-transaction charge for each method, plus any conditions that could change the quote. Confirm which processor and devices the quote assumes. A lower rate on one line is not enough if the quote excludes charges that apply to your workflow.
The following is a hypothetical comparison, not a vendor price. Suppose an $80 order has a card-present quote of 2.5% plus $0.10 and a keyed quote of 3.5% plus $0.20. The quoted card-present processing fee is $2.10: $2.00 plus $0.10. The keyed fee is $3.00: $2.80 plus $0.20. Keyed entry costs $0.90 more in quoted processing fees for that transaction.
Those figures include the stated variable percentage and per-transaction charges only. They exclude fixed costs such as software or equipment, and exception costs such as disputes or refunds. They are not the restaurant's all-in operating costs. The $80 is the sale amount, not the fee or a deposit.
Under those assumptions, use the card-present route when the guest and working terminal are available. For an occasional phone order where the card cannot be presented, the extra $0.90 may be acceptable if management approves the process and its controls. For frequent phone orders, estimate volume and compare alternatives before accepting that difference as routine.
When reviewing quotes, ask how refunds, disputed payments and any minimum or account charges are priced. Ask whether the quoted rate applies to your expected card types and transaction mix. The guide to POS payments and processing costs can help organize those questions. For Fleksa's current plan pricing, consult Fleksa plans; the plans page was checked in November 2026. Processing and other applicable costs still need to be confirmed in your quote.
Fleksa offers restaurant POS alongside direct ordering and reservations. Toast lists restaurant POS, hardware, online ordering, payments, KDS and integrations. Square offers restaurant point of sale and related payment and order tools. For each, use the same requirements sheet and ask about keyed entry, permissions, records, contract terms and processor choice. Do not treat a product list as proof that a particular payment workflow is available in your setup.
Walk through authorization and exceptions safely
Before rollout, ask the vendor to demonstrate the complete workflow in a simulation or training environment. Use fictional order and payment details supplied for that environment. The exercise must not create a real charge, send a guest message or dispatch a courier. Confirm those safeguards before anyone starts.
Give the operator a specific scenario: a guest calls to order dinner for pickup and cannot present a card at the time of the call. The employee enters the order, asks the manager to handle payment under the restaurant's proposed policy, and follows the vendor's approved simulation steps. Record the expected result before the demonstration, then record what the screen actually shows.
For an approved simulation, expect an explicit authorization result and a clear connection between that result and the order. Ask who can see it and whether the record identifies the payment method and employee. For a declined simulation, expect staff to recognize that payment was not authorized. The manager should decide how to follow up; the kitchen should not treat a decline as a completed payment merely because an order exists.
Run a separate permission check. Have a simulated counter-employee account attempt the action that your policy reserves for a manager. The expected result is denial if that restriction is part of your requirements. If the action succeeds, record a failure against your policy and ask whether the permission can be configured. Do not describe the restriction as available until the vendor demonstrates it in your proposed setup.
Discuss fraud exposure as an operational risk, not a number invented for the exercise. Ask what information staff are prompted to collect, what checks are available, and what the processor expects when a payment is disputed. A successful authorization is not the same as a guarantee against a later dispute. Avoid putting card details into order notes or other informal records; ask the processor for its approved handling procedure.
If a required control is unavailable, agree on a safe workaround before service. That might mean using another processor-approved payment method or asking a manager to handle the order under a documented procedure. If there is no acceptable workaround, leave keyed entry out of the rollout until the issue is resolved. A later live-service pilot is a separate management decision, not part of the simulated checks.
Make a rollout decision with evidence
Use the table to turn the demonstration into a decision. Pass means the proposed configuration meets your written requirement. Fail means it does not. Unknown means you still need a clear answer or demonstration; it is not a pass.
| Check | Pass | Fail | Unknown: next action |
|---|---|---|---|
| Authorization result | Staff can identify the simulated result and related order. | Staff cannot reliably distinguish an authorized payment from a decline. | Ask for the order and payment screens to be shown together. |
| Staff access | The proposed role restriction works as required. | An unauthorized role can perform the restricted action. | Ask who configures permissions and repeat the simulated check. |
| Dispute record | The processor identifies the records available and how to retrieve them. | The required record cannot be obtained under the proposed process. | Request a sample record and the processor's dispute procedure. |
| Fees and exceptions | The quote covers both methods and identifies other applicable charges. | The offered terms do not meet the restaurant's requirements. | Request written rates, conditions and exception charges. |
Assign an approval owner, usually the person responsible for payment operations and the vendor agreement. Keep the requirements sheet, written quote, simulated outcomes and any promised configuration changes together. Record who will train staff and who can approve a change to permissions later.
For dispute evidence, ask the processor which transaction and order records it makes available, how long they can be retrieved and who can access them. Do not assume that an order receipt alone will resolve a dispute. Have a qualified adviser review contract or legal questions when needed, rather than relying on a sales demonstration to settle them.
Once the owner has reviewed the open items, request a demo of the Fleksa restaurant POS. Bring your sample phone-order scenario, role requirements and quote questions, and ask the team to show the result in a safe simulation.
Frequently asked questions
Is keyed entry always more expensive than card-present payment?
Not necessarily. Rates and charges depend on the processor and your agreement. Ask for both quotes using the same amount, then compare applicable fixed and exception costs as well as transaction fees.
Does an authorization mean a keyed payment cannot be disputed?
No. Authorization and a later dispute are different events. Ask your processor what records and procedures apply to the payment method you plan to use.
Should every employee be able to key in a payment?
Set access according to your operating policy and confirm whether the proposed system can enforce it. If you want manager-only access, demonstrate that restriction before relying on it.
