The public site leads to the separate KREM bot where purchase, access and support live.
KREM VPNProduct · Telegram · payments · infrastructure
KREM VPN — from brand to working access
We built the product layer around a VPN: brand and website, Telegram checkout, YooKassa verification, account access, subscription delivery to Happ and Incy, plus monitoring and safe recovery.
₽1controlled YooKassa trial payment confirmed and access issued
5/5Happ, Incy and neutral delivery formats passed on 15 October
7/10profiles carried HTTPS in the latest full run; three DE paths remained unavailable
23full-chain checks passed in an isolated two-host web pilot
Evidence snapshot: 15 October 2026. These figures describe verified test runs; they do not promise identical availability for every route in the future.
case status
site and bot checkout are liveA working product with an explicit readiness boundary
The owner paid for a controlled trial, received access and separately confirmed a working connection on their device.
The full website purchase passed a technical rehearsal but is not public. Device limits are not enabled either.
A complete product, not just a VPN server
The goal was to close the gap between marketing, payment and technical access delivery while keeping one understandable journey for the user.
Identity and website
A standalone KREM VPN brand, visual system, responsive site, help and clear terms — kept separate from the Kremlinet brand.
The bot as an account
Navigation, trial, purchase, current expiry, existing link, device setup and a clear route to support.
YooKassa and a dedicated ledger
The order is recorded before provider hand-off. Verification checks amount, currency, brand and order; replay cannot extend access twice.
Happ and Incy
One HTTPS address serves both primary clients and a neutral import format with expiry headers and no-store protection.
Several connection paths
Multiple protocols and geographic exits provide fallbacks. Monitoring tests actual HTTPS transfer, not only process health.
Monitoring and recovery
Checks separate subscription delivery from traffic, preserve working processes and avoid automatic “repairs” after one ambiguous signal.
buyer and system journey
From first visit to a connected app
Each hand-off preserves context, while the server — not a browser button or payment-page return — confirms the financial result.
The site explains the product
The user sees the offer and supported clients, then enters the dedicated KREM Telegram bot.
The bot records the order
Price, term, brand and consent are stored before the protected YooKassa page opens.
The server verifies payment
A provider event triggers an independent check. The ledger prevents double fulfilment after replay or network uncertainty.
Access returns to the same account
The bot shows the term and existing URL, ready to import into Happ or Incy and refresh after renewal.
Subscription issued
Access appears only after a verified payment.
Status can be checked later
A lost return does not create a second order or ask the user to pay again.
The same URL remains
Adding time to the remainder is technically verified; a full real ₽199 renewal still awaits owner acceptance.
One visual language from discovery to setup
These are published product materials without customer data — not concepts invented for this portfolio page.
Architecture that stays simple for the user
Shared servers and a shared merchant are allowed, but KREM and Kremlinet keep separate customer routes, orders and rights.
01Websitepositioning and entry
02Telegramidentity and order
03YooKassapayment and receipt
04Ledgerreceipt and expiry
05Deliveryone HTTPS URL
06Happ / Incydevice connection
The complexity was not one integration
Payment, delivery and VPN traffic can fail independently, so the control layer cannot be a single green light.
A replay must not add time twice
Events and requests keep stable identities. Pending, replay and late success are handled without a second fulfilment.
A healthy process is not a healthy route
Monitoring separately tests delivery, TLS, services and HTTPS through each profile. The latest run kept three failed DE paths visible.
Two brands cannot share one ledger identity
KREM and Kremlinet share infrastructure but retain separate bots, customer URLs, orders and access rights.
What is confirmed — and what remains development
We distinguish a public product, owner acceptance and synthetic engineering evidence.
Website, dedicated bot and Telegram checkout
The public site shows the current ₽199 offer; YooKassa checkout starts in the KREM bot.
Controlled payment and connection
The ₽1 trial was paid and issued; the owner separately confirmed a working device connection.
Safe renewal and web chain
Preserving the URL, adding the term and replay safety passed isolated tests; the full web pilot passed 23 checks.
Public web purchase, first-party app and device limit
Web checkout remains off until real ₽199 acceptance. The first-party mobile app is in development; device controls are not enabled.
Next development
The roadmap follows open acceptance gates rather than adding promises to the interface.
Accept a full renewal
One deliberate ₽199 payment: receipt, return, same URL and remaining term plus 30 days.
Publish web checkout after acceptance
Only after verifying the real owner flow, public TLS routes and recovery procedure.
Strengthen independent routes
Investigate the failed Germany paths, retain the working NL fallback and avoid universal-availability claims.
Complete first-party apps
Qualify builds, stores, physical devices and every supported subscription format separately.
Enable device controls only after acceptance
Prepared code is not a production feature: it still needs a Linux fixture, full chain and explicit release window.
Preserve observability
Keep measuring delivery, traffic, certificates and infrastructure state independently.