Payment Gateway: Authentication & Relay
Under the payment gateway domain there is another group of pages that do not collect payments: auth landing and relay redirects. Payers usually just "pass through" them — a flash of authorization, then a jump back to the web console. These pages are driven by backend-generated addresses, and the related settings are scattered across the admin console; this page explains where they sit in the whole chain.
Payment Auth Landing Pages (Invisible to the Payer)
When a payment method that requires the user's identity is selected (the JSAPI family of WeChat / Alipay / Douyin), the payment page first redirects to the corresponding platform's authorization page to obtain the openId; after authorization it returns to a landing page on the gateway domain and automatically resumes payment — the payer never notices, at most a single page switch.
| Landing path | Platform | Notes |
|---|---|---|
/auth/wechat | WeChat Official Account web OAuth | Also works in the PC WeChat built-in browser |
/auth/alipay | Alipay authorization | |
/auth/douyin | Douyin silent auth (silent_auth) |
The authorization redirect lands on the environment page of the cashier (/cashier/{order-no}/{environment}), and the payment flow resumes from the breakpoint.
Troubleshooting: if the authorization step reports "domain not registered / invalid callback", most likely the domain registered on the open platform does not match the payment gateway domain — WeChat registers a web authorization domain (bare domain), Alipay registers an authorization callback URL (full address including the protocol); both should be the gateway domain, see Channel Integration.
Agency-Operation Authorization Landing Page (Merchant)
/isv-auth/alipay is the redirect page for Alipay agency-operation authorization in service-provider (ISV) mode: the merchant clicks the authorization link under "Channel Merchants → Authorization Token" in the admin console, confirms on Alipay's authorization page, and comes back here to exchange for the app_auth_token; the token is updated automatically and never passed around by hand. How to initiate: see Admin App - Channel Merchants.
Third-Party Login and Binding Relay Pages
Who passes through: users who sign in with WeChat / Alipay on the admin or merchant web console, or bind a third-party account.
Why a relay is needed: an Alipay app has exactly one authorization callback slot, while login and payment auth share the same AppId — if the login callback used the admin / merchant console's own domain directly, it would crowd out the payment callback (payment auth fails once login is enabled); WeChat Official Account web authorization domains also have registration limits. That is why login / binding callbacks of redirect-type platforms uniformly land on the payment gateway domain, and the gateway then jumps back to whichever console initiated the flow — login and payment never interfere.
Mechanism: the callback path looks like /auth/oauth-callback/{client}/{platform}; the page looks up the target console's callback URL by "client + platform" and relays the authorization parameters onward untouched; account binding uses the same mechanism (/auth/social-bind-callback/...).
From the user's view: a flash-through relay page during login that normally needs no attention.
Configuration and troubleshooting: open-platform registrations for third-party login are maintained in the admin console (see Third-Party Login); if login ends in 404 or fails to return to the originating console, first check that the "payment gateway frontend URL" in the endpoint config matches the actually deployed domain.
Agreement Pages
/protocol/{type}: standalone display pages for the user agreement and privacy policy; links such as those in the payment page footer land here, and the pages can be shared directly.
Related Links
- Overview: the responsibility map and the address-generation mechanism
- Payment Pages: interactions of the payment-facing pages
- Deployment & Go-Live: the domain contract — auth and relay addresses are likewise generated by the backend against the gateway domain
- Third-Party Login: the configuration side on the web console
- Channel Integration: domain registration and joint testing