跳到正文
TJ NOVA LTDTJ Commerce API签名服务端交接 English
查看运行时合同

TJ COMMERCE API / 签名集成

让每个独立站都通过一条可追责路径进入商业闭环。

API Gateway 通过明确租户身份、签名、幂等与可靠事件交付，把获准站点接入 TJ 产品目录、订单、Payment Hub 与回调主干。

查看集成页面查看买家付款流程

DEV 真实边界：此独立副本中存在端点合同，但可用外部集成仍需获准租户、共享签名配置、HTTPS 回调与生产服务商就绪。本页不展示任何凭据。

集成控制面HMAC + IDEMPOTENCY
POST/api/integrations/handshake租户身份、目录与回调就绪
POST/api/integrations/order签名权威订单入口
POST/api/tj-payment-events可信站点付款事件接收
OUT签名回调发件箱重试、死信与审计状态
Tenant-bound不允许匿名商业接入
Signed requests可识别篡改的入口合同
Idempotent orders重试不重复创建意图
Reliable callbacks发件箱、重试、死信与审计

精简公开接口

四项公开职责，密钥与运营动作保持私有。

01

握手

在订单流量开始前确认租户身份、启用目录与 HTTPS 回调登记是否可用。

02

订单入口

接收签名来源引用、客户上下文与权威产品选择，不信任客户端价格。

03

付款事件接收

按验证合同接收可信站点付款事件；浏览器跳转不会被当作付款事件。

04

回调发件箱

排队签名下游事件，重试临时故障，并把终止故障隔离到死信。

05

运营边界

人工重试、服务商控制与订单状态写入保持鉴权、确认，并处于公开路由之外。

06

不泄露密钥

公开页只说明结构与边界；签名密钥、服务商令牌与回调密钥绝不进入 HTML 或网址。

一个权威，两种公开视角

Payment 解释买家旅程，API Gateway 解释服务端合同。

这不是重复产品。二者都指向同一个 TJ Payment Orchestration Gateway SKU 与同一套服务端权威状态机。

01面向买家的 Payment Hub产品视角 02运行时集成页面可用界面 03付款前成交链守护安全停止 04完整 SiteOS 运营流程端到端

失败关闭伪合同

只有每个权威条件都同意，集成才继续。

可用流量前必须具备

  • 获准租户与已启用产品目录
  • HTTPS 店铺与 HTTPS 回调网址
  • 存放在内容之外的共享签名配置
  • 幂等键与稳定来源订单引用
  • 满足订单约束的运行时就绪服务商
handshake(site, signature)
  if !approved_tenant → reject
  if !https_callback → reject

order(product_id, source_order_id, idempotency_key)
  amount = server_catalog[product_id]
  if !runtime_provider → fail_closed

provider_event(signature, provider_reference)
  if !verified → quarantine
  update(order_state)
  enqueue(signed_callback)
  retry → dead_letter → audit

开发者问答

用大白话说清集成边界。

这是带真实密钥的公开 API 文档吗？

不是。本页只说明职责与公开路由名；租户专属请求头、签名材料与服务商凭据保持私有。

回调端点宕机时怎么办？

发件箱保留事件、按策略重试，并把终止故障记录为死信供鉴权运营人员复核。

这个 API 会取代支付服务商吗？

不会。TJ 协调获准结账、状态与回调；配置的受监管服务商负责处理和结算资金。

连接一个获准独立站

购买一套网关，分别给买家与开发者展示正确视角。

商业 SKU 仍是 USD 1,999 的 TJ Payment Orchestration Gateway；服务商审核与外部费用另计。

选择网关咨询集成