Podłączenie płatności mono (właśnie format subskrypcji) do strony na WordPressie

Mamy chatbota na SendPulse i potrzebna jest konfiguracja, aby przez niego była możliwość zakupu subskrypcji na zamknięty klub za pomocą Stripe, która będzie automatycznie odnawiana co miesiąc, a także dawała możliwość zarządzania subskrypcją oraz automatycznie otwierała i zamykała dostęp w przypadku rozpoczęcia lub zakończenia subskrypcji Co jest już gotowe W Stripe stworzono produkt z miesięcznym pobieraniem i link do płatności. Bot w SendPulse istnieje, prowadzi użytkownika do płatności i potrafi dodawać tagi oraz pracować z polami kontaktowymi. Brakuje połączenia między dwoma systemami: obecnie, jeśli osoba płaci przez Stripe, SendPulse o tym nie wie Co trzeba zrobić Skonfigurować w Stripe webhook na zdarzenia checkout.session.completed, invoice.paid i customer.subscription.deleted Napisać handler (funkcja serverless lub gotowe narzędzie no-code, takie jak Albato, n8n), który przyjmuje webhook, wyciąga email klienta i typ zdarzenia Przez API SendPulse aktualizować pole lub tag kontaktu (na przykład, club_active = tak/nie) w zależności od zdarzenia Skonfigurować w SendPulse automatyzację, która na podstawie tego pola otwiera dostęp do zamkniętego kanału przy udanej płatności i zamyka przy anulowaniu lub nieudanym pobraniu Podłączyć Stripe Customer Portal, aby uczestnik mógł samodzielnie anulować subskrypcję lub zmienić kartę, a to również docierało do SendPulse przez ten sam webhook jeśli macie sposób na połączenie łatwiejsze bez zewnętrznych webhooków, również to rozważymy! Co powinno wyjść na końcu Działający proces: osoba płaci w Stripe, w ciągu kilku minut otrzymuje dostęp do kanału, przy anulowaniu lub niepowodzeniu pobrania dostęp jest automatycznie zamykany, bez udziału administratora. Plus krótka dokumentacja: gdzie co jest skonfigurowane, jak uruchomić handler ponownie, jeśli się zawiesi, i gdzie szukać w przypadku skargi uczestnika na zamknięty dostęp Kogo szukamy Doświadczenie w pracy z API Stripe i webhookami, doświadczenie z API SendPulse (lub gotowość do szybkiego zapoznania się z nim, dokumentacja jest otwarta), umiejętność uruchomienia prostego handlera serverless lub skonfigurowania połączenia w Albato/n8n. Gotowość do pokazania podobnego przypadku z portfolio będzie plusem

O firmie i bieżącej pracy Firma sprzedaje towary przez: kilka sklepów Rozetka; 5–8 sklepów Prom.ua; kilka sklepów Epicentr. Wolumen: orientacyjnie 50–100 zamówień dziennie. Planowane jest podłączenie good w najbliższym czasieUżywane systemy i metody płatności Rozetka; Prom.ua; Epicentr; Nowa poczta; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Metody płatności: płatność przy odbiorze przez Nową pocztę / NovaPay; RozetkaPay; bezpośredni przelew na IBAN; planowana płatność przez link za pośrednictwem monobank. NovaPay i RozetkaPay przekazują pieniądze w sumie według rejestrów: w rejestrze NovaPay wskazane są TTN; w rejestrze RozetkaPay wskazane są zamówienia. Główne cele Skonfigurować KeyCRM tak, aby właściciel mógł w jednym miejscu: -Widzieć wszystkie zamówienia ze wszystkich sklepów. -Nie tracić zamówień i TTN. -Widzieć aktualny stan każdej wysyłki. -Widzieć faktyczny ruch pieniędzy w zamówieniach. -Automatycznie łączyć otrzymane płatności z odpowiednimi zamówieniami. -Widzieć nieprzypisane płatności, niedopłaty, nadpłaty i inne rozbieżności. -Kontrolować działania pracowników. -Minimalizować pracę ręczną.-Automatyczną fiskalizację - Zbudować odpowiednią automatyzację ruchu zamówienia Przeprowadzić audyt istniejącego KeyCRM Sprawdzić: -aktualne statusy, pola i automatyzacje; -bankowe i płatnicze połączenia; -role i prawa pracowników; -historię działań; -aktualne ustawienia Checkbox; -możliwość realizacji wymagań standardowymi środkami KeyCRM. Na podstawie audytu dostarczyć: -listę znalezionych problemów; -wykaz niezbędnych ustawień; -wykaz zadań, dla których potrzebna jest integracja API lub zewnętrzna usługa; -zalecenia dla lepszej pracy serwisu -ocenę terminów i kosztów. Skonfigurować przyjmowanie i przetwarzanie zamówień Wymagane: ustawić jednolitą sekwencję przetwarzania zamówień; ustawić obowiązkowe pola, bez których zamówienie nie może być przekazane do następnego etapu; stworzyć kontrolę zamówień, które się nie załadowały, załadowały z błędem lub pozostały bez odpowiedzialnego. Skonfigurować ruch i weryfikację płatności Podłączyć do KeyCRM wszystkie używane konta i usługi płatnicze: PrivatBank; monobank; NovaPay; RozetkaPay; ekspedycja monobank po jego podłączeniu. Należy zrealizować: -Automatyczne pobieranie dostępnych wyciągów i transakcji. -Wyświetlanie faktycznych wpływów dla każdego FOP i konta. -Automatyczne przypisanie bezpośredniej płatności na IBAN do zamówienia według numeru zamówienia w komentarzu. -Weryfikację całkowitej wypłaty NovaPay z rejestrem i dalsze przypisanie wierszy rejestru do zamówień według TTN. -Weryfikację całkowitej wypłaty RozetkaPay z rejestrem i dalsze przypisanie wierszy rejestru do zamówień według numeru zamówienia. -Automatyczne przetwarzanie płatności przez link po podłączeniu ekspedycji. -Osobną listę płatności, które nie mogą być automatycznie przypisane. Identyfikacja: -niedopłaty; -nadpłaty; -częściowe płatności; -duplikowane płatności; -płatności bez znalezionego zamówienia; -zamówienia oznaczone jako opłacone bez potwierdzonego wpływu. -Codzienna weryfikacja kwot według FOP, kont i metod płatności. -Status „Opłacono” powinien być ustawiany automatycznie po potwierdzonym zaksięgowaniu pieniędzy na odpowiednim IBAN. Pracownicy nie powinni mieć prawa ustawiać go ręcznie. Jeśli standardowe możliwości KeyCRM są niewystarczające, integrator powinien: proponować integrację API lub zewnętrzny moduł; opisać jego logikę; osobno ocenić rozwój; zapewnić dziennik błędów i ponowne przetwarzanie; nie przypisywać płatności automatycznie przy niejednoznacznym dopasowaniu. Skonfigurować kontrolę zagubionych zamówień Potrzebna jest osobna lista robocza lub raport: zamówienie wpłynęło, ale nie zostało podjęte do pracy; zamówienie potwierdzone, ale nie przekazane do magazynu lub drop; zamówienie gotowe, ale TTN nie została stworzona; TTN stworzona, ale paczka nie została przekazana przewoźnikowi; paczka długo się nie porusza; klient nie odbiera paczki; była przekierowanie; rozpoczęto zwrot; zwrotna paczka nie została odebrana przez firmę; zamówienie dostarczone, ale płatność nie została zaksięgowana; płatność otrzymana, ale nie przypisana do zamówienia; zamówienie pozostało w statusie pośrednim dłużej niż dopuszczalny czas. W przypadku każdego wyjątku powinny być: odpowiedzialny; czas reakcji; zadanie lub powiadomienie; jasny powód; link do zamówienia. 4.7. Skonfigurować prawa i kontrolę pracowników Obowiązkowe ograniczenia: -pracownicy nie mogą usuwać zamówień; -pracownicy nie mogą ręcznie ustawiać statusu „Opłacono”; -pracownicy nie mają dostępu do połączeń bankowych, kluczy API i ustawień administracyjnych.Skonfigurować Checkbox Obecnie paragony z KeyCRM nie są tworzone. Integrator musi: -sprawdzić istniejące konta, kasy i kasjerów Checkbox; -podłączyć kasy odpowiednich FOP; -ustawić metody płatności; -ustawić automatyczną fiskalizację dla uzgodnionych scenariuszy; -ustawić przetwarzanie błędów; -ustawić paragony zwrotu; -przeprowadzić testy.Skonfigurować raporty dla właściciela Właściciel powinien widzieć: -liczbę nowych i nieprzetworzonych zamówień; -problemowe wysyłki; -paczki w oddziale; -zwroty; -dostarczone zamówienia bez otrzymanej płatności; -otrzymane, ale nieprzypisane płatności; -niedopłaty i nadpłaty; -ręczne zmiany pracowników.Format może być realizowany standardowymi listami, filtrami, analizą, zadaniami lub zewnętrznym raportem — sposób proponuje integrator. Przeszkolić pracowników Po konfiguracji przeprowadzić szkolenie: właściciela — kontrola, raporty, błędy i prawa; menedżerów — przetwarzanie zamówień; pracownika dropu — przekazanie zamówienia i kontrola TTN; pracownika magazynu — tworzenie TTN i wysyłka; odpowiedzialnego za finanse — przetwarzanie nieprzypisanych płatności i rozbieżności. Dostarczyć krótkie instrukcje lub nagrania wideo podstawowych operacji. Oczekiwany rezultat Po wykonaniu prac: -wszystkie zamówienia są przetwarzane w KeyCRM; -przegapione i zawieszone zamówienia są automatycznie identyfikowane; -każda TTN jest powiązana z zamówieniem i śledzona; -problemowe paczki trafiają do odpowiedzialnych pracowników; -bankowe i płatnicze wpływy są widoczne w CRM; -jednoznaczne płatności są automatycznie przypisywane do zamówień; -rejestry NovaPay i RozetkaPay są weryfikowane z wpływami i zamówieniami; -niejednoznaczne płatności trafiają na ręczną weryfikację; -pracownicy nie mogą usunąć zamówienia ani ręcznie oznaczyć go jako opłacone; -właściciel widzi ruch pieniędzy i listę odchyleń; -Checkbox działa zgodnie z uzgodnionymi scenariuszami; -zespół jest przeszkolony do pracy. Format propozycji od integratora Przed rozpoczęciem wdrożenia wykonawca powinien dostarczyć: -Wynik audytu. -Proponowany schemat konfiguracji. -Co będzie realizowane standardowymi środkami KeyCRM. -Co wymaga API lub zewnętrznej usługi. -Koszt standardowej konfiguracji. -Osobny koszt rozwoju. -Terminy według etapów. -Wykaz niezbędnych dostępów. -Plan testowania i uruchomienia.

Opracowanie międzynarodowej aplikacji mobilnej pod klucz (Projekt + Kod) W celu obniżenia kosztów, możliwe jest zakupienie gotowego projektu 1. Ogólne wymagania dotyczące projektu Platforma: Rozwój wieloplatformowy na frameworku Flutter (jeden kod dla iOS i Android). Typ platformy: Społeczny zakład / Gry o dyscyplinę (Peer-to-Peer 도전戰). Zadanie Wykonawcy: Pełny cykl rozwoju (UI/UX Projekt w Figma, frontend, backend-serwer, baza danych, integracja czujnika IoT i bramki płatniczej). Wielojęzyczność: Pełne wsparcie lokalizacji (i18n) oraz obsługa wielu walut. 2. Wymagania dotyczące UI/UX Projektu Potrzebny jest nowoczesny, neonowo-technologiczny interfejs w ciemnych kolorach (Tryb Ciemny). Kolory akcentujące: Głęboki grafitowy (tło), jasny zielony (finanse, saldo), jasny czerwony (tryb ochrony, zdarzenia karne). Funkcjonalność: Wyświetlanie 4 głównych ekranów dolnej nawigacji (Dashboard, Pokoje Gier, Portfel, Ustawienia urządzenia). Potrzebne są dynamiczne animacje zmiany salda i wyskakujących alertów. 3. Architektura finansowa (Escrow/Holding/Split) Aplikacja do utrzymania depozytów zgodnie z zasadami dyscypliny. Kluczowa jest integracja bramki płatniczej, która obsługuje Split Payments (Podział płatności) oraz Holding funduszy (Stripe Connect dla rynku globalnego/analogiczne dla lokalnego). Logika transakcji (komendy API backendu): Doładowanie: Środki użytkowników są przypisywane do ich konta i zamrażane na transakcyjnym (escrow) koncie systemu płatniczego. Nie trafiają bezpośrednio na konto firmy. Tryb SOLO: Po wystąpieniu zdarzenia wyzwalającego z czujnika IoT w zakazanych godzinach backend wydaje polecenie systemowi płatniczemu przelania stałej kwoty (kary) z konta transakcyjnego użytkownika na konto rozliczeniowe firmy. Tryb GROUP (Pokój): Użytkownicy tworzą wspólną pulę (na przykład 10 osób po 10 dolarów). Pieniądze są zamrażane w ramach konkretnego Pokoju Gier. Po wystąpieniu zdarzenia wyzwalającego u jednego z uczestników jego kara automatycznie się dzieli: 15% (prowizja platformy) trafia na konto rozliczeniowe firmy, a 85% pozostaje w puli nagród pokoju. Po zakończeniu terminu wyzwania backend automatycznie dzieli zgromadzoną pulę nagród między zwycięzców, a system płatniczy dokonuje automatycznego przelewu (Payout) na ich karty. 4. Struktura kabinetów Kabinet 1: „Osobisty Tracker” (Tryb SOLO) Wskaźnik statusu monitorowania (Aktywny/Dostępny/Zablokowany). Konfigurator interwałów czasowych ochrony (Time Picker) oraz ustawienia wartości kary wyzwalacza. Panel stanu zewnętrznego urządzenia IoT (poziom naładowania czujnika w %, poziom sygnału, status synchronizacji). Kabinet 2: „Pokoje Gier” (Tryb GROUP) Narzędzia do tworzenia prywatnych pokoi (generowanie linków/zaproszeń dla przyjaciół) oraz lista publicznych globalnych lig. Tabela wyników (Leaderboard) uczestników z wyświetlaniem ich aktualnego statusu w czasie rzeczywistym, timer do końca wyzwania oraz wbudowany czat grupowy. Wspólny dział: Wielowalutowy portfel Wyświetlanie salda z automatycznym konwertowaniem lokalnych walut w czasie rzeczywistym. Historia transakcji z przejrzystym logiem wydatków, prowizji i wygranych. 5. Wymagania dotyczące Backend i Integracji IoT Stos: Node.js/Python/Go (do wyboru wykonawcy, uzasadnione). Łącze z IoT: Odbieranie pakietów danych z zewnętrznego modułu Wi-Fi. Czas wysyłania powiadomień Push (przez FCM) na smartfon w momencie wystąpienia zdarzenia z czujnika – mniej niż 1 sekunda. Logika antyfraudowa: Serwer musi analizować przesyłane przez czujnik dane telemetryczne wbudowanego akcelerometru (accel_x/y/z). Jeśli zdarzenie występuje przy zerowej zmianie osi przyspieszenia, transakcja jest oznaczana przez system jako podejrzana (ochrona przed statycznym trzymaniem czujnika), użytkownik otrzymuje powiadomienie.