Flaem

Flaem to platforma hostingowa, na której firma prowadzi serwery gier, VPS-y, strony, domeny i pocztę swoich klientów. Żeby taka firma mogła sprzedawać, panel musi rozmawiać z całym otoczeniem: z operatorem płatności, z KSeF, z rejestratorem domen, z dostawcą ochrony DDoS, z bramką SMS i z Discordem, na którym siedzą jej klienci.

Każdą z tych integracji operator włącza osobno, kluczami ze swoich umów, w panelu administratora. Kreator startu pokazuje, której jeszcze brakuje, a to, czego nie ma na liście, podłącza się przez REST API, podpisane webhooki, Terraform albo serwer MCP.

Klient płaci kartą, przelewem, BLIK-iem, kontem PayPal, kodem paysafecard, SMS-em albo kryptowalutą. Bramkę operator włącza kluczami z własnej umowy, a wpłata w tej samej transakcji wystawia fakturę i uruchamia albo odnawia usługę.

Przy Przelewy24, Tpay i PayU sześciocyfrowy kod BLIK wpisuje się w samym panelu, bez przejścia na stronę bramki. Klient zatwierdza płatność w aplikacji banku i przez cały czas zostaje w sklepie.

Każda bramka startuje w trybie testowym, żeby pierwsza prawdziwa wpłata nie przyszła przez pomyłkę. Klucze są zaszyfrowane w bazie i panel nigdy więcej ich nie pokazuje. Zwroty pełne i częściowe idą przez bramkę, a nieudane obciążenie zapisanej karty Stripe przy odnowieniu jest ponawiane w dniu terminu, po trzech i po siedmiu dniach.

Faktura powstaje w chwili płatności, a plik FA(3) trafia do KSeF z kolejki w tle, więc przerwa po stronie KSeF nie blokuje żadnej sprzedaży ani odnowienia. Kolejka ponawia wysyłkę coraz rzadziej, a gdy KSeF długo nie odpowiada, każdy administrator dostaje powiadomienie z numerem faktury i powodem.

Numer VAT firmy z UE sprawdza VIES, faktura w walucie obcej dostaje średni kurs z tabeli A NBP razem z numerem tabeli, a sprzedaż konsumentom w innych krajach UE jest liczona w euro na potrzeby OSS. Po zamknięciu miesiąca operator pobiera jedną paczkę dla księgowej: raporty przychodu, MRR, nieopłaconych faktur, zwrotów i prowizji resellerów w CSV, XLSX i PDF oraz plik JPK zbudowany z tych samych dokumentów, które widać w panelu. Reseller wysyła faktury własnym tokenem KSeF, w kontekście swojego NIP.

Klient wyszukuje i rejestruje domenę w sklepie operatora, a Flaem rozmawia z rejestratorem, przez którego operator ją kupuje: Openprovider, AfterMarket.pl, ResellerClub i inne marki LogicBoxes, CentralNic, OVHcloud, Namecheap, Porkbun, domeny.tv albo bezpośrednio NASK dla domen .pl. Dla każdej końcówki ustawia się kolejność kont: gdy pierwsze nie odpowie, rejestracja idzie przez następne.

Rejestratora spoza listy podłącza się opisem jego API w formularzu panelu, własnym mostkiem albo, jako akredytowany rejestrator, przez EPP wprost do rejestru. Po zakupie strefa DNS trafia do PowerDNS z edytorem rekordów w panelu klienta albo do Cloudflare, a skrzynki powstają w mailcow, który sam wpisuje do strefy rekordy DKIM, SPF i DMARC.

Ruch ataku czyści sieć dostawcy ochrony, zanim dotrze do łącza operatora. Flaem podpina tę ochronę, ustawia filtry dla każdej usługi i pokazuje klientom ataki na ich adresy, bez pisania zgłoszenia.

Flaem czyta dane ze starego systemu przez jego API, bazę albo kopię konta i najpierw pokazuje raport z próby na sucho: co powstanie, co się zmieni i czego nie da się przenieść. Do chwili, w której operator go zatwierdzi, nic się nie zmienia. Przeniesione pakiety czekają nieaktywne, z ceną zero, więc nikt nie dostanie faktury ani blokady przez pomyłkę, a importy z WHMCS, Convoya i Virtualizora można cofnąć.

Z WHMCS przechodzą klienci, saldo do portfela, terminy i kwoty odnowień, faktury jako archiwum i zapisane karty Stripe. Z Pterodactyla przechodzą użytkownicy, węzły, alokacje portów, jajka, pakiety i serwery z zachowanym identyfikatorem, a węzeł Wings zostaje przejęty na miejscu. Maszyny z Convoya zostają na tym samym Proxmoxie bez restartu, z Virtualizora, SolusVM, VirtFusion i VMware ESXi przechodzą na węzły Proxmox VE, a strony, domeny, skrzynki i bazy z cPanelu i DirectAdmina wchodzą z kopii konta.

Operator, który chce zostać przy WHMCS, Bleście, HostBillu albo Paymenterze, instaluje w nim moduł Flaem jak każdy moduł serwera. Jego system zostaje właścicielem klienta, pieniędzy, okresu i windykacji, a Flaem zakłada, zawiesza i zmienia usługi przez API mostu.

Każda zmiana niesie klucz z numeru usługi i rodzaju operacji, więc zadanie ponowione po przekroczeniu czasu nie postawi drugiej maszyny. Usługa z mostka nie dostaje we Flaem faktur ani odnowień, bo tym zajmuje się system rozliczeń operatora.

Faktury, awarie, zbliżające się limity i odpowiedzi na zgłoszenia trafiają do klienta tam, gdzie sam wybierze: do panelu, na e-mail z serwera SMTP operatora, SMS-em przez Twilio, SMSAPI albo SerwerSMS, pushem w przeglądarce i w aplikacjach na iOS i Androida, na Telegramie albo na Discordzie. Alarm dla zespołu trafia do dyżurnego, a bez potwierdzenia idzie wyżej po drabinie eskalacji.

Bot Discorda działa na własnej aplikacji operatora, więc na serwerach klientów odzywa się jego marka. Każde zgłoszenie otwiera wątek na Discordzie zespołu, a odpowiedź z wątku wraca do zgłoszenia. Klient ma komendy do serwerów, kopii zapasowych i faktur, kanał alertów o awariach swoich serwerów i role nadawane według usług, które ma.

Klient loguje się kontem Google, GitHub, Discord albo Steam lub przez dowolnego dostawcę OpenID Connect. Formularze chroni Cloudflare Turnstile albo hCaptcha, a zamówienie przed uruchomieniem serwera ocenia antyfraud: reguły operatora, MaxMind minFraud albo FraudLabs Pro.

Klient wyszukuje plugin albo mod w panelu i instaluje go jednym kliknięciem, bez wgrywania plików przez SFTP. Operator decyduje, które katalogi są włączone: Modrinth, CurseForge, Hangar, SpigotMC i GeyserMC dla Minecrafta oraz Steam Workshop i Thunderstore dla gier ze Steama. Zależności instalują się razem z pluginem, a każdy pobrany plik jest sprawdzany sumą kontrolną, zanim trafi na serwer.

Czego nie ma na liście, podłącza się przez publiczne API. Wszystkie narzędzia korzystają z tych samych kluczy, limitów i dziennika użycia.

Webhooki niosą podpis HMAC-SHA256 obejmujący znacznik czasu i treść, więc odbiorca rozpozna podróbkę i stare zdarzenie podane drugi raz. Nieudane dostarczenie jest ponawiane w rosnących odstępach, a adres, który stale nie odpowiada, wyłącza się z podanym powodem.