Epay and Rainbow Pay are industry names for a protocol family: shared-key signing with fixed parameters. Xiaodou Open Platform provides protocol compatibility for that family. It is not a no-sign or fourth-party collection service: buyer payments are collected and settled by a licensed payment company into the merchant's own settlement account, and the money does not pass through an intermediary account.
What compatibility means
The compatibility layer accepts the requests your existing plugin sends and returns results in the same protocol shape. Your plugin keeps its behavior; only the three configuration values change. The supported endpoints are submit.php, mapi.php and api.php, using the same parameters and signature rules as the protocol family.
The three values
| Setting | What to enter |
|---|---|
| Gateway URL | The address shown on the "Epay configuration" page in the merchant portal. Dujiaoshuka requires the full address including /submit.php; V2Board uses the base URL. |
| Merchant ID | The merchant number generated in the portal. |
| Merchant key | The shared key generated in the portal. Enter it only in your plugin configuration. |
Supported endpoints
| Endpoint | Purpose |
|---|---|
submit.php | Form checkout with a page redirect. |
mapi.php | Programmatic checkout that returns payment information. |
api.php | Query: act=order for an order, act=query for transactions. |
Keep using the same entry point your plugin already sends to.
Which systems can switch
| System | Verification status | Note |
|---|---|---|
| Dujiaoshuka (also called Dujiaoshou Faka) | Source-level review completed | Enter the full gateway address including /submit.php |
| V2Board | Source-level review completed | Enter the base gateway URL |
| Other similar plugins | Ecosystem registration only; no source-level review | Same protocol family; verify with your actual version and one small real order |
Every migration is accepted only after one small real order passes order creation, webhook delivery and order query. Then switch production traffic.
Migration steps
- Enable the "Epay configuration" page in the merchant portal.
- Copy the gateway URL, merchant ID and merchant key.
- Fill the three values into your plugin.
- Verify order creation, webhook delivery and order query with one small real order.
- After it passes, switch production traffic.
Supported scope
- Alipay: available now.
- WeChat Pay: WeChat JSAPI is available when the buyer opens the cashier inside the WeChat browser. Mobile browsers outside WeChat and native apps have no direct invocation form.
- QQ Wallet: not supported. If your plugin offers it, switch to Alipay or WeChat Pay.
What is not covered
- No RSA signature form; this is a shared-key protocol compatibility layer, not the signed merchant API.
- No API refunds through this layer; use the merchant portal or the signed merchant API refund flow.
- No batch queries, settlement account changes or direct QR code output.
- No no-sign or fourth-party collection service.
FAQ
Is this an official partnership with Epay or Rainbow Pay?
No. This is protocol compatibility only. We do not claim an official partnership or certification. Funds are still collected and settled by a licensed payment company into your own account.
Do I need to change my system's code?
No. The plugin only needs three values: the gateway URL, the merchant ID and the merchant key. The compatibility layer translates the request into the Xiaodou payment chain.
Which endpoints are supported?
submit.php for form checkout, mapi.php for programmatic checkout, and api.php for order and transaction queries with act=order or act=query.
Can I accept WeChat Pay through this compatibility layer?
Yes. WeChat JSAPI is available when the buyer opens the cashier inside the WeChat browser. Mobile browsers outside WeChat and native apps have no direct invocation form.
Does the compatibility layer support API refunds?
No. Refunds are initiated from the merchant portal's completed orders page or through the signed merchant API refund flow, not through the Epay compatibility endpoints.
How should I verify a migration?
Run one small real order and verify order creation, webhook delivery and order query. Only then switch production traffic.