浏览器里的加密货币 POS 终端不做什么

Paymos 的加密货币 POS 终端是一张网页，不是一台机器。每个项目一条终端链接，在控制台里生成，在手机或平板上打开——不需要专用收款硬件，没有按设备的初始化，也没有要配对的东西。收银员用终端支持的 46 种法币之一输入金额，付款确认后屏幕把结果留在那里，等人把它带回输入金额。它不带库存、不带班次、不打印小票、不算税、也没有小费。

最后那句话，是 POS 页面通常不会写的。在桌前读到的能力清单，到了柜台就变成一句承诺，两者之间的差距会当着排队的客人暴露出来。

做展会、快闪店和海外线下交付的卖家，最容易踩到这个差距。行李里带不了一台收款机，落地当天要收的却是真钱——这时候要先弄清楚，一张网页能替掉的是柜台上的哪一格。

终端产品页讲这项能力本身，文档讲那条链接从哪里取。这篇写在两者下面：浏览器终端实际怎么运转，以及它的五条边界。

浏览器里的加密货币 POS 终端是什么？

浏览器里的加密货币 POS 终端，是一张跑在商户自己已有设备上的收款页面。整个流程里出现不了专用收款硬件——设备清单就是一部带浏览器的手机或平板。

每个项目有一条终端链接，在控制台里生成。收银员打开这条链接，打开这个动作本身就是全部安装：没有设备配置，没有配对步骤，也没有哪一件设备必须先登记才能收第一笔钱。

链接是项目级的属性，有没有这条链接也是。终端跟着项目的集成方式走：只有集成方式为「收银终端」的项目才有终端链接，所以一个跑三个项目的商户，可能只有其中一个项目在柜台上收钱。这个选择在建项目时问一次，之后不能改，也没有一个单独的终端开关可拨——要换一种接法，就是另建一个项目。

柜台也不会另开一本账。终端上收到的付款就是商户账下一张普通账单，在控制台里和其他账单排在一起，用同一套搜索和筛选就能找到。

这个终端不做哪五件事？

终端不做库存、不做班次、不打印小票、不算税、不收小费。这是完整 POS 系统承担的五件事，一件都不在这里。清单之所以放在文章这么靠前的位置，是为了让商户先读到它，而不是让收银员在排队中间才发现。

把这份清单写出来本身就是重点。产品页只写自己做什么，读的人会把周围的沉默当成覆盖范围，而在柜台上，这种误读的代价是一笔卖不成的生意——这也是唯一值得把功能表反过来写的场合。

终端是一个收款界面。它收下一个金额并把这笔钱收到，店里其余的活今天在哪里跑，之后还在哪里跑：库存系统、排班表、开票流程，以及负责算出该收多少钱的那个环节。

这五件事里有四件缺席，是因为它们依赖终端拿不到的信息。库存要知道卖出的是哪件商品，班次要知道当班的是谁，单据和税额要知道这笔生意做在哪里、卖给了谁；输入金额这一步不问其中任何一项。

没有要配对的硬件，会带来什么变化？

配对，是把一台 POS 机变成一件需要采购、投保、配置和更换的资产的那一步。浏览器终端把这一步以及它背后的设备台账一起去掉了：没有要过夜充电的东西，也没有哪台设备必须在场，生意才能成交。

换机也从同一条事实推出来。班中途坏掉的平板，换一台打开终端链接就继续用，因为本来就没有任何东西绑在坏掉的那台上，接替的那台也不用重做一遍按设备的初始化。

依赖是转移了，不是消失了。浏览器终端需要一台浏览器能用、网络在线的设备，这是一种和「打印纸还有没有」不一样的顾虑，不是没有顾虑。

成本那边的结论也从这里来。柜台上的硬件成本不再是一台要买的新机器，而是手里已经有的那部手机；多开一个收银位也不是一次采购，是多开一个标签页。

每个项目一条链接，覆盖到哪里？

一条终端链接覆盖所有打开它的设备。终端支持多台设备同时使用，第二个收银员在另一部手机上打开同一张页面，第三个再来一次——一条链接，柜台上有几双手都够用。

每台设备继承同一套外观。终端使用项目的收银台品牌设置——项目的付款页已经带着的名称和 logo、样式预设、配色和圆角——所以一个柜台后面的三部手机显示的是同一家店。

分界线在项目，不在门店。两个当成两家店在运营的销售点，与其共用一条链接，不如建成两个项目：各自有自己的终端链接、自己的品牌设置和各自启用的网络与代币。

项目级的链接带不来的东西是班次。终端里没有一个「在某位收银员名下开启、以盘点收尾」的对象，所以日结这件事今天从哪里来，之后还从哪里来，按已经在跑的流程走。

用法币输入金额有什么用？

用法币输入金额，等于用买卖双方都在想的那种钱给这笔生意定价。终端支持 46 种法币输入金额，屏幕上的数字就是店里自己的价格，柜台上没有人需要把它换算成一个代币数量。

终端上的这笔销售，在买家确认代币和网络时就锁定汇率，转账还没发出。稳定币金额在钱包打开之前已经定死，之后不跟行情走——价格早就在柜台上口头谈定，需要的正是这一点。

不过法币计价并不是终端专属的能力。任何一个开账单的入口都可以按法币填金额，所以一家既有柜台又在线上卖的店，两边用同一种方式定价，跨两个渠道读同一种货币。

输入的货币属于计价，不属于结算。商户余额留在收到的那种资产里，Paymos 不会强制把它换成法币、BTC 或 ETH。

库存和班次留在哪里？

库存和班次是最让人意外的两处缺席，因为两者都像是 POS 的默认配置。终端两样都不带：卖出一件商品不会让任何数字减一，收银员的一天前后也没有东西被打开或关闭。两件事都留在今天所在的位置。

两者里更清楚的是库存。跟踪库存的系统需要知道卖出的是哪件商品；终端收到的是一个金额，而一个金额只固定了价格，没有点名任何商品。这个数字里没有任何信息能告诉库存表该减哪一行。

班次与其说是功能，不如说是一个容器。一个班次意味着备用金、归到一个人名下的销售，以及收工时那次要么对得上、要么对不上的盘点。没有班次对象的收款界面没有可开的东西，所以一天还在终端到来之前收工的地方收工。

这两处缺席指向同一个判断标准：终端处理钱，不处理商品和人。柜台上凡是需要知道「卖的是哪一件」或者「当班的是谁」的活，都不在这张网页上。

什么都不打印，小票从哪来？

出具单据的义务属于卖家，不属于收款界面。终端什么都不打印、也不开具小票，这改变的是由谁来产生这份单据，不是这份单据该不该有。

义务挂在这笔交易本身上，不挂在收款方式上。欧盟委员会的增值税规则把这件事直接放在企业身上：向另一家企业或非应税法人供货或提供服务时必须开具发票，金融和保险这类免税交易除外；对私人个人的销售，是否需要发票由各成员国的规则决定。

对做跨境生意的卖家，这一条的意思很实际：单据义务跟着你卖到哪里走，不跟着钱从哪条链上来。一家欠着单据的店，无论收到的是现金、刷卡还是浏览器终端上的稳定币，都一样欠着。

付款本身仍然会留下记录。终端上的一笔销售在商户账下是一张账单，控制台里有账单搜索、筛选和账单详情——那是一份「收了什么」的记录，不是给客户的那份单据。

为什么不在收银台算税？

税额是一个属地问题，在钱动之前就该定下来。终端不做税费计算，原因是正确的数字取决于一个收款界面永远看不到的信息——在柜台如此，在别处也一样。

该收多少，挂在三件事上：这笔生意做在哪里、卖的是什么、买的人是谁。终端一项都不问；其中任何一项答错，结果都要过几个月才在一份申报表里露出来。

也没有哪个平均值能替代一个设置。全国平均税率不是任何人实际收取的那个数，同一件商品卖到不同地方、卖给不同的人，可能对应两个不同的数字，而这三项输入，付款界面一项也拿不到。

所以终端接收的，是商户自己的税务流程算出来的那个数。那次计算发生在上游，商品和地址都已经确定的地方；到达输入金额这一步的，是已经报给客户的总价。

为什么小费不该做进付款界面？

小费是一个工资体系里的对象，背后连着一条记录链。终端不带小费功能，而一个小费栏会把这条链的最前端放在一块承担不了后半段的屏幕上——一个下游什么都没有的收集点。

收到的小费必须走到几个确定的地方：具体某位员工、这位员工的记录，以及工资核算。终端里既没有班次也没有员工档案，这条链的任何一环都不在这里。

所以诚实的答案就是没有。一个收下了钱却没法归到任何人头上的小费栏，比没有小费栏更糟，因为它产生了一份没有记录支撑的义务，而终端不提供这样一栏。

实际做法其实也不用改。小费今天怎么收、记在哪里，之后照旧；终端只负责这笔销售的金额，那个金额里不含小费。

付款确认之后屏幕怎么处理？

付款确认不会把屏幕收走。结果停在那里，直到收银员按下返回项目，干净的金额输入才出现，供下一笔生意用。终端也没有取消或撤销按钮。

已确认是一个有定义的状态，不是一种乐观判断。终端把一笔付款判为已确认之前要等多深，由网络和金额共同决定——小额可以在更浅的深度上完成，大额会要求更强的门槛，为什么等待时长要按金额分档有一篇专门讲完整策略。

柜台上的动作顺序也是这么来的。确认是交货的信号；把屏幕带回输入金额是另一个动作，收银员在客人走开之后才做。

屏幕不自己清空，反倒是好事。付过款的凭证一直摆在收银员眼前，看完了再收走，中间不会被下一笔生意顶掉。

什么样的柜台适合这个终端？

浏览器终端适合那种记录本来就在别处的柜台。市集摊位、快闪店、服务类生意，以及任何「一笔生意就是一个价格加一次付款、不需要从库存里挑出一行」的收银位。这些柜台缺的正好就是一个收款界面。

同一份清单反过来读，就是排除条件。库存随销售变动的店铺、店员收入含小费的餐厅、成交时必须出单据的场合，三者需要的都是终端之外的系统。

两种读法出自同一份清单，这也正是把它公开的理由。先判断浏览器 POS 终端是不是那块缺的拼图——线上收加密货币的几种做法讲的是它不是的那种情况，一张账单怎么走到已支付讲的是客人打开钱包时柜台在做什么。