加密订阅和定期付款：它们的真实运作方式

加密订阅与卡片订阅的运作方式不同，假装否则是大多数集成出错的地方。信用卡可以在下个月再次收费，因为您持有一个令牌，可以提取资金。加密货币没有等效物：没有人可以进入用户的钱包并扣款。因此，真正的定期加密支付是预付访问期——客户付款后，您授予访问权限直到某个日期，当他们再次付款时，您在其上叠加另一个周期。正确理解这个思维模型，其他一切——提醒、宽限期、访问控制——都将迎刃而解。本文解释了加密订阅的实际运作方式，何时优于卡片计费，何时不优，以及如何干净地实现访问逻辑。

为什么加密没有自动收费（以及这没关系）

卡片网络是基于拉取的。当您保存一张卡时，商家存储一个令牌，网络允许他们按计划发起收费。客户每个月并不在循环中。区块链是基于推送的。只有当钱包持有者签署并广播交易时，支付才会发生。没有网关可以重放的持续授权。使用Payora，这一点更是如此——没有任何自动发送，也没有任何自动收费：只有在付款人签署时，支付才会发生，只有在您请求时，资金才会离开您的余额。

人们有时会指出链上“订阅”原语——ERC-20approve()补贴、账户抽象会话密钥或像 Sablier 这样的流媒体协议。这些存在，但它们是小众的、特定于链的，需要用户预先批准支出上限，并增加了真实的用户体验和安全风险。对于 99% 使用 USDT 或 BTC 向客户收费的企业来说，务实的模型是预付续订。这更简单、更安全，并且在您支持的每种币和网络上都能以相同的方式工作。

预付模型：收费，然后叠加 +30 天

这里是整个模式。订阅只是一个 access_until 时间戳在客户的账户上。每次成功付款都会延长它。

• 新注册： 客户支付 30 天的计划。在您确认的 webhook 上，设置 access_until = now() + 30 days.
• 续订： 客户再次付款。您从较晚的时间开始延长——当前的 access_until 如果他们提前付款，或者 now() 如果他们让其失效。这就是 "叠加 +30 天" 规则：access_until = max(access_until, now()) + 30 days.
• 到期：一个计划的任务（或简单的请求检查）将 access_until 与现在进行比较。过期后，访问权限将被撤销，直到下一个付款到账。

使用 max() 很重要。如果有人提前三天续订，你不想浪费这三天——从他们现有的结束日期延长。如果他们晚了一周续订，你从今天开始延长。这一行可以防止两种最常见的账单投诉。

一个具体的例子

假设你销售一个每月15美元的会员，并接受USDT在TRC-20上，因为手续费很低。流程如下：

// on confirmed payment webhook (HMAC-verified)
$sub = getSubscription($userId);
$base = max($sub->access_until, now());
$sub->access_until = $base->addDays(30);
$sub->last_paid_at = now();
save($sub);
grantAccess($userId);

这就是加密会员账单的核心。没有存储卡，没有保险库，没有退款。客户在到期前几天收到发票或付款链接，支付后，webhook会处理其余的。如果他们不付款，访问权限就会结束——没有失败的收费重试，没有发送给无效卡的催款邮件。

卡片定期账单与定期加密支付

这两种模式并没有绝对的优劣；它们优化的方向不同。卡片在无摩擦的保留上占优势。加密在最终性、覆盖面和成本上占优势。以下是诚实的比较：

权衡是明确的：卡片静默续订但因拒付和退款而流失收入；加密货币从不让你意外地出现逆转，但依赖客户在每个周期采取行动。这就是为什么提醒邮件不是可选的——它是你整个续订漏斗。

当每种模型实际上适合时

预付加密订阅在以下情况下表现出色：

• 你的受众是全球性的或加密原生的，并且已经持有稳定币。
• 退款欺诈是一个真实的成本——数字商品、SaaS、成人、游戏、高风险垂直领域。
• 你希望以你控制的资产进行结算，而不是让处理器持有你的余额。
• 年度或季度计划是可行的——更少的续订意味着更少因不作为而流失的机会。

卡片仍然更适合低价、高量的消费者订阅，因为每个周期的任何摩擦都会影响留存率。许多企业同时运行两者，并让客户选择。如果你已经接受一次性加密，添加订阅主要是在你已有的结账上增加一个调度和消息层——见接受没有支付处理器的加密货币用于基础设置。

干净地实现访问控制

保持访问决策简单明了并集中管理。每个受保护的请求都应该问一个问题：是now() < access_until? 不要在代码库中分散订阅逻辑。

1. 存储状态，而不是事件。真相的来源是access_until，而不是一堆支付记录。支付变更该字段；你的应用读取 它。
2. 添加宽限期。 确认的链上支付可能需要几分钟。给出一个小的缓冲期（比如，过期后2-3天），以便在最后一天付款的客户在交易确认时不会被锁定。
3. 从签名的Webhook驱动一切。 仅在Payora发送确认的支付事件时扩展访问，并在信任之前验证 HMAC-SHA256 签名。详细信息见 webhook 签名验证.
4. 在到期前发送续订发票。 提前几天生成支付链接并通过电子邮件发送。这与自由职业者使用的发票流程相同 — 见 用加密货币给客户开票.
5. 一键续订。重用客户首选的币种和网络，以便回归会员每月不必重新选择链。

对于续订，确认的资金会根据您配置的结算模式进行记账：默认情况下，您可以查看内部 余额 并在您的时间表上将其转出，支付 您的计划费用（免费计划为1.5%）加上仅在您提款时收取的币种网络费用（最低$50），而不是在您接受时。批准的直接结算是特定于账户的，视支持情况而定。保持续订费用低也是值得一读的：减少加密支付费用.

常见错误需避免

• 延续自 now() 在早期续订上 — 你窃取了客户支付的天数。始终 max(access_until, now()).
• 在时钟一到的瞬间撤销访问 — 确认交易看起来像是未付款。使用宽限期。
• 信任未签名的 webhook — 任何人都可以 POST 到你的端点。验证签名，否则你将发放免费会员资格。
• 在用户界面中承诺 "自动续订" — 这是预付的。说 "在你付款时续订"；这里的诚实可以防止支持票。

开始

加密订阅不再神秘，而是更注重纪律：预付周期、一个 access_until 字段，以及一个堆叠时间的签名 webhook。这是一个你可以在下午完成并永远思考的模型。创建一个免费的 Payora 账户 获取 API 密钥，将你的续订与 SDK 和 webhook 文档，或者先试试 实时结账演示 以查看你的会员将使用的支付流程。当你准备好时，设置托管结账、发票和支付链接 并开始在你的客户已经持有的 20 多种币种中进行收费。