17 Commits

Author	SHA1	Message	Date
Ilia Denisov	12e616ceae	feat(payments): send no fiscal receipt; keep the code switchable ... The merchant accepts payments as a sole proprietor on НПД, which is outside 54-ФЗ: there is no online cash register, YooKassa does not serve receipts for that regime at all (checked with their support), and each operation is reported by the merchant to «Мой налог», which issues the чек. So no `receipt` is sent with a payment or a refund. This also removes a failure class rather than just code: a malformed receipt was an API error at payment creation, which broke the purchase outright. The fiscal code is kept dormant rather than deleted. All of it now sits behind one switch, `BACKEND_YOOKASSA_VAT_CODE`: unset — the default — builds and sends nothing; a 54-ФЗ rate code turns «Чеки от ЮKassa» back on unchanged. The return is foreseeable, which is why the switch exists: НПД carries an annual income ceiling, and losing the regime puts 54-ФЗ back in force, at which point this is a deploy-variable edit instead of writing the integration again. The D36 email anchor still gates a direct purchase. It had two justifications — a recovery anchor and the receipt address — and only the second is gone; without an email a paying customer who loses the account loses the chips with it. What was missing is that the rule was enforced but never communicated: the wallet showed the packs to a player signed in through VK or Telegram in a browser, and tapping Buy produced a bare "something went wrong". It now says "add an email in your profile" in the buy tab instead, linking to the profile; spending already-earned chips is untouched. The predicate is a pure function so it is covered by the node-env unit tests rather than needing a browser. Tests: the receipt-off default is pinned by an integration test asserting a purchase carries no receipt, and the dormant path by one that switches a VAT code on and checks the receipt reappears with the right fiscal attributes; plus unit coverage for the enable predicate and the wallet's email rule. A note for whoever runs the numbers next: the shared (svelte + i18n) chunk is now 40 bytes under its 31 KB gzip budget. Decision D51 revised.	2026-07-28 11:40:59 +02:00
Ilia Denisov	584384487c	fix(vk): route the Wallet public-offer link out of the Mini App WebView ... The "Public offer" link in the Wallet pointed at the same-origin static /offer/ page with a plain target=_blank anchor and no click handler. The Android VK client ignores target=_blank and navigates its own WebView to the page, stranding the player with no way back to the game (iOS opens a child browser, so it was unaffected). The existing onExternalLinkClick router could not help: it escapes only cross-origin links, and /offer/ is same-origin (a static legal page, not an SPA route). Add onInAppPageLinkClick, which routes a same-origin, non-SPA page out through the host escape hatch (Telegram openLink, VK away.php) while bypassing the cross-origin gate, and attach it to the offer link. Outside a Mini App host it is a no-op and the anchor's own target=_blank stands. The "Rules" (About) and ad-banner links already route correctly (cross-origin + a handler) and are left unchanged.	2026-07-17 20:20:22 +02:00
Ilia Denisov	1507ceb793	feat(payments): live payment-availability kill switch + per-account override ... Let an operator disable purchases live from the admin — a whole rail/channel or one account — and show the user a localized reason on their next attempt, so a provider outage or a misconfig is explained instead of a silent dead button. - rail kill switch (payments.rail_status, per rail direct:web / direct:android / vk / telegram): enabled + a per-language message, edited on the catalog page. Fail-open — a rail with no row stays enabled, so payments are never accidentally killed. The intake gate (CanPurchase in handleWalletOrder, before the order) returns payment_unavailable + the localized message, orthogonal to the security gates. - per-account override (payments.account_payment_override, a row only for non-default): allow / deny / default, edited on the user card. "allow" bypasses ONLY the ops rail switch, never the security gates (trusted platform, the email anchor, the VK-iOS freeze, the min client version). - wire: an additive ExecuteResponse.message envelope field (frozen-contract-safe); the gateway forwards a backend domain-error message; the client shows it on a payment_unavailable buy attempt. - admin: rail toggles on the catalog page, the override control on the user card. - tests: the pure gate (unit, TDD), the store + gate + override end-to-end (integration, migration 00016), the client (svelte-check / vitest). - docs: PAYMENTS (+ru), the decisions log (D45/D46). Fiscalization stays cabinet-side (owner decision) — no itemized-receipt code. Contour-safe: additive migration (two new tables, no wipe), the wire add is additive, and fail-open so nothing is disabled until an operator acts.	2026-07-14 16:29:41 +02:00
Ilia Denisov	de003e862a	feat(android): resolve gateway origin on native, skip SW, hide MVP purchases ... Make the web SPA behave correctly inside the Capacitor native shell, where the bundle loads from a local origin: - New lib/origin.ts gatewayOrigin(): absolute URLs resolve to VITE_GATEWAY_URL on native (the finished-game export/share URL in Game.svelte and the Wallet site-root link), falling back to the page origin on web. transport.ts already resolved via VITE_GATEWAY_URL and is left as-is. - Skip the PWA service worker on the native channel (the assets are already local; a worker would risk serving stale content across store updates). - Hide the money-purchase UI in the MVP: new distribution.purchasesHidden() folds VITE_PAYMENTS_DISABLED and the Google Play flag. The Wallet "buy" tab shows a neutral, pointer-free note (wallet.purchasesSoon) for the RuStore MVP and keeps the RuStore stub Google-Play-only. A ?nopay mock force mirrors ?gp for the e2e. - Native env types in vite-env.d.ts. Client-only, contour-safe: no wire/proto/schema change; web/VK/Telegram unchanged. Tests: origin + purchasesHidden unit tests, a ?nopay wallet e2e. svelte-check clean, vitest green, web + native vite build clean.	2026-07-12 14:58:35 +02:00
Ilia Denisov	8ce986922a	feat(ui): wallet storefront redesign — split buy/spend, compact balance, exchange confirm ... Reworks the Wallet screen to be more compact and to separate the two flows, and fixes a reported bug. Bug: buying a value with too few chips showed the generic "Something went wrong" toast — the backend's `insufficient_chips` (409) code was propagated correctly but had no i18n mapping, so `errorKey` fell back to `error.generic`. Add `error.insufficient_chips` / `error.product_not_found`. Also disable a value's Exchange button up front when the spendable balance cannot cover it (the server stays authoritative). Redesign: - a compact **balance** row leads the screen — the context's own chips (🪙 N) then any linked other-platform chips behind that platform's logo (monospaced digits); inside a VK/TG store only that store's own segment shows; - the benefits section is renamed **Active**, moved above the store, shows one inline line (hints + ad-free) and hides when nothing is active; - the **store** splits by a two-way toggle into **Buy chips** (money packs + the watch-an-ad row at the top) and **Spend chips** (values, exchanged for chips); - a value's action reads **Exchange** and opens a single confirmation dialog (chip spends are instant, with no provider window to confirm them); the existing cross-platform store-compliance warning folds into that same dialog when the spend would draw VK/TG chips. No payments-model or wire change; the money→chips→values model is unchanged (verified: money buys only chip packs, values are chips-only — "no-ads for money" is structurally impossible). Tests: wallet e2e updated for the new layout (chromium + webkit green). Docs: FUNCTIONAL (+_ru) wallet story rewritten. App bundle budget 126 → 127 KB (always-loaded settings hub).	2026-07-10 17:46:22 +02:00
Ilia Denisov	9acf6ab3b4	fix(payments): VK-iOS freeze is purchase-only; remove the rewarded diagnostic ... Testing the rewarded slice surfaced a contradiction: rewarded ads let a VK-iOS user earn vk chips, but the blanket VK-iOS "spend freeze" then blocked spending them (the wallet showed "5 (view-only)"). Apple's ToS forbids only BUYING in-app values on VK-iOS (money -> chips), not spending or earning them — so the freeze is corrected to purchase-only: vkFrozen() now gates only CreateOrder (the money-in step), not spendableSources (spending). VK-wallet chips — earned via rewarded ads or bought on the same account elsewhere (VK Android) — now spend on VK-iOS too. (Owner's ToS finding.) Also: the temporary contour diagnostic confirmed VK returns only {result:true} for a rewarded view (no token/signature) — client-attested is final, no hardening possible — so the diagnostic (the log and the diag wire field) is removed. Docs: PAYMENTS(+ru) VK-iOS freeze + D17 amend + PLAN E6. Tests updated (gate / wallet VK-iOS now spendable).	2026-07-10 01:27:26 +02:00
Ilia Denisov	dbd76d53e8	feat(ads): rewarded video (VK) — client-attested credit + daily/hourly caps ... The first ads slice: a voluntary rewarded video credits chips. VK Mini App ads (VKWebAppShowNativeAds) expose only a client-side watch result — no server-to-server verify — so the credit is client-attested, guarded by a server daily + hourly cap (config reward_daily_cap / reward_hourly_cap, default 50 / 10). The caps are both anti-abuse (bounding a forger who skips the ad and calls the endpoint directly) and an economic conversion lever (limiting free chips so a player who wants more buys). D29 amended to VK's reality. Backend: CreditReward (VK-only, order-less, idempotent on a client nonce, floored by the caps; payout from config rewarded_payout_chips, default 0 = off) + the wallet.reward edge op returning the updated wallet (reward_chips gates the "watch for chips" CTA). Additive migration (two config columns). Client: the ads-network abstraction (lib/ads.ts, VK impl) + the VK bridge (vkRewardedReady / vkShowRewarded) + the Wallet CTA + i18n. A contour test stub (VITE_ADS_STUB -> a toast instead of a real ad; prod always real) and a temporary diagnostic that logs the raw VK data, so we confirm on the contour exactly what VK returns (harden to signature-verify if it carries one). Tests: backend integration (credit, nonce idempotency, hourly cap, disabled, non-VK refusal) + codec unit (reward wire). Docs: PAYMENTS(+ru) §10, D29 amend, PLAN E6. Bundle: shared budget 30->31 (reward i18n strings).	2026-07-10 00:41:42 +02:00
Ilia Denisov	55dbb1005e	fix(ui): scope the wallet buy-button busy dim to the tapped button ... Tapping one pack's Buy dimmed every buy button at once (the shared busy flag drove disabled + the :disabled opacity on all of them), so it looked like both packs reacted to one tap. Track the in-flight product id (busyId): the concurrency guard stays global, but the pressed/dimmed look is now scoped to the tapped button. Payments were never affected.	2026-07-09 22:26:28 +02:00
Ilia Denisov	6e03ce0131	feat(payments): Telegram Stars payment rail ... Accept real money via Telegram Stars (XTR) — the third intake rail alongside Robokassa (direct) and VK Votes. Only the bot reaches Telegram, so the rail funnels through the reverse mTLS bot-link: - the gateway mints the invoice on a CreateInvoice command (the bot calls createInvoiceLink, XTR; the link goes to WebApp.openInvoice); - the bot gates each pre_checkout_query via a ValidatePreCheckout unary (the order must exist, be still creditable and not already paid — the reusable-invoice double-pay guard; the decline reason is localised to the order account's language); - a completed successful_payment is queued in a durable pure-Go SQLite outbox and forwarded via a ForwardPayment unary, credited once (idempotent on telegram_payment_charge_id, honours an expired order), re-driven on restart and every 30s. The rail is wired by TELEGRAM_STARS_OUTBOX_DIR (default /data) but stays inert until a chip pack carries an XTR price, so seeding a Stars price in the admin is the go-live. Tests: backend integration (order->forward->credit once, duplicate, pre_checkout gate) + bot outbox unit (idempotent, restart re-drive) + executor createInvoice. Docs: PAYMENTS(+ru) §9, ARCHITECTURE, the platform/telegram README, PLAN.	2026-07-09 21:35:29 +02:00
Ilia Denisov	8230253142	fix(ui): derive the VK-iOS store link from the deployment origin ... Replace the hardcoded erudit-game.ru host with location.origin, so the iOS store note's "other version" link points at this deployment's own site root (prod or the contour) without a hardcoded host or build-arg wiring.	2026-07-09 20:26:25 +02:00
Ilia Denisov	e33b9864c8	fix(ui): point the VK-iOS "other version" link at the site root ... The landing at / lists every version's entry; /app/ dropped the player straight into the web game. Link the iOS store note to the root instead.	2026-07-09 20:18:42 +02:00
Ilia Denisov	f6aa0ba4b0	fix(ui): correct the VK-iOS purchase block + add an iOS store note ... The VK-iOS detection used platformSubtype(), which is server-derived for VK and so never reported iOS on the client — the pack CTA stayed active and a tap hit a 403 with a generic error. Read the device family from the signed vk_platform launch param (normalizeSubtype(vkPlatform())) instead. Under the store header on VK-iOS, add a note that purchases are prohibited by Apple policy, linking to the web version (opened through VK's external-link route).	2026-07-09 20:11:35 +02:00
Ilia Denisov	f48ebf2151	fix(ui): VK-iOS shows the pack CTA disabled with a toast, not a failed buy ... Money purchases are not permitted in the VK iOS app (Apple ToS), and the backend already refuses them (the CreateOrder VK-iOS freeze). Show the pack "Buy" muted there and explain on tap ("purchases are not available on this platform"), instead of letting the tap hit a 403 and a generic error toast. The storefront still lists the packs.	2026-07-09 19:57:10 +02:00
Ilia Denisov	3bb9f10fad	feat(payments): VK Votes payment rail ... Wire the VK Mini Apps ("голоса") rail end to end, reusing the intake engine. The wallet.order endpoint branches by rail: a VK context opens a pending order (provider vk) and returns its id, which the client passes to VKWebAppShowOrderBox. VK's two-phase payment callback is verified at the gateway with the app protected key (GATEWAY_VK_APP_SECRET) and proxied to a backend intake handler: get_item returns the ordered pack's title and vote price; a chargeable order_status_change credits the vk segment exactly once (the same Fund, idempotent on VK's own order id) and records a succeeded event, so the dispatcher push refreshes the wallet. Integration test for the VK order->credit path.	2026-07-09 19:27:57 +02:00
Ilia Denisov	3367cc2bf1	feat(payments): payment-event dispatcher + the provider-return UX ... Deliver payment_events to connected clients as an in-app wallet-refresh push: a background dispatcher drains undispatched events and publishes a KindNotification "payment" signal, marking each delivered; the client bumps a wallet-refresh counter the open Wallet screen watches, re-fetching in place. A return-focus refetch is the fallback. The Robokassa Success/Fail return now serves a self-closing page (the payment opens in a separate window) so the customer drops back into the live app instead of a cold start. Integration test for the event drain/mark queue.	2026-07-09 18:26:06 +02:00
Ilia Denisov	936a70ab94	feat(ui): wire the chip-pack purchase to Robokassa ... Replace the disabled "Soon" pack action with a real purchase: the Wallet opens a money order (wallet.order) and sends the player to the provider's hosted-payment page (window.open via openExternalUrl); the chips are credited later by the verified server callback. Add a public-offer link under the packs (paying accepts the offer). Codec order round-trip unit test + a mock-e2e purchase test; the Google Play stub and the chip-spend paths are unchanged.	2026-07-09 17:43:02 +02:00
Ilia Denisov	4aa6174968	feat(payments): wallet screen with balances, benefits and storefront ... Add the "Кошелёк" section to the settings hub: context-visible chip balances, active benefits (no-ads term/forever, hints) and a storefront of chip-priced values and money-priced chip packs. Guests have no wallet; the Google Play build hides the money purchases behind a RuStore stub; a web purchase that would draw VK/Telegram chips warns first. Add the catalog read path the storefront needs — a context-projected GET /api/v1/user/wallet/catalog (payments service + store, gateway op wallet.catalog, FBS Catalog/CatalogProduct/CatalogAtom, client decode) — plus the client leg for the existing wallet.get/buy ops. Value spends reuse the existing spend path; the chip-pack purchase (money order flow) arrives with payment intake, so its action is a disabled placeholder for now. Covered by Go unit (catalog projection) + integration (/wallet/catalog over Postgres), vitest (formatting, spendable selection, web-spend warning, GP flag, codec + gateway encode round-trips) and Playwright mock e2e (render, guest-hidden, GP stub, warning) on Chromium + WebKit.	2026-07-08 12:37:32 +02:00