Payment Gateway (H5)
The payment gateway is a frontend project deployed on the payment gateway domain: the payment pages seen by payers, authorization callbacks from channels and wallets, third-party login relay for the web consoles, and agreement display are all served by it. It does not only serve phones — the web cashier opened in a desktop browser is the same project (one project with PC and mobile page sets, auto-adapted). The payment gateway frontend URL in the backend "Platform Config → Endpoint Config" points to it.
What It Covers
| Responsibility | Path (under the gateway domain) | Who uses it | Details |
|---|---|---|---|
| Payment pages (unified cashier / QR terminal / aggregate) | /cashier/{order-no}, /h/{qr-terminal-no}, /aggregate/{order-no} | Payer | Payment Pages |
| Pay result redirect | /pay-result/{trade-no} | Payer | Payment Pages |
| Transfer confirmation | /transfer-confirm/{transfer-no} | Payee | Payment Pages |
| Payment auth landing | /auth/wechat, /auth/alipay, /auth/douyin | Payer (passes through unnoticed) | Authentication & Relay |
| Agency-operation authorization landing | /isv-auth/alipay | Merchant | Authentication & Relay |
| Third-party login / binding relay | /auth/oauth-callback/... | Admin / merchant web console login users | Authentication & Relay |
| Agreement display | /protocol/{type} | Payer | Authentication & Relay |
There are also three mini-program fallback pages: QR terminal /m/{qr-terminal-no}, aggregate /am/{order-no}, cashier /cm/{order-no} — when a mini-program link is opened in a browser, they show a "please scan with your wallet" guide instead of starting a payment.
Who Generates These Addresses
Most addresses on the payment gateway are not assembled by the frontend itself — they are generated by the backend against the "payment gateway frontend URL": payment links (the pay URL returned to the merchant system by pre-pay), the result pages channels redirect back to, transfer confirmation addresses, auth redirect paths, and the relay entry for third-party login all work this way.
Therefore the payment gateway must be deployed under the payment gateway domain configured in the endpoint settings; the two sides must match, otherwise payers and login users get a 404. This is its biggest deployment particularity — see Deployment & Go-Live.
Division of Work with the Cashier Mini-Program
- Scanning a merchant-presented code inside WeChat / Alipay opens the cashier mini-program to pay;
- Opening a payment link in a browser (from an SMS, email, or web button — phone or desktop) pays on the payment gateway's payment page;
- If the QR code fails to match the mini-program (mini-program not published, plain-link QR code rules not configured), it falls to the gateway's fallback guide page, prompting the user to scan with WeChat / Alipay instead.
The three collection types each have a link prefix per form (same domain, different paths):
| Collection type | Payment gateway (opened in browser) | Cashier mini-program (opened in wallet) |
|---|---|---|
| QR terminal | /h/{qr-terminal-no} | /m/{qr-terminal-no} |
| Aggregate pay | /aggregate/{order-no} | /am/{order-no} |
| Unified cashier | /cashier/{order-no} | /cm/{order-no} |
Desktop and Mobile Adaptation
The same link automatically serves two page sets by device: mobile browsers run the full checkout flow; desktop browsers show the web cashier for the unified cashier, and "please scan with your phone" guides on the QR terminal / aggregate pages. For debugging, append ?device=pc / ?device=mobile to the link to force a form. Page-by-page interactions are covered in Payment Pages.
Related Links
- Payment Pages: unified cashier / QR terminal / aggregate page interactions
- Authentication & Relay: auth landing, agency-operation authorization and third-party login relay
- Deployment & Go-Live: build, deployment and the domain contract
- Cashier Mini-Program: the in-wallet payment form
- Gateway Payment: the business chain behind the payment pages