用余额购买：退款在哪些情形下有效

收银台里有四种付款方式，它们的差别不只在手续费，还在于从付款到发货之间要过多久。

加密货币方式里转账金额唯一不是任性，而是识别付款的手段：系统正是靠它在众多转账里找到你那一笔。所以不能把金额凑整，也不能「差不多这么多」地发过去。

• 收银台给出的金额不要凑整 — 付款正是靠它来识别的。
• 加密货币付款要等网络确认，用余额付款什么都不用等。
• 手续费在收银台里就标在方式旁边：CryptoBot 是 5 %。
• 余额充值用的方式和支付订单的一样。
• SBP 的二维码要用手机自带的「相机」打开，而不是银行 App 里的扫码。

充值余额时可选的也是同一套：余额用支付订单的那些方式来充。区别只在时点 — 你是提前一次性付款，而不是每次购买时单独付。

余额解决的是一件事 — 去掉等待。直接用加密货币付款时，从发出转账到发货之间要过网络确认的时间，而这段时间里商品可能已经被买走：目录里的库存是活的，会变。用余额付款时扣款立刻发生，订单组装当场就开始。

第二个用途是定期采购。通过 API 工作的脚本没法在每一轮迭代里都等转账确认；它用的是余额，余额提前充好，随着下单逐步消耗。

库存这件事值得单说。带即时发货的商品是马上就走的，但目录里的数量是活的，从你决定买到转账被确认之间，它可能已经变了。余额去掉的正是这个缝隙。

还有第三个效果，不太显眼。30 分钟的检查窗口是从购买开始算的，不是从开始付款算的。在扣款之前你做的一切都不消耗窗口 — 而用余额付款，把等待网络的那几分钟从窗口里拿掉了。

渠道之间最主要的差别就在这里，而且从收银台看不出来。「退款」这个词描述的是三套不同的机制，究竟哪一套会生效，取决于故障发生在哪里，而不是取决于你怎么请求。

• 通过 API 用余额付款：发货失败时款项自动退回余额。
• 在网站或机器人里付款：没有自动退款，但发货没有发生时款项根本不会被扣。
• 按保障更换：如果账号首次登录进不去而又没有可换的，款项退回商店余额。

共同的规则只有一条：退款退到余额，不退到银行卡。商店根本不做自动退回银行卡这件事，选择充值金额时值得把这一点算进去。

这个清单里没有第四种情形 — 「因为改主意了所以退钱」。商品是数字化的、即时交付的，所以退款绑定的是发货故障，或者商品与描述不符，而不是买家的决定。

第一种和第二种情形的差别在于：故障由谁来处理。在 API 里由商店自己处理，不需要人介入。在网站和机器人里，失败时钱不会走，而争议情况通过客服人工处理 — 对一次性购买来说这没问题，但不适合成批的订单。

商店所有的联系渠道都在 Telegram：频道和客服机器人。商店不使用电子邮件，没有电话也没有办公室。网站分析也没有接，所以「看看你那次访问里发生了什么」谁也做不到 — 处理是按订单号来的。

这样的联系方式看着很简朴，但它有反面的好处：处理与你用什么设备、什么浏览器购买无关。订单号在任何渠道里都同样能找到这笔购买。

由此得出联系客服的做法：订单号和商品编号。有这两个值就足以找到购买，没有它们处理就开始不了。两个值在个人中心都看得到，而商品编号还写在商品卡片上，也能在目录搜索里用。

• 看不到交付内容 — 先在个人中心打开订单：数据留在那里，可以重复下载。
• 商品与卡片不符 — 客服机器人、订单号、商品编号，在 30 分钟之内。
• 付款走了而订单没组装成 — 在网站和机器人里款项不会被扣，通过 API 用余额付款时它会自己退回。
• 商店不承诺响应时间：目录、付款和交付自动运行，客服按繁忙程度回复。

联系时最好不要写的，是「账号两天之后不能用了」这类描述。商店明确说明交付之后账号的表现不作保证，这样的工单没有可处理的对象。谈论的对象是交付那一刻的状态。

关于退款要记住一点：它永远退到商店余额。余额里的钱可以支付下一个订单，但商店不承诺把它按原路提出来 — 这会影响到一次充多少钱才合理。

组装需要一到两分钟，最多五分钟。数据会自己出现在订单页面上，不用刷新页面，并保留在个人中心和 Telegram 机器人里。商店不发邮件通知 — 它根本不使用电子邮件，所有联系都走 Telegram。

订单不会消失：交付内容可以重复复制或下载成文件，也可以按单个商品下载。这一点在最初的 30 分钟里很重要 — 如果复制时丢了什么，不用去找客服，在个人中心打开订单就行。

重复下载还有另一个好处：交付内容可以按订单里的单个商品取，而不是一次全取。对由几个商品编号组成的大额采购来说，这比去拆一个总列表要省事得多。

从这一刻起验收开始，它同样是交易的一部分。核对数据行的构成、把交付跑一遍转换器、抽样登录 — 做完这些再去改密码和绑定信息：检查结束之前的任何修改都会让更换保障失效。