Multi-language Local Task System Build Log: Vue Frontend + PHP Backend Deployment Notes

I recently helped a client deploy a local task system targeting the Vietnamese market, with a fully open-source Vue frontend and PHP backend. Honestly, this combination of “task betting + system lottery” is quite common in Southeast Asian gray markets. The client wanted something they could launch quickly, customize on their own, and didn’t cost a fortune. After a week of tinkering, here are the key takeaways for site owners with similar needs.

Core Features Hands-on Review

This system bundles “task publishing + lottery drawing + user fund flow” together, with a very clear positioning. Let me break it down into three parts.

Vue Multi-language Frontend Architecture

The frontend is built with Vue 2, defaulting to Vietnamese, with language switching handled through the standard vue-i18n approach. Language packs are stored under src/lang, currently built-in with Vietnamese, Chinese, and English. The switching logic is written in the router meta, paired with a global mixin for on-demand loading. In practice, you can tweak translations without rebuilding; hot-reload shows the changes instantly.

The page layout is split into two templates: user-side and agent-side. The user side includes a task hall, betting history, fund details, and team management modules. The agent side adds promo link generation and subordinate management. The overall UI is clean with no flashy animations, and load times are decent.

Task Lottery Mechanics

The so-called “system lottery” basically means all results are preset on the backend rather than fetched from an external lottery API. Supported task types include local Vietnamese Loto, quick-draw games, Vietnamese color disc, and more. All numbers, trends, and draw results are pushed from the backend’s “Draw Management” section.

The preset control logic works like this: the admin sets the winning numbers, betting window, and closing time for each round. What users see as a “live draw” is actually a countdown that reveals the preset result once it ends. This means the operator has full control over the payout ratio, with all profit and loss managed from the backend.

Fund Flow and Payment Gateway

Payments run through a unified cashier on the PHP backend. The default code integrates several common Southeast Asian channels: Vietnamese local bank transfer, USDT (both TRC20 and ERC20 supported), and MoMo e-wallet. Payment callbacks use async notifications, with signature verification written in app/Common/Payment—easy enough to modify.

Once a user’s deposit hits the system, it gets split into two states: “wallet balance” and “task frozen funds.” Funds are frozen at bet placement and settled after the draw—deducted for losses, added back for wins. Every transaction in the “Account Change Log” is traceable, including each entry’s source and destination.

Deployment Essentials and Pitfalls

Environment Requirements

  • OS: CentOS 7.x or Ubuntu 20.04 both work
  • Web server: Nginx 1.18+ or Apache 2.4
  • PHP: 7.2 to 7.4 (7.4 verified as the most stable; 8.0+ has compatibility issues)
  • Database: MySQL 5.7
  • Node: 12.x, for frontend build
  • Bandwidth must be generous—slow access for Southeast Asian users means they close the page immediately

Deployment Workflow

Backend deployment is the same as any standard PHP project: upload the code, create the database and import the SQL, configure the database connection and payment merchant ID in .env, then run php think optimize. The frontend needs a separate build step: navigate to the frontend directory, run npm install for dependencies, update the API address in config (pointing to your backend domain), then npm run build to generate dist. Drop it into the backend’s public/static directory or bind a subdomain—either works.

Pitfall warning: The backend’s draw bot must be properly configured with crontab, otherwise user bets will sit with funds frozen indefinitely. I wrote a shell script paired with Supervisor as a permanent safeguard. Also, the payment callback URL must use HTTPS—both browsers and payment channels require it.

Secondary Development Possibilities

The code follows a standard ThinkPHP5 framework structure with clear module separation (user/agent/admin as three applications). To add a new payment channel, just copy an existing one from app/Common/Payment and rename the class. To add a new lottery type, create a controller under app/admin/controller/Lottery and duplicate the corresponding frontend template with updated config. Overall, the bar for customization is low—anyone who knows PHP can get up to speed within a week.

Who Is This System For?

To be frank, this codebase targets a fairly niche audience and isn’t for everyone. The following types of people might consider it:

  • Site owners or agents with local Vietnamese resources looking to run local promotions
  • Teams already running other Southeast Asian businesses who want to expand into “task-based” product lines
  • Developers who need to reference “system lottery preset” logic for their own projects
  • Clients with limited budgets who need customizable source code

It’s not suitable for complete non-technical beginners—deployment and ongoing maintenance both have a learning curve. If it’s your first time with this kind of system, I recommend having someone handle the initial deployment, then taking it over once you’re familiar.

Frequently Asked Questions

Q: Is the system fully open-source? Any encryption?
A: The PHP backend code is completely open-source—no ionCube encryption, and no ThinkPHP commercial encryption either. The frontend dist is minified, but the source code is all in the src directory and can be rebuilt.

Q: What’s the default payout rate? Can it be adjusted from the backend?
A: The system doesn’t preset a payout rate. The draw result for each number in each round is set manually or in bulk in the backend’s “Draw Management” section. You can write a script to auto-generate them, or hook up a third-party random API for “pseudo-random” results.

Q: Can new languages be added beyond the three built-in ones?
A: Yes. Language packs are standalone JSON files—copy vi.json, modify a new one, register it in src/lang/index.js, and restart the frontend service. We added Lao and Thai for a client without issues.

Q: Is the USDT payment callback stable? Are there dropped orders?
A: USDT is on-chain confirmation, defaulting to 12 block confirmations before callback—theoretically very stable. The code includes an “order recovery” mechanism: orders that time out without completion can be manually confirmed or have notifications resent via script.

Q: Can this system be repurposed into a legitimate business?
A: Technically yes—you could strip out the lottery module and keep just the task publishing and fund flow to make it a standard task platform. However, the original version is positioned as “task lottery,” so operating it in mainland China is not recommended, and Southeast Asian markets require attention to local compliance issues.

#Vietnam local task system #Vue multi-language #PHP open-source backend #ThinkPHP5 #system lottery