Wir haben einen Chatbot auf SendPulse und benötigen eine Einstellung, damit über ihn die Möglichkeit besteht, ein Abonnement für einen geschlossenen Club über Stripe abzuschließen, das automatisch jeden Monat verlängert wird, und dass er die Verwaltung des Abonnements ermöglicht sowie automatisch den Zugang öffnet und schließt, falls es beginnt oder endet. Was bereits bereit ist In Stripe wurde ein Produkt mit monatlicher Abrechnung und ein Zahlungslink dafür erstellt. Der Bot in SendPulse existiert, führt den Benutzer zur Zahlung und kann Tags setzen und mit Kontaktfeldern arbeiten. Es fehlt die Verbindung zwischen den beiden Systemen: Momentan erfährt SendPulse nicht, wenn jemand über Stripe bezahlt. Was zu tun ist In Stripe einen Webhook für die Ereignisse checkout.session.completed, invoice.paid und customer.subscription.deleted einrichten. Ein Handler (serverless-Funktion oder ein fertiges No-Code-Tool wie Albato, n8n) schreiben, der den Webhook empfängt, die E-Mail des Kunden und den Ereignistyp extrahiert. Über die API von SendPulse das Feld oder Tag des Kontakts aktualisieren (zum Beispiel, club_active = ja/nein) je nach Ereignis. In SendPulse eine Automatisierung einrichten, die basierend auf diesem Feld den Zugang zum geschlossenen Kanal bei erfolgreicher Zahlung öffnet und bei Stornierung oder fehlgeschlagener Abbuchung schließt. Das Stripe Customer Portal anschließen, damit der Teilnehmer das Abonnement selbst kündigen oder die Karte wechseln kann, und dies ebenfalls über denselben Webhook an SendPulse übermittelt wird. Wenn Sie einen einfacheren Weg zur Verbindung ohne externe Webhooks haben, ziehen wir das auch in Betracht! Was am Ende herauskommen sollte Ein funktionierender Workflow: Eine Person bezahlt bei Stripe, erhält innerhalb weniger Minuten Zugang zum Kanal, bei Stornierung oder fehlgeschlagener Abbuchung wird der Zugang automatisch ohne Beteiligung eines Administrators geschlossen. Außerdem eine kurze Dokumentation: wo was eingestellt ist, wie man den Handler neu starten kann, falls er ausfällt, und wo man hinschauen sollte, wenn ein Teilnehmer sich über den geschlossenen Zugang beschwert. Wen wir suchen Erfahrung mit der Stripe API und Webhooks, Erfahrung mit der SendPulse API (oder die Bereitschaft, sich schnell darin einzuarbeiten, die Dokumentation ist offen), die Fähigkeit, einen einfachen serverless-Handler zu erstellen oder eine Verbindung in Albato/n8n einzurichten. Die Bereitschaft, einen ähnlichen Fall aus dem Portfolio zu zeigen, wäre ein Plus.
Über das Unternehmen und die aktuelle Arbeit Das Unternehmen verkauft Waren über: mehrere Geschäfte von Rozetka; 5–8 Geschäfte Prom.ua; mehrere Geschäfte von Epicentr. Volumen: ungefähr 50–100 Bestellungen pro Tag. Es ist geplant, in naher Zukunft Good zu verbinden.Verwendete Systeme und Zahlungsmethoden Rozetka; Prom.ua; Epicentr; Neue Post; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Zahlungsmethoden: Nachnahme über Neue Post / NovaPay; RozetkaPay; Direktüberweisung auf IBAN; Es ist geplant, die Zahlung über einen Link durch das Acquiring von monobank zu ermöglichen. NovaPay und RozetkaPay überweisen Geld in Gesamtsummen gemäß den Registern: Im Register von NovaPay sind die TTH angegeben; Im Register von RozetkaPay sind die Bestellungen angegeben. Hauptziele KeyCRM so einrichten, dass der Eigentümer an einem Ort: -Alle Bestellungen aus allen Geschäften sehen kann. -Bestellungen und TTH nicht verliert. -Den aktuellen Status jeder Sendung sehen kann. -Die tatsächlichen Geldbewegungen zu den Bestellungen sehen kann. -Eingegangene Zahlungen automatisch mit den entsprechenden Bestellungen verknüpfen kann. -Ungebundene Zahlungen, Unterzahlungen, Überzahlungen und andere Abweichungen sehen kann. -Die Handlungen der Mitarbeiter kontrollieren kann. -Manuelle Arbeit minimieren kann.-Automatische Fiskalisierung - Die richtige Automatisierung des Bestellflusses aufbauen Eine Prüfung des bestehenden KeyCRM durchführen Überprüfen: -aktuelle Status, Felder und Automatisierungen; -Bank- und Zahlungsanbindungen; -Rollen und Rechte der Mitarbeiter; -Aktivitätsgeschichte; -aktuelle Checkbox-Einstellungen; -die Möglichkeit, die Anforderungen mit den Standardmitteln von KeyCRM umzusetzen. Nach der Prüfung bereitstellen: -eine Liste der gefundenen Probleme; -eine Liste der erforderlichen Einstellungen; -eine Liste der Aufgaben, für die eine API-Integration oder ein externer Dienst benötigt wird; -Empfehlungen für eine bessere Serviceleistung -eine Schätzung der Fristen und Kosten. Die Annahme und Verarbeitung von Bestellungen einrichten Es ist notwendig: eine einheitliche Reihenfolge zur Verarbeitung von Bestellungen einzurichten; obligatorische Felder einzurichten, ohne die eine Bestellung nicht an die nächste Stufe übergeben werden kann; eine Kontrolle über Bestellungen zu schaffen, die nicht hochgeladen wurden, mit Fehlern hochgeladen wurden oder ohne Verantwortlichen geblieben sind. Die Bewegung und Abstimmung von Zahlungen einrichten Alle verwendeten Konten und Zahlungsdienste mit KeyCRM verbinden: PrivatBank; monobank; NovaPay; RozetkaPay; Acquiring von monobank nach dessen Anbindung. Es ist notwendig zu realisieren: -Automatische Abholung verfügbarer Auszüge und Transaktionen. -Darstellung der tatsächlichen Einnahmen für jeden FOP und jedes Konto. -Automatische Verknüpfung der Direktzahlung auf IBAN mit der Bestellung anhand der Bestellnummer im Kommentar. -Abstimmung der Gesamtzahlung von NovaPay mit dem Register und anschließende Verknüpfung der Zeilen des Registers mit den Bestellungen anhand der TTH. -Abstimmung der Gesamtzahlung von RozetkaPay mit dem Register und anschließende Verknüpfung der Zeilen des Registers mit den Bestellungen anhand der Bestellnummer. -Automatische Verarbeitung von Zahlungen über einen Link nach der Anbindung des Acquirings. -Eine separate Liste von Zahlungen, die nicht automatisch verknüpft werden können. Erkennung: -Unterzahlungen; -Überzahlungen; -Teilzahlungen; -doppelte Zahlungen; -Zahlungen ohne gefundene Bestellung; -Bestellungen, die als bezahlt markiert sind, ohne bestätigten Eingang. -Tägliche Abstimmung der Beträge nach FOP, Konten und Zahlungsmethoden. -Der Status „Bezahlt“ muss automatisch nach bestätigtem Geldeingang auf die entsprechende IBAN gesetzt werden. Mitarbeiter dürfen ihn nicht manuell setzen. Wenn die Standardmöglichkeiten von KeyCRM nicht ausreichen, muss der Integrator: API-Integration oder ein externes Modul vorschlagen; seine Logik beschreiben; die Entwicklung separat bewerten; ein Fehlerprotokoll und eine Wiederverarbeitung sicherstellen; die Zahlung nicht automatisch bei mehrdeutiger Übereinstimmung verknüpfen. Die Kontrolle über verlorene Bestellungen einrichten Eine separate Arbeitsliste oder einen Bericht ist erforderlich: Die Bestellung ist eingegangen, aber nicht bearbeitet worden; Die Bestellung ist bestätigt, aber nicht an das Lager oder Drop übergeben worden; Die Bestellung ist fertig, aber die TTH wurde nicht erstellt; Die TTH wurde erstellt, aber das Paket wurde nicht an den Frachtführer übergeben; Das Paket bewegt sich lange nicht; Der Kunde holt das Paket nicht ab; Es gab eine Weiterleitung; Die Rücksendung hat begonnen; Das Rücksendepaket wurde nicht vom Unternehmen erhalten; Die Bestellung wurde geliefert, aber die Zahlung wurde nicht gutgeschrieben; Die Zahlung wurde erhalten, aber nicht mit der Bestellung verknüpft; Die Bestellung blieb länger als zulässig im Zwischenstatus. Für jede Ausnahme müssen sein: Verantwortlicher; Reaktionszeit; Aufgabe oder Benachrichtigung; verständlicher Grund; Link zur Bestellung. 4.7. Die Rechte und Kontrolle der Mitarbeiter einrichten Obligatorische Einschränkungen: -Mitarbeiter dürfen Bestellungen nicht löschen; -Mitarbeiter dürfen den Status „Bezahlt“ nicht manuell setzen; -Mitarbeiter haben keinen Zugang zu Bankverbindungen, API-Schlüsseln und administrativen Einstellungen.Checkbox einrichten Derzeit werden keine Belege aus KeyCRM erstellt. Der Integrator muss: -die bestehenden Konten, Kassen und Kassierer von Checkbox überprüfen; -die Kassen der entsprechenden FOP anschließen; -Zahlungsmethoden einrichten; -automatische Fiskalisierung für vereinbarte Szenarien einrichten; -Fehlerbehandlung einrichten; -Rückbelege einrichten; -Tests durchführen.Berichte für den Eigentümer einrichten Der Eigentümer muss sehen: -die Anzahl neuer und unbearbeiteter Bestellungen; -problematische Sendungen; -Pakete in der Filiale; -Rücksendungen; -gelieferte Bestellungen ohne eingegangene Zahlung; -eingegangene, aber nicht verknüpfte Zahlungen; -Unterzahlungen und Überzahlungen; -manuelle Änderungen der Mitarbeiter.Das Format kann mit Standardlisten, Filtern, Analysen, Aufgaben oder einem externen Bericht realisiert werden – die Methode schlägt der Integrator vor. Die Mitarbeiter schulen Nach der Einrichtung eine Schulung durchführen: für den Eigentümer – Kontrolle, Berichte, Fehler und Rechte; für die Manager – Bearbeitung von Bestellungen; für den Drop-Mitarbeiter – Übergabe der Bestellung und Kontrolle der TTH; für den Lagerarbeiter – Erstellung der TTH und Versand; für den Finanzverantwortlichen – Bearbeitung ungebundener Zahlungen und Abweichungen. Kurze Anleitungen oder Videoaufzeichnungen der wichtigsten Operationen bereitstellen. Erwartetes Ergebnis Nach Abschluss der Arbeiten: -werden alle Bestellungen in KeyCRM bearbeitet; -werden versäumte und hängende Bestellungen automatisch erkannt; -ist jede TTH mit der Bestellung verknüpft und wird verfolgt; -gelangen problematische Pakete zu den verantwortlichen Mitarbeitern; -sind Bank- und Zahlungseingänge in der CRM sichtbar; -werden eindeutige Zahlungen automatisch mit den Bestellungen verknüpft; -werden die Register von NovaPay und RozetkaPay mit den Einnahmen und Bestellungen abgeglichen; -gelangen mehrdeutige Zahlungen zur manuellen Überprüfung; -dürfen Mitarbeiter keine Bestellung löschen oder manuell als bezahlt markieren; -sieht der Eigentümer die Geldbewegungen und die Liste der Abweichungen; -funktioniert Checkbox gemäß den vereinbarten Szenarien; -ist das Team im Umgang geschult. Format des Angebots vom Integrator Vor Beginn der Implementierung muss der Auftragnehmer bereitstellen: -Das Ergebnis der Prüfung. -Den vorgeschlagenen Einstellungsplan. -Was mit den Standardmitteln von KeyCRM umgesetzt wird. -Was API oder einen externen Dienst erfordert. -Die Kosten der Standardkonfiguration. -Die separate Kosten der Entwicklung. -Fristen nach Phasen. -Eine Liste der erforderlichen Zugänge. -Test- und Implementierungsplan.
Entwicklung einer internationalen mobilen Anwendung schlüsselfertig (Design + Code) Um Kosten zu sparen, möglicherweise ein fertiges Design kaufen. 1. Allgemeine Anforderungen an das Projekt Plattform: Cross-Plattform-Entwicklung mit dem Flutter-Framework (ein Code für iOS und Android). Plattformtyp: Soziale Wetten / Spielkonkurrenzen in Disziplin (Peer-to-Peer 도전戰). Aufgabe des Auftragnehmers: Vollständiger Entwicklungszyklus (UI/UX-Design in Figma, Frontend, Backend-Server, Datenbank, Integration des IoT-Sensors zur Kontrolle und des Zahlungsgateways). Mehrsprachigkeit: Vollständige Unterstützung der Lokalisierung (i18n) und Arbeit mit mehreren Währungen. 2. Anforderungen an das UI/UX-Design Es wird ein modernes, neon-technologisches Interface in dunklen Tönen (Dark Mode) benötigt. Akzentfarben: Tiefes Graphit (Hintergrund), leuchtendes Grün (Finanzen, Balance), leuchtendes Rot (Schutzmodus aktiviert, Strafereignisse). Funktionalität: Anzeige von 4 Hauptbildschirmen der unteren Navigation (Dashboard, Spielräume, Wallet, Geräteeinstellungen). Dynamische Animationen zur Änderung des Saldos und Popup-Alerts sind erforderlich. 3. Finanzarchitektur (Escrow/Holding/Split) Die Anwendung ist für die Einhaltung der Disziplinregeln zur Einbehaltung von Einlagen verantwortlich. Die Integration eines Zahlungsgateways, das Split Payments (Zahlungsteilung) und das Halten von Geldern unterstützt, ist von entscheidender Bedeutung (Stripe Connect für den globalen Markt/Äquivalente für den lokalen Markt). Transaktionslogik (API-Befehle des Backends): Aufladung: Die Gelder der Benutzer werden ihrem Konto zugeordnet und auf einem Transit- (Escrow-) Konto des Zahlungssystems eingefroren. Sie gelangen nicht direkt auf das Konto des Unternehmens. SOLO-Modus: Bei Eintreten eines Triggerereignisses vom IoT-Sensor in den verbotenen Stunden gibt das Backend den Befehl an das Zahlungssystem, einen festen Betrag (Strafe) vom Transitkonto des Benutzers auf das Geschäftskonto zu überweisen. GROUP-Modus (Raum): Benutzer bilden einen gemeinsamen Pool (z. B. 10 Personen $10). Das Geld wird innerhalb eines bestimmten Spielraums eingefroren. Bei Eintreten eines Triggerereignisses bei einem der Teilnehmer wird die Höhe seiner Strafe automatisch aufgeteilt: 15% (Plattformgebühr) gehen auf das Geschäftskonto, während 85% im Preisfonds des Raums verbleiben. Nach Ablauf der Challenge verteilt das Backend automatisch den angesammelten Preisfonds unter den Gewinnern, und das Zahlungssystem führt eine automatische Überweisung (Payout) auf deren Karten durch. 4. Struktur der Konten Konto 1: „Persönlicher Tracker“ (SOLO-Modus) Statusanzeige für die Überwachung (Aktiv/Verfügbar/Blockiert). Konfigurator für Zeitintervalle der Überwachung (Time Picker) und Einstellung der Kosten für den Straftrigger. Statusanzeige des externen IoT-Geräts (Batteriestatus des Sensors in %, Signalstärke, Synchronisierungsstatus). Konto 2: „Spielräume“ (GROUP-Modus) Werkzeug zur Erstellung privater Räume (Generierung von Einladungslinks/Codes für Freunde) und Liste öffentlicher globaler Ligen. Rangliste (Leaderboard) der Teilnehmer mit Anzeige ihres aktuellen Status in Echtzeit, Timer bis zum Ende der Challenge und integrierter Gruppenchat. Gemeinsamer Abschnitt: Multicurrency-Wallet Anzeige des Saldos mit automatischer Umrechnung lokaler Währungen in Echtzeit. Transaktionshistorie mit transparentem Protokoll von Abhebungen, Gebühren und Gewinnen. 5. Anforderungen an das Backend und Integration von IoT Stack: Node.js/Python/Go (nach Wahl des Auftragnehmers, begründet). Verbindung zu IoT: Empfang von Datenpaketen vom externen Wi-Fi-Modul. Geschwindigkeit der Push-Benachrichtigung (über FCM) auf das Smartphone bei Eintreten eines Ereignisses vom Sensor – weniger als 1 Sekunde. Anti-Fraud-Logik: Der Server muss die vom Sensor übermittelten Telemetriedaten des eingebauten Beschleunigungsmessers (accel_x/y/z) analysieren. Wenn ein Ereignis bei null Änderung der Beschleunigungsachsen auftritt, wird die Transaktion vom System als verdächtig markiert (Schutz vor statischer Sensorhaltung), und der Benutzer erhält eine Warnung.