本页内容
安全
了解 Paymos 如何用隔离的转出签名、目标地址白名单、HMAC 认证、签名 webhook、SSRF 防护和审计记录保护代币余额。
Paymos 是托管型网关——链上移动你资金的密钥由我们保管。这给每个商户带来一个合理的问题：是什么阻止 Paymos 拿走我的钱，出了问题又会怎样？
本页回答这两个问题——先给出简短的承诺清单，再用平实的语言逐条解释背后的逻辑。它描述平台给你的保证及其实际价值，而不是内部蓝图。凡属公开 API 的细节（如何签名请求、如何验证 webhook），我们都精确记录，因为你集成时需要。
为什么你的资金是安全的
受控的目标地址与隔离签名
- 隔离的签名基础设施。 Paymos 把托管和签名路径与公开 Web 面隔离运行。这是受管托管，不是商户直接掌控密钥。
- 强制白名单。 资金只能转到你事先批准的目标地址。即使你的 API 凭证全部失陷，也无法凭空造出一个新的收款地址。
- 默认仅账户所有者可操作。 转出权限和编辑白名单的权限默认保留给账户所有者，除非你显式委托——每次授权都有日志。
- 按你的节奏转出。 付款达到最终性那一刻，余额就是你的。我们不锁定资金。每小时转、每天转，或不转：请求和发出的交易之间没有批量窗口，也没有排队，之后走多久由链本身决定。
- 隔离的余额。 每个商户的余额单独记账。我们不归集商户资金，不出借，也不再质押。
你的钱不会悄悄消失
- 按网络和金额选定的确认深度入账——足以让重组变得罕见，但不足以称之为不可能。
- 不追回。 一旦我们告知付款已确认，就绝不撤销。如果已确认的付款后来被重组丢弃，损失由 Paymos 承担——不是你。
- 转出不会重复发送。 每笔转出都携带你自己的幂等键。
- 分层冻结控制可在链上实况偏离账本时自动冻结单个资产。
- 流动性提前校验，转出要么快速失败，不会卡住。
- 防篡改记录：每个特权操作都有审计，密钥和签名在写入记录前先被清除。
不追回。 一旦我们告知付款已确认，就绝不撤销。如果已确认的付款后来被重组丢弃，损失由 Paymos 承担——不是你。
本页其余部分用平实的语言逐条解释。如果你见过 HMAC 或 SSRF 这些词却不知其意——继续读。
威胁模型
我们的防御设计针对：
- 静态资金——可能移动链上余额的密钥
- 在途资金——转出授权与目标地址篡改
- API 访问——凭证窃取、请求重放、越权
- Webhook 投递——伪造负载，以及把我们的基础设施当作 SSRF 跳板打进你的网络
- 运营风险——误删操作、多服务器竞态、审计缺口
明确不在范围内：你客户的钱包安全（他们自管密钥）、转出签名后的接收方风险（链上交易是最终的）、你与 Paymos 并行运行的第三方服务，以及针对你团队的社会工程。
转出签名与目标地址控制
问题所在。 区块链上的资金由签名密钥控制。凭证被盗、目标地址被改、签名主机失陷，都可能变成资金损失事件——除非周围的控制全部以失败关闭（fail-closed）的方式工作。
Paymos 的做法。 出账交易在隔离的基础设施上签名。转出只能发到商户白名单中已存在的地址，白名单为空则转出完全不可用。改白名单是一个单独动作，会写进审计日志；如果操作的用户已经启用第二因素，这次修改还要当场再过一道升级认证。账号没有第二因素，就没有可验的东西——这一层从你启用它的那天才开始生效。
事件调查期间，运营方可以停止全部出账转账，或冻结单个资产-网络组合。每笔转出还携带幂等键，重放同一请求不会产生第二笔付款。
这仍然是托管基础设施：签名路径由 Paymos 运营。目标地址控制、冻结、审计记录和账本对账降低托管周边的风险；它们并不把托管变成非托管或门限托管。
每张账单都有自己专属的充值地址，因此对账没有歧义。沙箱付款和转出不接触真实资金，你可以在不产生生产转账的情况下测试集成。
HMAC——API 如何确认请求真的来自你
HMAC 全称 Hash-based Message Authentication Code（基于哈希的消息认证码）。名字唬人，原理简单。
问题所在。 你的服务器发来"创建一笔 1000 美元的转出"。我们有两个问题：这真的是你，还是冒充者？请求在传输中有没有被篡改——金额或地址被改？如果只是把密码放进请求里，任何截获流量的人都能偷走它并冒充你发请求。
HMAC 的做法。 你和我们共享一个密钥（你的 API secret）。对每个请求，你计算一个"指纹"（签名）——请求内容与密钥一起的哈希。你发送请求和指纹，但不发送密钥。我们用自己那份密钥重算同一个指纹。两者一致，就证明确实是你，并且内容未被改动——改动任何一个字符，指纹都对不上。
类比。 信封上的火漆印。密钥是你独有的印章。人人都能看到印记，但没有印章就无法伪造。信被拆开重写，印记就不再与内容相符。
关键点：密钥本身从不在网络上传输。即使攻击者录下你的全部流量，也无法提取密钥或伪造新请求——他们手里的只是你已发请求的签名。（SHA-256 就是那台把任意输入碾成定长、不可逆指纹的"磨盘"。）
精确格式（供集成使用）
每个认证请求携带两个请求头：
Authorization: HMAC-SHA256 {api_key_id}:{base64(signature)}
X-Request-Timestamp: {unix_seconds}
签名是对规范字符串计算的 HMAC-SHA256：
{timestamp}\n{METHOD}\n{path}\n{query}\n{sha256_hex_lower(body)}
空 body 在该位置贡献空字符串——不参与哈希；查询参数按 URL 中的原样参与签名。完整细节见 认证 页。
防重放保护
攻击者能不能重发录下的旧请求——把"创建转出"重放一百次？时间戳是签名的一部分，任何 X-Request-Timestamp 与服务器时间偏差超过 ±5 分钟的请求都会被拒绝（返回 401）。录下的请求活五分钟，然后作废。再结合幂等（见下），即使在这五分钟内重放"创建转出"，资金也不会重复发出。
类比。 一张入场窗口只有五分钟的票——昨天的票没用。
恒定时间比较
比较两个签名时，朴素比较会在第一个错误字符处停下——响应时间会泄露已经猜对了多少个字符，让攻击者逐字节猜测。我们用恒定时间比较：无论你猜对了多少，"不匹配"耗时完全相同。
类比。 一把密码锁，无论你猜对一位还是五位，"不对"的回答耗时都一样。你无法感知自己"越来越接近"。
密钥类型与轮换
两种密钥类型，各自固定作用域，由服务器对每次调用强制检查：
- Payment key——钱进来的一切：创建和查询账单，管理收款通道并读取其充值记录。不能读余额，不能创建转出。
- Payout key——创建、查询和取消转出，读取余额。不能创建账单，也够不到收款通道。
密钥轮换零停机：先生成新密钥，旧密钥在 previous_secret_expires_at 前保持有效，这个时间点固定是轮换后 24 小时。窗口写死，不是可以传的参数。窗口没关之前两把密钥都接受，之后只有新密钥可用。
Webhook 安全——同一套 HMAC，方向相反
上面的 HMAC 保护你发给我们的请求。Webhook 是我们敲你的门（"账单已支付"）。同样的技巧反过来用：我们用你的端点密钥给每个 webhook 签名，你在信任之前先验证。否则任何知道你 webhook URL 的人都能发一个假的"已支付"事件，骗你发货。
X-Webhook-Signature: t={unix_seconds},v1={hex_hmac}
被签名的负载是 {timestamp}.{request_body}。该方案与 Stripe 一致，验证 Stripe webhook 的库几乎不用改就能用；密钥轮换期间我们在同一请求头中同时发出两个签名。见 验证 Webhook。
SSRF 防护
SSRF 全称 Server-Side Request Forgery（服务端请求伪造）。你设置一个 webhook URL，我们的服务器向它发请求。聪明的攻击者把 URL 不指向外部，而指向我们网络内部——云元数据地址或内部面板——让我们的服务器替他抓取，把 Paymos 变成访问内网的代理。
我们的防御：webhook 目标必须解析到公网地址——拒绝回环、私有、内部和云元数据地址段——并且连接固定到已验证的地址，不留 DNS 重绑定窗口。重定向一律拒绝。验证不通过的目标立即丢弃，探测无法消耗投递预算。
类比。 一个只往真实外部地址送货的快递员，拒绝送"到本楼自己的机房"，出发前核对地址，也不理会"其实改送那边吧"的纸条。
投递语义
Webhook URL 必须使用 HTTPS（保存端点时强制）。投递为 at-least-once——在你侧按事件 ID 去重（Stripe、GitHub、PayPal 的通行约定）。失败的投递按指数退避重试，共 11 次尝试，横跨约 16 小时——完整时间表见 投递与重试——之后标记为失败，可在控制台重放。每次尝试有独立的超时。
转出保护——层层上锁
资金转出是托管型网关的生死线，因此层数最多：
- 白名单（强制）。 转出只能发到你事先批准的地址。某网络族的白名单为空时，完全无法创建转出——没有"第一笔转出顺带登记地址"的捷径。即使密钥被盗，资金也只能转到你自己的钱包，盗钥失去意义。类比：一个只能向预登记收款人列表汇款的账户——拿到你密码的小偷也无法添加新收款人。
- 仅所有者。 创建转出和编辑白名单属于账户所有者，不属于普通管理员角色。你必须显式授予非所有者，且该授权可审计。
- 双因素（2FA）。 认证器应用的六位验证码，每 30 秒变化；登记过的通行密钥同样算第二因素。它默认不开，要你自己启用——而启用它，正是升级认证生效的开关：账号有了第二因素之后，改转出白名单、改 API 密钥的 IP 白名单、关掉第二因素本身，都要在执行那一刻现给一次验证。
- 冻结控制（断路器）。 我们可以一次冻结全部、冻结单网络上单代币，或冻结单商户。如果链上余额偏离账本超过安全余量，单资产冻结可以自动触发。
- 提前流动性校验。 转出在受理前先对可用资金（含手续费）校验，立即以明确错误失败，而不是卡住。
- 幂等。 你的订单标识就是幂等键——发两次，返回同一笔转出，绝不产生第二笔转账。类比：寄存牌；同一张票交两次，取回的还是同一件外套。
- 竞态安全的创建。 同一账户的并发转出请求在服务端串行化，两个并行调用无法钻过同一次余额校验。
授权与隔离
- 每个请求都先经服务端检查再执行：环境必须匹配（沙箱 vs 生产）、调用方类型必须被允许、凭证作用域必须覆盖该操作、资源必须属于调用方。这些检查才是真正的边界——UI 控件只是提示。
- 返回 404，而非 403。 资源不存在，或存在但不属于你，都返回
404。攻击者无法区分"这个 ID 真实存在但不是你的"和"这个 ID 不存在"。类比：门卫一律说"查无此人"，无论那人不存在，还是住在这里但你无权上楼。 - 你的身份来自凭证，绝不来自请求体。 在请求里放别人的标识没有任何作用——你无法靠伪造 ID 代替其他商户行事。
- 细粒度权限。 访问由细粒度、按角色的权限控制（如转出、查看余额、管理 webhook），每项可独立授予。服务端检查是边界；控制台与之镜像。
限流
每个商户有独立的限流额度。超限时你会收到带 Retry-After 请求头的 429 Too Many Requests，因此单个失常的集成只能影响自己的吞吐，影响不到平台和其他商户。
链上最终性——为什么你的钱不会消失
在区块链上，交易很快"出现"在区块里，但链仍可能改写近期历史（"重组"）——看似已确认的东西可能消失。像未干的墨迹：写上了，但还可能被抹花。
最终性意味着等到交易被埋得足够深、无法逆转。墨迹干了。我们等到每个网络各自的最终性才动你的余额。在最终性取决于确认深度的链上，该深度随金额伸缩——小额快速清算，大额多等一会；具有原生即时最终性的链在区块最终时即结算。这些阈值按网络状况调优，不是固定值。
核心承诺：如果我们已确认的付款后来被重组丢弃（极少见），损失由 Paymos 承担，不是你。 确认 webhook 一旦触发，你可以立即据此行动。额外的好处：没有拒付（不像银行卡，买家可在交易后数月内撤销），且迟到的付款在设计上不可能——账单过期后确认的付款不会记入已过期的账单。
数据保护
传输中： 所有流量使用 TLS 1.2+，生产环境启用 HSTS，未加密请求重定向到 HTTPS。
静态： 会话 cookie 为 HttpOnly、Secure、SameSite=Strict；登录链接一次性使用、快速过期、静态加密存储。
防伪造： 改变状态的控制台操作携带防伪造令牌，与 SameSite=Strict cookie 一起缓解跨站请求伪造。
审计日志： 每个特权操作记录操作者、执行内容、结果和时间。敏感值——密钥、密码、令牌、哈希、签名——在写入前脱敏，写入时强制。
运营韧性
- 多服务器安全。 跨多台服务器运行绝不会重复处理付款、转出或 webhook——同一事项的并发工作被协调为恰好执行一次。由自动化测试验证，不是假设。
- 隐私安全的错误上报。 崩溃报告在离开我们的系统前清除个人数据和请求内容。
- 自愈基础设施。 自动健康检查把不健康的实例移出轮转。
- 安全的模式变更。 数据库迁移按序应用一次，只向前——我们绝不对生产数据做破坏性回滚。
合规与数据处理
开始不需要 KYC。 无需提交身份、地址或受益所有人文件即可注册并开始测试，Paymos 也不向你的客户收集这些文件。Paymos 不审查你的业务、不核查牌照、不筛选商户类目，也不对你的客户做制裁筛查；这些义务仍由商户承担。如果活动需要人工审核、超出账户限额，或主管机关要求，我们可能随后要求 KYC/KYB，详见我们的 AML/KYC 政策。
客户侧数据。 按设计，Paymos 在收银台不收集你客户的任何个人数据——没有邮箱、电话、姓名或卡数据。流程是：账单 → 付款页 → 钱包支付 → 完成。我们看到的是钱包地址和金额，不是身份，因此你经由 Paymos 的 GDPR/CCPA 敞口实际上为零。
商户侧数据。 对你的账户，我们持有企业名称、联系邮箱、国家和项目元数据（webhook URL、API key 标识）。GDPR 删除请求触发 30 天软删除，随后永久清除；审计轨迹只保留被删记录的哈希。
数据驻留。 主要数据存储在欧盟。企业合同可指定区域——联系我们。
我们不做什么
- 不声称尚未建成的东西。 本页描述的是已部署的系统。路线图项目在发布前不列出。
- 不超时托管。 付款确认那一刻资金即到你的余额；转出时机由你选择。
- 不归集商户余额。 每个余额单独隔离。一个商户的资不抵债或纠纷碰不到另一个商户的资金。归集到同一个池子正是 FTX 这类交易所沉没的原因。
- 不承诺接收方侧安全。 转出一旦签名，交易即在链上且最终。白名单防的是笔误和盗钥——它无法验证你批准的目标地址会规矩行事。
报告漏洞
请将披露发送至 [email protected]。
- 回执确认： 收到完整报告后两个工作日内
- 范围： 生产环境
paymos.io和*.paymos.io、生产 REST API，以及 Paymos 发布的 SDK 和 CMS 插件 - 范围外： 基于限流的拒绝服务、社会工程、第三方服务（你的 CDN、托管商等）
- 漏洞赏金： 目前没有公开计划；重大发现的私下披露按个案奖励，可应要求致谢
请不要对其他商户的账户做测试，不要对生产环境做破坏性测试，在我们修复前不要公开披露。我们承诺在收到完整报告后的两个工作日内回执确认、持续通报修复进展、发布时（经你许可）署名致谢，并且不对范围内善意研究采取法律行动。