Making three sign-in paths resolve to one token wallet cost a month of Dantiva's build

Every generation costs money on the provider side, and a call can fail halfway through ^[13]. That failure mode is why the token balance is not a number the server decrements. It reserves tokens when a job starts, captures them when the video arrives, and refunds them when the provider fails ^[13]. Each job carries an idempotency key, so a double tap on a slow connection does not start two generations ^[14]. The free tier is fenced three ways: one welcome grant per device, a daily ceiling, and a limit on jobs running at the same time, because free tokens on an open internet get farmed within hours ^[15]. Identity work is where the month went. The site signs people in with Google or email verification, the bot knows a Telegram ID, and the Mini App receives a signed payload from Telegram ^[10]. All three have to resolve to the same wallet, and a purchase made in one place has to show up in the other two within seconds ^[11]. "That last sentence cost me a month," the developer wrote of sharing one account and one balance across the three doors ^[9]. Skipping the parity check once left the bot with templates the site did not have, and every feature is now checked on all three surfaces before release ^[12]. The September 19 incident is a clean argument for keeping money logic in one place. Unlimited accounts exist for friends, testers and partners, and the server checked that list before touching any wallet, correctly ^[16]. The Mini App then rendered its launch screen twice, and the second pass overwrote the unlimited status with the subscription wallet, so a person with unlimited access saw a balance of 25 paid tokens and an offer to buy a plan ^[17]. Nothing was charged ^[17]. The fix was a priority rule in the interface and two regression tests that render the screen twice on purpose ^[18]. The developer wrote that "the money logic belongs in one place, and the screens only display it" ^[19]. That render bug landed one day after subscriptions went live on the 18th ^[27]. The product has carried three names: Project Aurora as a July codename, then Synora, then Dantiva, which is the domain and every customer facing string ^[20]. The code is still Synora. Environment variables start with SYNORA_, the device header is X-Synora-Device, and the Cloud Run service and the task queue carry the old name ^[21]. A rule in the cutover document forbids renaming them, because a rename touches secrets, deployment configuration, the queue, the header every client sends and the Telegram configuration at once, with nothing visible to a user ^[22]. Grepping for a dead brand name costs less than rotating secrets. Whether the second layer dominates your estimate too depends on conditions this build happens to meet: a provider billed per call that can fail mid-job, more than one front end sharing state, and real payments with refunds, an admin panel and a legal center in two languages ^[5][13]. A free single-surface demo on the same Veo call needs none of it. July's version was one API call to Veo on Cloud Run with all state in memory ^[6], and the developer's verdict on it was "It worked. It could not be sold." ^[7] I would build the reserve-capture-refund ledger before taking the first payment. Demand is still unproven. Payments have been live since early September and subscriptions since the 18th ^[25]. The developer says the one advantage he can prove today is paying in rubles from a Telegram account with a proper receipt, since the tools this audience would otherwise use sit behind a foreign card and a VPN ^[23][24]. He writes that paid demand is not confirmed, and that he does not yet know which of the three doors converts best, which he intends to answer from purchase data ^[24][26].