Blog · 2026-08-30

Automating Check-Ins, Payouts and Prize Draws: System Design for a Membership LINE Bot

From LINE identity binding and the unique keys that block duplicates, to idempotent payout crediting, systemd auto-start, external alerting and 6-hourly backups, a breakdown of a membership bot architecture that nobody has to babysit.

The most labor-intensive part of membership operations is the repetitive work: verify check-ins every day, hand out prizes against a list, confirm the payout landed, then message each person individually. Done by hand it is slow and things get missed, and the moment a campaign scales up, support drowns. This entire pipeline can run fully automated on a LINE bot, as long as a few design questions get settled first. Otherwise automation just makes the mistakes faster.

Identity Binding: LINE Identity and Member Account Are Two Systems, So Build the Mapping Table

What a LINE official account gives you is a platform-issued user ID. Your membership system has its own account namespace. The two have nothing in common by nature. Step one for every piece of automation is building the binding table that maps LINE ID to member account, and building it strictly:

• Binding must verify ownership. A member typing an account name into the chat box is not a binding. Pair it with a one-time verification code or admin approval, or anyone can bind someone else's account to their own LINE identity.
• Enforce uniqueness with database constraints: one LINE identity binds to exactly one member account, and one member account can only be bound once. Without both unique constraints you will eventually get one person with multiple bindings collecting prizes twice, or popular accounts getting claimed by whoever gets there first.
• Log every unbind and rebind. When a dispute comes up, that log is the only evidence that can settle it.

Once binding is solid, check-ins, prize draws, payouts and push messages all hang off the same member identity, which is the foundation everything downstream needs.

Check-Ins and Prize Draws: Pick the Right Duplicate Key, and Let the Database Enforce It

The most common failure in duplicate prevention is choosing the key at the wrong level. To block "the same member checking in twice in one day", the unique key is member plus date. To block "the same member entering the same campaign draw twice", the key is member plus campaign. If the key is not aligned with the thing you are actually trying to prevent, your functional tests can all pass green and duplicates will still get through.

Three implementation points:

• Enforce it with a database unique index, not an if in application code. Double taps, network retries and two simultaneous requests can all slip past application logic at the same instant. A unique index will not let them. On a key collision, reply "you have already checked in today", which is a normal response to the user, not an error.
• Define the time zone for "a day" explicitly. If the host clock is several hours off Taiwan time, people around midnight will get an extra day or lose one.
• Anti-abuse has to be layered, and you should assume someone will come to stuff the box. We ran a campaign signup and prize draw page with five layers: IP rate limiting, blocklists, unique keys on phone and email, fingerprint hashing, and a human verification challenge. Afterwards we ran a multi-dimensional cleanup and audited roughly 118 genuine entries out of 142 signups, with the rest being test data, junk numbers, batch entries from the same subnet, and people referring themselves. The front end can stop a slip of the finger. It cannot stop someone determined, so the list has to be auditable for authenticity after the fact.

Automated Payout Crediting: Idempotency Beats Speed, and Push Only After the Credit Succeeds

In iGaming-style operations, a payout means crediting campaign winnings or rebates straight into a member's game wallet. The core of a fully automated payout is the bot backend calling the membership system's crediting interface with a unique transaction number on every request. Resend the same number and the system returns the same result and does not credit a second time. That is idempotency, and it is what makes an automated payout safe to retry.

• The dangerous state is not failure, it is uncertainty. When a crediting request times out, the money may or may not have moved. You cannot blindly retry that transaction and you cannot mark it failed either. Query its status first, then decide. If the failure path is not designed, automation just automates losing money.
• Lock the ordering: confirm the credit succeeded, then send the LINE push notification. A duplicate push costs the user one extra message. A duplicate credit is a direct loss, so the retry strategies on the two sides have to be separate.
• Keep a record of every payout and reconcile on a schedule: the bot's payout log and the membership system's crediting log get compared automatically, and one mismatch raises an alert. Fully automated does not mean nobody watches, it means a human is only needed when something is wrong.
• Push messages cost money and come with a quota, so transaction notifications and marketing messages need separate tiers. Do not let system messages eat the quota.

The Cloud Trio: Auto-Start, Alerting, Backups. Miss One and It Is Not Live

A bot like this is a resident service receiving messages around the clock, and running it on a machine in the office is a single point of failure. Our standard approach is deploying to a cloud host with all three pieces in place:

1. Auto-start on boot and self-healing on crash: systemd with Restart=always and the unit enabled, so the service comes back by itself when the host reboots and gets relaunched when the process dies. On another system built from the same deployment skeleton, we measured systemd catching a force-killed process and bringing it back in about 6 seconds.
2. External uptime check and alerting: a dead process cannot announce that it is dead, so alerting cannot rely on the service reporting on itself. Use an external liveness check that pushes a notification to your phone the moment it goes down.
3. Automatic data backups: the binding table and the check-in and payout logs are the life of this system. We back the database up to cloud object storage every 6 hours, in a different failure domain from the host, keeping multiple restore points. If the host burns down, you lose a few hours at most, not everything.

Closing

Check-in, binding, payout, prize draw: none of them is hard on its own. The hard part is designing the failure paths, duplicates, timeouts, binding races, stuffed entries and outages, into the system from the start. The quality of a fully automated system is decided by its failure paths. If your membership operations are still stuck on manually verifying lists or paying out by hand, or you want to add duplicate prevention and redundancy to an existing bot, come talk to us about which part is worth automating first.

We Turned This Architecture Into a Product

The entire system design above is packaged as our LINE OA smart management platform, so you do not have to handle hosting, signatures, idempotency and backups yourself.

• API integration: connect the bot to your own order or membership system, including the identity binding table
• 8-stage funnel tracking: every follower is staged automatically, no state machine for you to write
• CRM contact management: user profiles, behavior history and tags in one place
• Segmented push: pick recipients by stage and tag, so message costs go to the right people
• Keyword auto-reply: three trigger types, keyword, event and condition
• AI support agent: a RAG knowledge base plus an LLM, with automatic handoff to a human when it cannot answer

Three tiers, monthly fee in USDT, no lock-in:

The official accounts in these plans are registered under your own name, not held under ours. Full specs are on LINE OA platform, and for a fully custom build see Automation Development. If you want to understand the LINE official account structure first, read the Complete Guide to LINE Official Accounts.