在美国经营餐馆或酒吧，最怕的场景之一，是客人消费完直接走人，或者卡刷不过、余额不足，账单变成坏账。Pre-Authorization（预授权） 正是为了解决这个问题而设计的功能。对使用餐饮POS系统的华人商家来说，它不是“可选项”，而是酒吧开 Tab、桌台服务、预约 No-Show 防控中非常实用的一环。但预授权用不对，也可能带来客人投诉、交易被拒、甚至 capture 失败。下面按实际操作中最常遇到的8个问题，把 Pre-Auth 从开单到结账的逻辑一次讲清楚。
- Pre-Authorization是什么？
Pre-Authorization 的本质是先验证卡片、暂时冻结一笔额度，但不立即扣款。POS 系统先向发卡行发起一笔“授权”请求，确认这张卡有效、且可用余额足以覆盖预估消费金额；资金仍然在客人账户里，只是被标记为“暂时占用”。真正把钱从客人卡上扣走，要等到你在 POS 上做 Capture（捕获/结算） 这一步。
所以预授权和普通刷卡消费的核心区别是：普通 Sale 是一步完成“授权 + 扣款”；预授权是两步——先 Authorization，后 Capture。中间的窗口期，正是餐馆和酒吧用来“先把客人留住、最后按实际消费加小费结算”的空间。
- 酒吧和餐厅为什么常用预授权？
酒吧场景最典型：客人开 Tab 时，最终消费金额事先并不知道，可能只点一杯，也可能连开几轮。如果直接把卡号记下来、不做任何验证，一旦客人离开时卡刷不过或余额不足，商家几乎没有追索手段。预授权在开 Tab 时先冻结一个预设金额（或首单金额中的较大者），等于提前确认“这张卡至少能覆盖到这个数”。
对正餐餐厅来说，预授权同样有用：桌台服务中先开单、用餐中途加菜、最后加小费结算，整个流程和开 Tab 的逻辑一致。选餐馆POS系统时，如果要覆盖酒吧或全服务场景，预授权 / Tab Auth 是否原生支持，应当列入餐馆POS系统比较的核查清单。Toast、SpotOn、Square 等主流系统在酒吧场景中都有预授权或 Tab 支持，但具体默认金额、是否支持 increment、是否额外收费，各家并不相同。
开始POS需求评估
通过简单问答，我们将为您推荐最适合的POS系统。
- 预授权会不会马上扣钱？
不会。 预授权只冻结额度，钱并没有真正从客人卡上“扣走”。在客人手机银行或网银里，这笔金额通常显示为 Pending（待处理） ，而不是已入账的消费。对商家来说，预授权只是拿到了“之后按实际金额 capture 的权利”，不等于已经收到款。
这一点需要在员工培训中反复强调：预授权成功，只说明卡有效、额度够用，不代表账单已经付了。如果开 Tab 后忘记在关台时做 capture，预授权过期后额度会自动释放，商家再想扣款就来不及了。
- 最终金额高于预授权怎么办？
这是预授权在实际操作中最容易出问题的地方。如果最终账单（含小费）超过了最初冻结的金额，POS 系统在 capture 时需要向发卡行请求调高授权金额（incremental authorization / authorization adjustment） 。如果客人卡片的可用余额足以覆盖调高后的金额，通常可以顺利完成；如果余额不够，capture 可能被拒绝，导致你既拿不到原预授权金额，也收不到超出部分。
一个实用策略是：开 Tab 时不要把预授权金额设得过低。行业常见做法是在账单预估金额基础上加一个小费缓冲，通常加 10%–30%，以覆盖之后加入的小费空间。但金额设得太高又可能触发银行风控，或者让客人看到过大的 hold 而产生不满。比较稳妥的折中是，参考平均桌台消费的 50% 左右作为默认预授权额，再根据实际开单情况由员工手动调整。
- Tip如何加入最终交易？
小费不应当在预授权阶段就固定死，而应在 capture 时一并加入。操作逻辑是：预授权冻结一个基数金额，客人签单确定小费后，在 POS 上执行 Capture / Pre-Auth Completion，将“实际消费 + 小费”作为最终金额提交。如果最终金额高于原预授权，就回到上一条所说的授权调整逻辑；如果最终金额低于预授权，系统 capture 实际金额后，未使用的冻结额度会自动释放回客人卡上。
对餐馆收银系统来说，结账界面上是否有清晰的“小费输入 → 调整最终金额 → capture”流程，直接影响前台效率。在餐饮收银系统推荐2026类选型中，建议把“预授权单加小费是否顺畅”作为实际测试项，而不是只看功能列表上写没写“支持预授权”。
- 顾客卡片显示Pending正常吗？
非常正常，而且几乎是预授权的必然现象。 预授权在发卡行端就是以 pending authorization 的形式存在的，客人看到的是“有一笔钱被暂时冻结”，而不是已扣款。Pending 的金额可能是预设的固定额度，也可能高于实际消费（如果系统在预授权时加上了预估小费缓冲）。
商家能做的是提前沟通：开 Tab 或预授权时顺口说明“这是暂时冻结，不是已经扣款，结账后会按实际金额调整”，能减少相当一部分客人看到 Pending 后的疑问和投诉。
- 预授权多久会释放？
释放时间不由商家决定，而由发卡银行和卡组织规则决定。常见区间是 3 到 7 个工作日；部分银行可能延长到 10 天甚至更久，Amex 在某些 acquirer 下的自动释放窗口可能短至 7–10 天，也可能长达 30 天，取决于具体配置。如果商家主动 void 预授权，释放会更快一些，通常几个工作日内从客人可见的 pending 中消失。
这意味着：预授权不能当作“长期押金”来用。 如果预计从开单到 capture 之间会超过一周，需要特别留意授权过期风险，过期后 capture 可能失败，商家甚至可能被收一笔费用。
- 哪些场景不适合使用Pre-Auth？
预授权不是万能工具，以下场景要么不适用，要么需要格外谨慎。
普通快餐、奶茶店、金额确定的零售交易不适合用预授权。 金额在刷卡那一刻就已经确定，直接用 Sale 一步完成即可；强行用预授权只会让客人多看到一次 pending，增加不必要的困惑。更现实的一点是，部分收单机构对预授权有行业准入限制，普通餐饮零售商户未必能开通信用卡预授权权限，尤其是以“押金”为目的的使用，可能根本不在允许范围内。
预约 No-Show 收费场景需要区分“预授权”和“押金”的边界。 预约时预授权 $10–$20 用于约束 No-Show，在部分餐馆等位系统或预约模块中可行，但必须确认收单方和卡组织规则是否允许，以及未到店时能否顺利 capture。如果系统或资质不支持，强行操作可能触发合规问题。
授权过期风险高的场景也应避免。 如果从预授权到最终结算之间可能拖过一周，预授权过期后商家将失去 capture 权利，反而增加收款不确定性。
选型时把预授权放回餐馆POS系统的整体判断中
Pre-Authorization 本身是一个“支付流程功能”，但它能不能用好，取决于餐馆POS系统是否在开 Tab、加小费、金额调整、pending 提示、释放节奏上和你的业态匹配。在做餐馆POS系统比较或参考餐饮收银系统推荐时，建议直接问三个问题：预授权是否原生支持、最终金额高于预授权时的处理逻辑是什么、预授权失败或过期时系统如何提示。餐馆POS机价格固然重要，但预授权这类高频操作如果流程不顺，后续带来的客人投诉和收款风险，成本远高于机器差价。
如果你正在梳理刷卡与预授权在收银台上的完整操作逻辑，可以进一步参考信用卡机指南中的刷卡流程与费率说明；如果还在选型阶段，建议先从餐馆POS系统的整体功能框架入手，再对照自己的酒吧、桌台或预约场景做取舍。
相关阅读：