TJ PAYMENT HUB / 可信状态
付款页应该负责受控收款，而不是自行编造付款事实。
Payment Hub 接收服务端定价订单，只开放运行时就绪通道，把买家交给获准服务商，并等待可信事件后才更新为已支付。
受控内部记录已经核验支付宝电脑网站支付与微信支付 Native 能力的接入权限，但本公开页面不宣称 TJ NOVA LTD 就是这两个通道的法律商户主体；买家授权付款前，服务商收银台必须展示实际商户主体。本独立 DEV 预览不携带生产凭据，也没有真实资金权限，只有 CNY 权威目录、服务端签名、回调验签与订单账本全部就绪后，通道才会开放。
受控服务商通道
能力证据真实，商户主体与运行门禁也必须说清。
受控权威记录已核验以下获批能力的接入权限；服务商收银台必须展示实际法律商户，且只有当前服务端运行时通过全部启用门禁，买家才会看到可操作入口。
支付宝电脑网站支付
通过官方 alipay.trade.page.pay 交接到支付宝收银台；不宣称也不开放旧的 precreate / 当面付二维码路径。
微信支付 Native
服务端为一笔 CNY 订单生成唯一二维码；API v3 响应与通知都必须验签，原订单状态才能推进。
网站启用门禁
必须具备获批 CNY 目录、独立站点 HMAC 密钥、权威 Hub 地址、HTTPS 回调与实时就绪检查；不会把 USD 价格偷偷换算。
不靠猜的支付
买家只看到一个页面，系统把六个边界分得清清楚楚。
目录权威
产品 ID、价格、币种、交付和状态来自服务端目录。
先建单再结账
每次尝试在服务商交接前先获得可审计订单引用。
服务商就绪
只有通过当前配置与订单约束的通道才能被选择。
回跳不等于事实
页面能展示待处理、已支付、失败或复核状态，但不能自行创造状态。
回调运营
验签事件、重试、发件箱与死信路径在下游故障时保留交付。
退款与争议可见
运营记录把服务商动作、订单历史与证据连在一起；本页不会触发退款。
付款前的 SITEGUARD
先检查成交链并安全停止，再由 Payment Hub 掌握资金边界。
守护与支付各有权威。SiteGuard 观察已配置路径并停在最终付款动作之前；只有 Payment Hub 掌握服务商路由与付款事件事实。
状态合同
从点击结账到交付，只有这一条安全路径。
网关实施包含
- 一个审核通过的店铺接入
- 服务端权威产品目录
- 签名订单与握手入口
- 运行时就绪服务商路由与托管结账
- 验签事件、回调发件箱、重试与死信
- 支付运营与审计交接
order.created → provider.readiness.checked → checkout.handoff.created → buyer.returned (display only) → provider.event.verified → order.payment_state.updated → callback.outbox → ticket + notification + audit → fulfilment.released return_url ≠ paid missing provider contract → 409 / fail_closed
支付问答
不亮任何虚假的绿灯。
打开 Payment Hub 是否代表所有服务商都已接通？
不代表。页面检查运行时就绪状态并禁用不可用服务商；生产凭据与审核是独立门禁。
使用支付宝或微信支付时，我实际付给哪个商户主体？
买家授权付款前，服务商收银台或付款确认页必须展示实际法律商户。受控内部记录只核验获批能力的接入权限，本公开页面不宣称 TJ NOVA LTD 就是这两个通道的法律商户主体。本 DEV 副本尚未发布，也未完成真实付款。
网址参数能修改金额吗？
不能。固定价产品由服务端目录掌握金额；按范围报价产品在获批服务端价格出现前保持为零。
这个 DEV 页面会动真实资金吗？
不会。此独立预览不执行真实购买、退款、提现、转账或结算。
进入支付页面
查看订单、服务商与回跳边界如何协同。
现有 Payment Hub 仍是权威运行时页面；本页是它的公开产品说明。