Payment Product Configuration
A payment product is the carrier of "which payment methods a merchant can use": merchants pick a product when provisioning a channel merchant, and the product's capabilities decide what they can initiate. When the platform connects to channels as a service provider (ISV), the product-level keys, certificates and apps are also maintained here. Menu: Payment Management → Access Configuration → Payment Product Configuration.
Three-Layer Model: Channel → Product → Capability
| Layer | Examples | Description |
|---|---|---|
| Payment channel | WeChat, Alipay, Lakala | The payment institutions integrated |
| Payment product | WeChat Pay (ISV), WeChat Pay (direct), Lakala | One channel can hold several products; ISV and direct are different products |
| Payment capability | JSAPI, Mini Program, barcode, H5, QR | The checkout capabilities a product offers under each payment method |
The product catalog is built into the system and cannot be added to or removed. To see which products exist and which capabilities each mounts, open the read-only page Payment Management → Payment Master Data → Payment Products.
The Product Configuration Page
The page is a grid of product cards, each showing the product icon, name, enabled status (green/grey dot) and two entries at the bottom:
- Production config: opens the production environment detail of the product;
- Sandbox config: appears only when the product supports sandbox and the platform sandbox switch is on.
The environment radio (production/sandbox) in the card's top-right corner switches the product's active environment, with a confirmation dialog. The sandbox switch is a deployment setting: production deployments must disable sandbox, in which case no sandbox entry appears anywhere in the UI (see Configuration).
The Configuration Detail Page
From a card you enter the detail page:
- The product enable/disable switch is in the top-right corner. Disabling blocks new payments, while refunds, syncs and callbacks of existing orders are unaffected; re-enabling restores everything.
- The page dispatches to the product's config sub-page. Only products that need platform-level configuration (mostly ISV/aggregated modes) have one, for example:
| Product | Configuration content |
|---|---|
| Alipay (ISV) | ISV app management: app ID, keys (public-key/certificate modes), sub-merchant authorization |
| WeChat (ISV) | ISV merchant number and API certificate/key, WeChat app management, product-level default payment apps |
| Lakala | ISV keys (app ID, institution code, certificate serial, key pair), WeChat app association |
| Adapay/Dougong, Leshua, Fuyou, Shengpay etc. | Similar structure: ISV keys/certificates + WeChat app binding |
Direct-mode products (Alipay direct, WeChat direct, UnionPay, Douyin, Stripe, UMS series, etc.) have no product-level config page — their keys are configured on each channel merchant instead, and the detail page shows a "not supported" notice.
Configuration completeness badge
Sub-page cards carry a check badge in the top-right: a green check means all required items (ISV keys, default apps, etc.) are complete; an orange exclamation mark means something is missing. Finish configuring until the badge turns green — payments that depend on a missing item may fail.
Environments and Sandbox
The environment mechanism is designed for sandbox integration testing:
- Global switch: the deployment setting
daxpay.platform.config.sandbox-enabled. Production must set it tofalse(on startup with the switch off, the system also force-resets any leftover sandbox products back to production); test environments may enable it. - Switching does not rewrite existing records: switching a product from sandbox back to production only affects the default environment of future channel merchants and routing targets; existing sandbox channel merchants keep their flag — one product can carry both sandbox and production merchants.
- Routing validates environment consistency: a sandbox channel merchant can only be hit by a sandbox product and vice versa; on mismatch the payment is rejected by routing with an explicit message naming the mismatched channel merchant and product.
So after finishing sandbox testing and switching environments, provision new channel merchants for production and update routing — do not reuse the sandbox-era ones.
Relationship with Channel Merchants and Routing
Payment product (keys/apps, enable/disable, environment — this page)
└── Channel merchant (product chosen at creation, environment flag frozen)
└── Routing (maps channels/payment methods to channel merchants)A disabled product or an environment mismatch is rejected at the routing stage. When troubleshooting "payment failed", check product status and environment first, then channel merchants and routing.
Related Links
- Channel Merchants — provisioning channel merchants per product
- Routing — environment validation and route interception