Does returning from checkout prove payment?

No. The return page displays order state only. A trusted provider event or authorized server review updates payment truth.

Are all payment providers always available?

No. Provider choices are exposed only when runtime readiness, currency, country and order requirements pass. Unavailable rails fail closed.

How does SiteGuard fit before payment?

SiteGuard can check the configured journey up to a safe stop before the final payment action, then hand findings into the same support, ticket and audit path.

TC PAYMENT HUB / TRUSTED STATE

A payment page should route money—not invent payment truth.

The Hub accepts a server-priced order, exposes only runtime-ready rails, hands the buyer to an approved provider and waits for a trusted event before anything becomes paid.

Enter the live Hub surface Read the API contract

Controlled internal records verify access to Alipay computer website payment and WeChat Pay Native capabilities. They do not make a public claim that 西安天澈信息科技有限公司 is the legal merchant for either rail; the provider cashier must disclose that identity before buyer authorization. This independent DEV preview carries no production credential or real-money authority, so every rail stays disabled until its CNY catalog, server signing, callback verification and order ledger are ready.

PAYMENT STATE BUSFAIL CLOSED

01Server orderCanonical product, price, currency and reference

02Runtime gateProvider, country, currency and readiness checks

03Hosted handoffBuyer continues on the approved provider surface

04Trusted eventVerified callback updates order, audit and delivery

Server-owned priceClient amount cannot override the catalog

Runtime-only railsReadiness is checked when the buyer acts

Display-only returnA redirect never becomes proof of funds

Verified event spineOrder, ticket, notice, audit and delivery continue

CONTROLLED PROVIDER RAILS

Capability evidence is real. Legal identity and runtime gates stay explicit.

Controlled authority records verify access to the approved capabilities below. The provider cashier must disclose the legal merchant, and the buyer sees an actionable rail only when the current server runtime passes every activation gate.

ALI

Alipay computer website payment

Official alipay.trade.page.pay handoff to the Alipay cashier. The legacy precreate/face-to-face QR path is not claimed or offered.

WeChat Pay Native

The server creates a unique QR for one CNY order. API v3 response and notification signatures must verify before the same order can advance.

GATE

Website activation gate

Approved CNY catalog, dedicated site HMAC secret, authoritative Hub origin, HTTPS callbacks and live runtime checks are required. No USD price is silently converted.

PAYMENT WITHOUT THE GUESSWORK

The buyer sees one page. The system keeps six boundaries separate.

Catalog authority

Product ID, price, currency, delivery and status come from the server catalog.

Order before checkout

Every attempt receives an auditable order reference before provider handoff.

Provider readiness

Only rails passing current configuration and order constraints can be selected.

Return is not truth

The page can show pending, paid, failed or review state, but cannot create those states itself.

Callback operations

Verified events, retry, outbox and dead-letter paths preserve delivery when downstream systems fail.

Refund and dispute visibility

Operational records keep provider action, order history and evidence connected; no refund is triggered from this page.

SITEGUARD BEFORE PAYMENT

Check the journey, stop safely, then let Payment Hub own the money boundary.

Monitoring and payment have different authorities. SiteGuard observes a configured path up to the final payment action; the Hub alone owns provider routing and payment-event truth.

01SiteGuard journey checkno final payment action 02Payment Hub runtime surfaceprovider-gated 03Order status and returndisplay only 04Signed API and callback contractserver-to-server

STATE CONTRACT

The only safe path from a checkout click to delivery.

Gateway implementation includes

One approved storefront integration
Server-authoritative product catalog
Signed order and handshake ingress
Runtime-ready provider routing and hosted checkout
Verified events, callback outbox, retry and dead letter
Payment operations and audit handoff

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 FAQ

No false green lights.

Does opening Payment Hub mean every provider is connected?

No. The surface checks runtime readiness and disables unavailable providers. Production credentials and approvals are separate gates.

Which legal merchant will I pay on Alipay or WeChat Pay?

The provider cashier or payment confirmation must show the legal merchant before you authorize payment. Controlled internal records verify access to the approved capabilities, but this public page does not assert that 西安天澈信息科技有限公司 is the legal merchant for either rail. This DEV copy is not deployed and has not completed a real payment.

Can a query string change the amount?

No. For fixed-price products the server catalog owns the amount. Quote-required products remain zero until an approved server price exists.

Does this DEV page move money?

No. This independent preview does not perform a real purchase, refund, withdrawal, transfer or settlement.

ENTER THE PAYMENT SURFACE

See the order, provider and return boundaries working together.

The existing Payment Hub remains the authoritative runtime surface; this page is its public product explanation.

Open Payment Hub Check SiteGuard first