Whoever holds the token controls the bot
The Bot Token is the only credential the bot uses against the Bot API. Anyone who has it can send and read messages, change the webhook and see whatever data the bot can see. So the useful question is not whether the token was handed over, but who still holds a copy of the old one. Test notes, logs, chat history and CI settings on the developer side all count. The delivery terms should say the developer keeps no working token after handover and will cooperate with a rotation at acceptance.
Accept delivery by rotating the token
BotFather can generate a new token, which invalidates the old one at once. Make that an acceptance step. The buyer rotates the token from their own Telegram account, puts the new value only in their own server environment, confirms the bot responds there, and confirms the old token now fails. This proves two things: the buyer can actually reach the bot in BotFather, and the code does not hard-wire the token somewhere the developer controls. Also check which Telegram account created the bot. BotFather offers an option to transfer bot ownership; the exact entry point and limits depend on the current interface. If the bot sits under the developer's personal account, holding the token alone is not full control.
Source code delivery should mean a reproducible build
Break down what source delivery covers: the full repository with history or a stated snapshot, dependency manifests and lock files, a list of environment variable names and purposes (without real values), database schema and migrations, and deployment scripts or notes. A workable acceptance test is that the buyer builds and starts the bot in a clean environment from the repository and notes alone, without asking the developer anything. Also settle the rights: full assignment or a usage licence, and whether third-party and closed-source components allow the buyer to keep using and modifying the code. Put this in the contract rather than relying on assumptions.
Hosting ownership decides whether the bot stays online
Treat four resources separately: the server or cloud account, the domain and certificates, the database and its backups, and monitoring and logs. The safest setup has all of them under the buyer's name from the start, with the developer given limited access. If the developer hosts for now, state the term, who pays, how data is exported and what migration help is owed. The test is concrete: if the developer stopped responding tomorrow, could the buyer keep the bot running and retrieve all data? If not, hosting ownership is still unresolved. Webhook URLs, reverse proxy settings and scheduled jobs belong on the handover list too. They are often missed and determine whether the bot receives updates after a move.
Hand over the other keys and accounts the bot depends on
Bots often call payment, SMS, AI and storage services whose keys live in the developer's own accounts. List each service, the account holder and the billing party, and have the buyer reissue keys from their own accounts. If the bot works with an app on Google Play, for example for notifications, support entry points or login binding, check that the developer account, server callbacks and signing setup on the app side belong to the same owner. Otherwise the bot may move to the buyer while the app still points at the developer's services. For anything involving developer account transfer, follow the platform's account management pages at the time.
Write down responsibilities after acceptance
Disputes usually start after delivery. Agree on what marks acceptance (token rotated, buyer's environment running, developer access removed), which defects the warranty period covers, how new requirements are priced and who handles breakage from Bot API changes. Also agree on stop signals in advance. If the buyer cannot deploy independently, the developer will not revoke access, or the code will not build in a clean environment, hold the final payment and complete the handover first.