Two Accounts Into One: The Account Merging Guide for Vibe Projects

First, a clarification: every product name, person, amount and conversation in this guide is a fictional example invented to explain the method. They are not real products or real user cases. The method itself is general, and the specific days and amounts in the process are illustrative yardsticks, not any real product's rules.

Account merging is one of the most underestimated features in a vibe project. It looks like "turning two accounts into one", but it touches subscriptions, balances, content, collaboration permissions, third-party bindings and audit records — and any mistake costs users real money or years of accumulated content. Worse, a bad merge is almost impossible to "undo": once content sits under one account name, splitting it back usually means manual reconciliation. So this guide is not about what the merge button looks like. It is about the judgments to make before merging, the ownership checks required, the order of steps, and how to recover when things go wrong.

1. Distinguish first: merging is not rebinding, not deletion, not a new login method

Before acting, separate four easily confused operations. Rebinding swaps one account's login credential — say, changing the login email from A to B — while the account itself, its content, subscription and permissions stay put. Deletion wipes an account and its data, usually irreversibly; merging must never be implemented as "delete one account". Adding a login method gives the same account a new door — email login plus WeChat login, still one account. Merging takes two independent accounts that have each generated data, turns them into one account, and assigns both accounts' data, entitlements and relationships to it under defined rules.

A fictional example: Chen Mo has two accounts in a collaboration product called "Bailu Collab" — one registered with a work email, holding company project documents and a paid subscription, and one signed in via WeChat, holding personal boards and shared spaces with friends. One day he wants to "unify into one account". If support treats this as a "rebinding", they will only change one account's login method; the other account's data stays where it is, and he will believe the merge is done while both accounts still exist. The first step of any merge is always confirming which operation the user actually wants, and telling them in plain writing what happens to the absorbed account: is it deleted, frozen, or kept as a read-only archive?

This distinction matters because the four operations differ wildly in reversibility. A wrong rebinding can be rebound back; a wrong merge requires splitting data; a wrong deletion may recover nothing. Every merge entry point must literally say "merge" — never substitute vague words like "link", "sync" or "bind". The cost of a user entering the wrong flow far exceeds the cost of two extra lines of explanation.

2. Should you merge at all: judge first, process second

Not every "I have two accounts" case should end in a merge. Three typical cases should: both accounts genuinely belong to the same person, created through different sign-up doors — email first, WeChat later — that the system failed to recognize as one person; the user explicitly wants one identity, for example carrying work-account content to a personal account after leaving a job, or vice versa; or one account is nearly empty, and merging just clears a duplicate identity so the user stops picking the wrong account at login.

The cases that should not merge are equally clear. First, two accounts belonging to different people — even spouses, partners, or managers and reports — must never merge; merging exposes A's private content to B, and no technical measure can later "unsee" it. Second, an account involved in a dispute — unpaid bills, complaints, a ban under appeal — carries the dispute into the other account; resolve the dispute before discussing a merge. Third, the user merely finds login inconvenient, for example having forgotten one account's password — that is a recovery flow, not a merge. Solving a reversible problem with an irreversible operation is backwards.

The burden of judgment sits with the product, not the user. The first screen of a merge flow should be three judgment questions, not a confirm button: are both accounts yours? Does either account contain content or collaboration relationships that are not yours? Does the absorbed account hold an active subscription, balance, or pending item? If any question cannot be answered, the flow should stop and route to manual review — not let the user "click first and see".

3. Ownership verification: prove both accounts are yours, no exceptions

The most dangerous attack surface of merging is someone impersonating a user to "merge" another person's account into their own hands. So ownership must be verified for each account separately, at a strength no lower than password changes or credential swaps. Email accounts verify email ownership, phone accounts verify an SMS code, third-party logins re-run authorization. Verifying only one account and taking the user's word for the other leaves a legitimate-looking channel for account theft.

Verification must also guard against a common hole: session hijacking. A user currently signed in as A wants to merge in B; the system must require the user to re-prove control of B inside the same flow, not assume B is theirs merely because "the current session is A". In practice: the merge flow builds its own short-lived verification session, re-validates both accounts' credentials inside it, and only then proceeds. If any credential expires mid-flow, the whole flow restarts from the beginning — no "half-verified, half-approved".

After verification, keep a standalone audit record: when, who operated, which two accounts, and which verification methods passed. This record belongs to the merge event itself, not to either account's ordinary operation log. When a user later disputes "I never merged", or support needs to reconstruct the scene, this record is the evidence. A merge without an audit record is a merge that, for practical purposes, never happened — and when something goes wrong, nobody can explain it.

4. The conflict matrix: put every data category on the table before merging

The real work of merging is conflict handling, not button logic. Before coding, lay both accounts' data out in a conflict matrix by category, with a rule for each — not decisions made on the spot when code hits them. Seven common categories each need an explicit answer.

First, identity: username, avatar, bio. When both accounts have usernames, which survives? Is the absorbed account's username released, held for a while, or frozen permanently to prevent impersonation? A pragmatic rule: keep the primary account's username, and freeze the absorbed username for a protection period — ninety days, for example — during which nobody else may register it, releasing it only after expiry. That window exists to stop someone from immediately grabbing the old username and continuing to receive messages as the original owner.

Second, subscriptions and balances: paid subscriptions, remaining days, balances, coupons. When both accounts hold subscriptions, do durations stack, take the later expiry, or convert proportionally? Can balances combine, is there a cap, do coupons survive merging? These rules must be shown to the user for confirmation before merging, with concrete numbers — not discovered by the user in a bill afterwards. Any money rule must show the merged subscription expiry date and balance; if the numbers do not match, confirmation must not proceed.

Third, content: documents, boards, files, favorites. Content merging is usually "everything moves under the primary account", but name collisions, quotas and ownership need answers: two same-named documents, one in each account — coexist, rename, or ask the user to resolve manually first? Does the primary account's storage quota fit both accounts' content? Do comments, likes and version history keep their attribution? The principle: content may move, but historical attribution must not be rewritten — whoever wrote a comment stays its author after merging, because rewriting history destroys collaboration trust.

Fourth, collaboration relationships: team memberships, shared-space permissions, external collaborators. When one person joined the same team under two identities, merging should leave one identity, and whether permissions take the higher or the lower of the two must be decided in advance. Higher risks over-privilege, lower risks lost access; both choices cost something, so the key is choosing before, showing the user a merged-permission preview, and listing each team and space's post-merge identity for item-by-item checking.

Fifth, third-party bindings: WeChat, GitHub, Google logins, plus API keys and authorized apps. External bindings usually cannot be "auto-transferred", because the external platform recognizes that specific authorization. The pragmatic approach: the primary account keeps its own bindings, and the absorbed account's bindings are presented one by one for re-authorization or removal — never silently migrated. API keys deserve extra care: whether the absorbed account's keys expire or stay valid after merging must be explicit; vagueness here leaves an unowned back door.

Sixth, notifications and preferences: email subscriptions, notification toggles, language and timezone. When preferences disagree, "primary account wins" is the simplest rule — but users must be told "the absorbed account's preferences will be discarded", not silently overwritten. Seventh, pending items: unfulfilled orders, content under review, appeals in progress. These must be settled or explicitly assigned before merging; merging with open items just ties two tangled accounts into one knot.

5. Execution order: freeze first, migrate second, close out last

Once conflict rules are set, execution order decides whether a merge fails halfway. The recommended order has five steps. First, freeze both accounts: during merging, neither account may generate new data, change passwords, or buy new subscriptions — otherwise new data keeps appearing mid-migration and the books never reconcile. Freezing needs a clear notice and an estimated duration, not a silent lock that makes users think they were banned.

Second, take a pre-merge snapshot: a recoverable backup of both accounts' key data, at minimum identity, subscriptions, balances and a content inventory. The snapshot is not for "changing your mind anytime"; it exists so a failed merge can return to the pre-merge state. A merge without a snapshot can only be repaired by humans digging through logs to reassemble data, at enormous cost.

Third, migrate in conflict-matrix order: identity first, content second, money last. Fix the primary identity, then move content and collaboration relationships, then handle subscriptions and balances — money goes last because money rules are most easily contaminated by earlier mistakes. Migration should run in batches with resumable checkpoints, each batch verified for matching counts before the next runs — not one giant commit that must be fully redone on any error.

Fourth, verify and get user confirmation: show the user the merged result inventory — subscription expiry, balance, content counts, team identities — and treat the merge as complete only when every item checks out. Fifth, close out the absorbed account in the way promised at step one — deletion, freeze, or read-only archive — and clean up old login entries: when users next sign in the old way, they should see a clear message like "this account was merged into account X", not a panic-inducing "account does not exist".

6. Failure and rollback: the ability to "unmerge" must be written first

Before a merge feature ships, ask one question: if power fails at step three with the database half-written, can the system return to the pre-merge state? If that cannot be answered, the feature should not ship. Rollback is part of the merge feature, not a later patch: every migration batch needs an inverse operation, or the whole migration runs in one transaction that rolls back entirely on failure. "Ship first, handle failures manually" is unacceptable when money and content are involved.

Rollback splits into two kinds: technical rollback and user regret. Technical rollback means migration itself failed, the system automatically returns to snapshot state, and tells the user "the merge did not complete; both accounts are unchanged". User regret means the merge succeeded and the user wants it back — as a rule, no one-click "split" is offered, because split attribution is harder to define than merge attribution; but a manual appeal channel must exist, backed by a cooling-off period: for example, for seven days after merging, the absorbed account's data remains in snapshot and recoverable, with true cleanup only after. A cooling-off period makes users more willing to confirm, and gives support evidence when disputes arise.

The failure experience matters as much as the failure mechanics. A merge failure message must not merely say "operation failed, please retry". It must say which step failed, what state both accounts are in now, and what the user should do next. The worst outcome is a "half-merged" state: content moved, subscription did not, and neither account shows a complete picture. Any design that can produce half-merged states must be fault-drilled before launch, not discovered by the first real user who hits it.

7. Launch checklist

Check before shipping: merge, rebind, delete and add-login-method entries are worded so they cannot be confused; the merge first screen carries the three judgment questions; both accounts complete ownership verification inside a short-lived verification session; the conflict matrix covers all seven data categories with rules, and money rules are shown with concrete numbers; the absorbed username has a protection period; a pre-merge snapshot exists and migration runs in resumable batches; money migration runs last; the merged result inventory is user-confirmed; old login entries carry a clear merged-into notice; failure rolls back to snapshot, half-merged states are drilled; the merge event has a standalone audit record; cooling-off period and manual appeal channel are in place.

8. Handoff to support: what a merge ticket should look like

No matter how good the self-service merge flow is, some users will reach human support. When support opens a merge ticket, four things should be visible at first glance: both accounts' identifiers and verification results, each conflict-matrix category's outcome, the location of the pre-merge snapshot, and how many cooling-off days remain. Missing any one forces support to answer from feel — and feel-based answers are most likely to go wrong on money and permissions. The ticket template must be fixed before the feature ships, not improvised when the first dispute arrives.

Anti-patterns — send any of these back: verifying only one account before allowing a merge; using "link" or "bind" wording instead of "merge"; letting users discover money rules in a bill after merging; releasing a username immediately for others to register; silently migrating third-party bindings; leaving API key ownership vague; skipping the freeze so new data appears mid-migration; no snapshot, with failures repaired by manual log archaeology; failure messages that only say "please retry"; old login entries reporting "account does not exist" after merging. Done well, merging leaves users feeling "finally unified". Done badly, users lose subscriptions, content and trust — and trust, once lost, cannot be merged back.