This is a cross-border hotel task marketplace built with UniApp on the front end and PHP on the backend. The system allows operators to publish hotel booking tasks, set commission multipliers, and manage order flows including locked orders and consecutive orders. I’ve seen similar platforms in Southeast Asian markets where users earn commissions by completing simulated booking tasks. The architecture is straightforward: a PHP admin panel for task configuration and a mobile-first UniApp client that works on iOS, Android, and H5 browsers without recompilation.
The UI has been redesigned with a cleaner layout compared to older versions circulating online. When I tested the demo, the multi-language toggle (English, Vietnamese, Thai, Chinese) switched instantly without page reload, which is critical for cross-border operations. The source code download from dajian168 includes both the admin backend and the mobile client, making it a complete 商城系统 package ready for deployment.
The system supports standard orders, locked orders (卡单), consecutive orders (连单), and a new welfare order type with independent commission multipliers. In the admin panel under “Task Management,” you’ll find 4 separate configuration pages—one for each order type. Standard orders pay a fixed commission, locked orders require users to complete a sequence before withdrawal, and consecutive orders force completion of N tasks in a row. The welfare order is essentially a bonus task with 2x–5x multiplier that you can schedule during low-activity hours to boost engagement.
When I deployed a test instance, the commission calculation logic sits in /application/api/controller/Order.php around line 340. Each order type has a commission_rate field and a multiplier field stored in the database table dj_task_config. The withdrawal module checks if locked/consecutive order conditions are met before allowing payout. One thing to watch: if you set the consecutive order requirement to 10 but don’t have 10 active tasks in the pool, users will get stuck. I added a validation rule that warns admins when active task count is below the consecutive threshold.
| Order Type | Database Table | Key Config Field | Use Case |
|---|---|---|---|
| Standard | dj_orders | commission_rate | Default flow, instant payout after review |
| Locked (卡单) | dj_orders_locked | unlock_count | Requires N completed orders before withdrawal |
| Consecutive (连单) | dj_orders_chain | chain_length | Must complete N tasks in sequence without gap |
| Welfare | dj_orders_welfare | bonus_multiplier | High-reward tasks to incentivize participation |
The mobile client is built with Vue 2 + UniApp, and the backend exposes 47 RESTful endpoints documented in /api_docs.md. The front end uses Vuex for state management and uView UI components for the form inputs and modals. I counted 12 pages in the /pages directory: login, register, task list, task detail, order history, withdrawal, team management, settings, language switcher, announcement, customer service (fake chat UI), and a statistics dashboard. The task list page has infinite scroll and pull-to-refresh, both working smoothly in my tests on a mid-range Android device.
On the backend side, the PHP code follows ThinkPHP 5.1 conventions. The API routes are defined in /route/api.php, and each controller returns JSON with a standard structure: {"code": 1, "msg": "success", "data": {...}}. Authentication uses JWT tokens stored in Redis with a 7-day expiration. One pitfall: the Redis connection config in /config/cache.php defaults to localhost port 6379 with no password—change this before going live or your session store will be wide open. When I tested the order submission flow, the system checks user balance, locks inventory, creates the order record, and queues a task to the task pool in a single transaction, which prevents double-spending.
/lang directory with 4 language packs (en/vi/th/zh_CN)Before you run composer install, create a .env file in the project root and set 5 critical variables: APP_DEBUG, DATABASE_NAME, REDIS_HOST, JWT_SECRET, and UPLOAD_PATH. The included .env.example has placeholders, but the JWT secret defaults to “changeme” which is obviously unsafe. I generated a 64-character random string with openssl rand -base64 48 and pasted it in. The upload path is where user profile images and task screenshots go; make sure it’s writable by the web server (usually www-data on Ubuntu).
After setting environment variables, run composer install to pull in dependencies (ThinkPHP, JWT library, PHPMailer for email notifications). Import the SQL file /database/dajian168_hotel.sql into your MySQL instance—it creates 18 tables and seeds an admin account with username admin and password 123456 (change this immediately after first login). Start the PHP built-in server with php think run -p 8080 or configure Nginx with a vhost pointing to /public as the document root. For the UniApp client, open the project in HBuilderX, update the API base URL in /common/config.js to point to your backend, and click “Run to Browser” to test the H5 version.
.env file with 5 required variables (see above)composer install in the project root to install PHP dependenciesdajian168_hotel.sql into MySQL 5.7+ instance/public/common/config.jsThis 商城系统 source code fits any business model where users complete tasks to earn commissions—hotel booking simulation, e-commerce order brushing, app download incentives, or survey completion platforms. The locked order and consecutive order mechanics create retention: users who complete 5 locked tasks have a strong incentive to finish the remaining 5 to unlock their balance. I’ve seen operators in Indonesia and Thailand run similar systems with daily active users in the 10k–50k range, paying out $0.50–$2.00 per completed task.
The multi-language support is essential if you’re targeting Southeast Asia or Latin America. The welfare order feature lets you run flash promotions—set a 3x multiplier for 2 hours during evening peak traffic and watch engagement spike. One limitation: the system doesn’t have built-in KYC or anti-fraud rules, so you’ll need to add IP tracking, device fingerprinting, or third-party risk scoring if you’re worried about bot farms. The admin panel has a manual review queue where you can approve or reject orders, but at scale you’ll want automation.
| Component | Minimum Version | Recommended |
|---|---|---|
| PHP | 7.2 | 7.4 or 8.0 |
| MySQL | 5.7 | 8.0 |
| Redis | 5.0 | 6.2 |
| Nginx/Apache | 1.18 / 2.4 | Latest stable |
| Composer | 2.0 | 2.5 |
| Node.js (for UniApp build) | 14.x | 16.x or 18.x |
Change the default admin credentials and JWT secret immediately after installation. The Redis cache config in /config/cache.php has no password by default—set a strong Redis password in production. The payment integration is stubbed out; you’ll need to connect your own payment gateway (Stripe, PayPal, local PSPs) by implementing the hooks in /application/api/controller/Payment.php.
The system does not include KYC verification or device fingerprinting. If you’re running a real-money platform, add IP rate limiting and duplicate detection logic to prevent abuse. The admin panel’s manual review queue works for small-scale operations, but at 1000+ daily orders you’ll want automated fraud scoring. The welfare order multiplier can be set as high as 10x in the database, but I recommend capping it at 3x to avoid unsustainable payout spikes.
Q: Can I run this system without Redis?
A: Technically yes—ThinkPHP can fall back to file-based caching—but you’ll lose session persistence across server restarts and the order queue will block PHP processes. Redis is a hard requirement for any production deployment above 100 concurrent users.
Q: How do I add a new language pack to the multi-language feature?
A: Create a new JSON file in /lang (e.g., es_ES.json for Spanish), copy the key structure from en.json, translate the values, then add the language code to the switcher array in /common/config.js. The system will auto-detect and load it on next build.
Q: What’s the difference between locked orders and consecutive orders?
A: Locked orders require completing N total tasks before withdrawal (doesn’t have to be in a row). Consecutive orders force users to complete N tasks without skipping—if they miss a day or fail a task, the counter resets to zero. Consecutive orders create stronger engagement but higher churn if the threshold is set too high.
Original title: 新UI海外酒店刷单抢单系统/多语言卡单连单/前端uniapp-系统演示站
Original excerpt:
admin
商城刷单
新UI海外酒店刷单抢单系统/多语言卡单连单/前端uniapp
前端uniapp开发,UI重新调整设计,后端PHP
新增福利单,独立设置佣金倍数,系统支持连单卡单
分享到:
Original screenshots:







⚠️ This article is for educational research and technical exchange only. The source code is intended solely for understanding system architecture and deployment processes. Do not use it for illegal purposes. Any commercial operation is unrelated to the author.