Skip to content
西安天澈信息科技有限公司TC Commerce APISigned server-to-server handoff
View runtime contract

TC COMMERCE API / SIGNED INTEGRATION

Give every storefront one accountable route into commerce.

The API Gateway joins an approved site to the TC catalog, order, Payment Hub and callback spine with explicit tenant identity, signatures, idempotency and reliable event delivery.

DEV truth boundary: endpoint contracts exist in this independent copy, but a usable external integration still requires an approved tenant, shared signing configuration, HTTPS callback and production provider readiness. No credentials are shown here.

INTEGRATION CONTROL PLANEHMAC + IDEMPOTENCY
POST/api/integrations/handshakeTenant identity, catalog and callback readiness
POST/api/integrations/orderSigned canonical order ingress
POST/api/tj-payment-eventsTrusted site-payment event intake
OUTSigned callback outboxRetry, dead letter and audit state
Tenant-boundNo anonymous commerce integration
Signed requestsTamper-evident ingress contract
Idempotent ordersRetries do not create duplicate intent
Reliable callbacksOutbox, retry, dead letter and audit

A SMALL PUBLIC SURFACE

Four responsibilities, with secrets and operator actions kept private.

01

Handshake

Confirms tenant identity, enabled catalog and whether HTTPS callback registration is usable before order traffic begins.

02

Order ingress

Receives a signed source reference, customer context and canonical product selection without trusting client price.

03

Payment event intake

Accepts a trusted site payment event under its verification contract; it does not treat browser navigation as an event.

04

Callback outbox

Queues signed downstream events, retries transient failures and isolates terminal failures in dead letter.

05

Operator boundary

Manual retries, provider controls and order status writes remain authenticated, confirmed and outside public routes.

06

No secret leakage

Public pages document shape and boundaries only; signing keys, provider tokens and callback secrets never enter HTML or URLs.

ONE AUTHORITY, TWO PUBLIC VIEWS

Payment explains the buyer journey. API Gateway explains the server contract.

These are not duplicate products. Both lead to the same TC Payment Orchestration Gateway SKU and the same server-authoritative state machine.

FAIL-CLOSED PSEUDOCONTRACT

An integration advances only when every authority agrees.

Required before usable traffic

  • Approved tenant and enabled product catalog
  • HTTPS storefront and HTTPS callback URL
  • Shared signing configuration stored outside content
  • Idempotency key and stable source order reference
  • Runtime-ready provider for the order constraints
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

DEVELOPER FAQ

The integration boundary in plain language.

Is this page public API documentation with live secrets?

No. It documents responsibilities and public route names. Tenant-specific headers, signing material and provider credentials remain private.

What happens when a callback endpoint is down?

The outbox retains the event, retries according to policy and records a terminal failure as dead letter for authenticated operator review.

Does the API replace the payment provider?

No. TC coordinates approved checkout, state and callbacks; the configured regulated provider processes and settles funds.

CONNECT ONE APPROVED STOREFRONT

Buy the gateway once; expose the right view to buyers and developers.

The commercial SKU remains TC Payment Orchestration Gateway at USD 1,999; provider approval and external fees remain separate.