5 Commits

Author	SHA1	Message	Date
Ilia Denisov	92ba527575	feat(payments): settle the direct rail through YooKassa ... Replace Robokassa with YooKassa as the RUB direct-rail provider. The wallet model is untouched: one `direct` segment, the same spend wall, the same per-channel merchant shops (D42) and `shop` on the order (D44). The two providers are not shaped alike, and that drives the change: - Opening a purchase is now an outbound API call (`POST /v3/payments`, single-stage capture, redirect confirmation). The order id is both the `Idempotence-Key` and `metadata.order_id`, so a retried create cannot mint a second payment and a notification always resolves to its order. - YooKassa does NOT sign notifications, so the body is never evidence: it only names a payment, which is re-read with `GET /v3/payments/{id}`, and only that answer is acted on. Two guards ride on it — the payment's metadata must name the order, and its `test` flag must match the shop's, so a test-shop payment can never credit real chips. The sender address is checked against YooKassa's published ranges first, which stops a forger turning each fabricated notification into an outbound call of ours. - A notification lost for good would leave the money taken and the chips unowed, silently. The existing pending-order reaper now asks the provider about each order that reached its expiry age carrying a payment id, and credits the ones really paid — one request per order over its whole life, not polling. - `payment.canceled` records a `failed` event, so a declined payment is finally surfaced to the customer as PAYMENTS.md §9 already specified. - The admin refund moves the money through `POST /v3/refunds` before recording anything; a failed call records nothing, so the ledger cannot claim a refund that did not happen, and the recorded id is the provider's own. - YooKassa has no cabinet-side generic receipt: «Чеки от ЮKassa» registers one only if the request carries it, so every payment and refund now sends an itemized `receipt` to the D36 confirmed email. The VAT rate code is a deploy variable; the settlement subject and method are constants. Robokassa is retired, not deleted: the direct rail falls back to it when no YooKassa shop is configured and no deployment sets its credentials, so reviving it is a credentials change rather than a code change. Its variables are removed from compose, .env.example, write-prod-env.sh and the three workflows, and recorded in backend/internal/robokassa/README.md together with the cabinet configuration and the revival steps. Ledger rows keep `provider = 'robokassa'`; that literal is load-bearing for the idempotency index. No migration and no wire change: `orders.provider_payment_id` already existed, and the client is rail-agnostic. Decisions D47-D51 (revising D41) and stage E12 are baked into the docs.	2026-07-28 08:51:31 +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	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