We have a chatbot on SendPulse and need to set it up so that it allows subscription to a closed club via Stripe, which should automatically renew every month, and provide subscription management, as well as automatically open and close access in case of its start or end. What is already ready A product with monthly billing has been created in Stripe, along with a payment link for it. The bot in SendPulse exists, guides the user to payment, and can set tags and work with contact fields. There is a lack of integration between the two systems: currently, if a person pays through Stripe, SendPulse does not get notified about it. What needs to be done Set up a webhook in Stripe for the events checkout.session.completed, invoice.paid, and customer.subscription.deleted. Write a handler (serverless function or a ready-made no-code tool like Albato, n8n) that receives the webhook, extracts the client's email and the type of event. Use the SendPulse API to update the contact field or tag (for example, club_active = yes/no) depending on the event. Set up automation in SendPulse that opens access to the closed channel based on this field upon successful payment and closes it upon cancellation or failed billing. Connect the Stripe Customer Portal so that the participant can cancel the subscription or change the card themselves, and this should also be sent to SendPulse via the same webhook. If you have an easier way to integrate without third-party webhooks, we will consider that too! What should be the outcome A working chain: a person pays in Stripe, receives access to the channel within a couple of minutes, and upon cancellation or failed billing, access is automatically closed without administrator involvement. Plus, a short documentation: where everything is set up, how to restart the handler if it fails, and where to look in case a participant complains about closed access. Who we are looking for Experience with Stripe API and webhooks, experience with SendPulse API (or readiness to quickly understand it, documentation is open), ability to set up a simple serverless handler or configure integration in Albato/n8n. Willingness to show a similar case from the portfolio will be a plus.
About the company and current work The company sells products through: several Rozetka stores; 5–8 stores Prom.ua; several Epicentr stores. Volume: approximately 50–100 orders per day. A connection to Good will be established in the near future.Used systems and payment methods Rozetka; Prom.ua; Epicentr; Nova Poshta; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Payment methods: cash on delivery via Nova Poshta / NovaPay; RozetkaPay; direct transfer to IBAN; payment via link through monobank acquiring is planned. NovaPay and RozetkaPay transfer money in total amounts according to registers: the NovaPay register includes TTH; the RozetkaPay register includes orders. Main goals Set up KeyCRM so that the owner can: -See all orders from all stores. -Not lose orders and TTH. -See the current status of each shipment. -See the actual movement of money for orders. -Automatically link received payments to the corresponding orders. -See unlinked payments, underpayments, overpayments, and other discrepancies. -Control employee actions. -Minimize manual work.-Automatic fiscalization - Establish correct automation for order movement Conduct an audit of the existing KeyCRM Check: -current statuses, fields, and automations; -banking and payment connections; -roles and rights of employees; -action history; -current Checkbox settings; -the possibility of implementing requirements with standard KeyCRM tools. Based on the audit results, provide: -a list of identified problems; -a list of necessary settings; -a list of tasks that require API integration or external service; -recommendations for better service operation -an assessment of timelines and costs. Set up order receipt and processing It is necessary to: set up a unified order processing sequence; set up mandatory fields without which the order cannot be passed to the next stage; create control for orders that did not load, loaded with errors, or remained without a responsible person. Set up payment movement and reconciliation Connect all used accounts and payment services to KeyCRM: PrivatBank; monobank; NovaPay; RozetkaPay; monobank acquiring after its connection. It is necessary to implement: -Automatic retrieval of available statements and transactions. -Display of actual receipts for each FOP and account. -Automatic linking of direct payment to IBAN to the order by order number in the comment. -Reconciliation of the total payment from NovaPay with the register and further linking of register lines to orders by TTH. -Reconciliation of the total payment from RozetkaPay with the register and further linking of register lines to orders by order number. -Automatic processing of payments via link after connecting acquiring. -A separate list of payments that cannot be linked automatically. Identification: -underpayment; -overpayment; -partial payment; -duplicate payment; -payment without a found order; -an order marked as paid without confirmed receipt. -Daily reconciliation of amounts by FOP, accounts, and payment methods. -The status "Paid" should be set automatically after confirmed receipt of money to the corresponding IBAN. Employees should not have the right to set it manually. If the standard capabilities of KeyCRM are insufficient, the integrator must: offer API integration or an external module; describe its logic; separately assess the development; provide an error log and reprocessing; not link payment automatically in case of ambiguous matches. Set up control of lost orders A separate working list or report is needed: the order was received but not taken into work; the order is confirmed but not transferred to the warehouse or drop; the order is ready but TTH is not created; TTH is created but the package is not handed over to the carrier; the package is not moving for a long time; the client does not pick up the package; there was a redirection; a return has started; the return package has not been received by the company; the order is delivered but payment is not credited; payment is received but not linked to the order; the order remained in an intermediate status longer than the allowable period. For each exception, there should be: responsible person; reaction time; task or notification; clear reason; link to the order. 4.7. Set up rights and control of employees Mandatory restrictions: -employees cannot delete orders; -employees cannot manually set the status "Paid"; -employees do not have access to banking connections, API keys, and administrative settings.Set up Checkbox Currently, checks from KeyCRM are not created. The integrator needs to: -check existing accounts, cash registers, and cashiers in Checkbox; -connect the cash registers of the respective FOP; -set up payment methods; -set up automatic fiscalization for agreed scenarios; -set up error handling; -set up return checks; -conduct testing.Set up reports for the owner The owner should see: -the number of new and unprocessed orders; -problematic shipments; -packages in the department; -returns; -delivered orders without received payment; -received but unlinked payments; -underpayments and overpayments; -manual changes by employees.The format can be implemented using standard lists, filters, analytics, tasks, or an external report — the method is proposed by the integrator. Train employees After setup, conduct training: for the owner — control, reports, errors, and rights; for managers — order processing; for the drop employee — order transfer and TTH control; for the warehouse employee — TTH creation and shipping; for the finance responsible — processing unlinked payments and discrepancies. Provide short instructions or video recordings of key operations. Expected result After the work is completed: -all orders are processed in KeyCRM; -missed and stuck orders are automatically identified; -each TTH is linked to an order and tracked; -problematic packages are assigned to responsible employees; -banking and payment receipts are visible in CRM; -unambiguous payments are automatically linked to orders; -the registers of NovaPay and RozetkaPay are reconciled with receipts and orders; -ambiguous payments go for manual verification; -employees cannot delete an order or manually mark it as paid; -the owner sees the movement of money and a list of discrepancies; -Checkbox works according to agreed scenarios; -the team is trained to work. Format of the proposal from the integrator Before the implementation begins, the contractor must provide: -Audit results. -Proposed setup scheme. -What will be implemented with standard KeyCRM tools. -What will require API or external service. -Cost of standard setup. -Separate cost of development. -Timelines by stages. -List of necessary accesses. -Testing and launch plan.
Development of an international mobile application turnkey (Design + Code) To reduce costs, possibly do not buy a ready-made design 1. General requirements for the project Platform: Cross-platform development on the Flutter framework (one code for iOS and Android). Platform type: Social betting / Gaming disputes on discipline (Peer-to-Peer 도전戰). Executor's task: Full development cycle (UI/UX Design in Figma, frontend, backend server, database, integration of IoT control sensor and payment gateway). Multilingualism: Full support for localization (i18n) and working with multiple currencies. 2. UI/UX Design Requirements A modern, neon-tech interface in dark tones (Dark Mode) is required. Accent colors: Deep graphite (background), bright green (finances, balance), bright red (protection mode on, penalty events). Functionality: Display of 4 main screens in the bottom navigation (Dashboard, Game Rooms, Wallet, Device Settings). Dynamic animations for balance changes and pop-up alerts are needed. 3. Financial architecture (Escrow/Holding/Split) The application is related to holding deposits for compliance with discipline rules. Integration of a payment gateway that supports Split Payments and Holding funds (Stripe Connect for the global market/analogues for local) is critically important. Transaction logic (backend API commands): Replenishment: Users' funds are tied to their account and frozen in the transit (escrow) account of the payment system. They do not go directly to the company's account. SOLO mode: When a trigger event occurs from the IoT sensor during prohibited hours, the backend commands the payment system to transfer a fixed amount (penalty) from the user's transit account to the company's settlement account. GROUP mode (Room): Users form a common pool (for example, 10 people $10). The money is frozen within a specific Game Room. When a trigger event occurs for one of the participants, the amount of their penalty is automatically split: 15% (platform fee) goes to the company's settlement account, and 85% remains within the room's prize pool. After the challenge period ends, the backend automatically distributes the accumulated prize pool among the winners, and the payment system makes an automatic transfer (Payout) to their cards. 4. Cabinet Structure Cabinet 1: "Personal Tracker" (SOLO Mode) Monitoring status indicator (Active/Available/Blocked). Configurator for security time intervals (Time Picker) and settings for penalty trigger costs. Status panel for the external IoT device (sensor battery charge in %, signal level, synchronization status). Cabinet 2: "Game Rooms" (GROUP Mode) Toolkit for creating private rooms (generating invite links/codes for friends) and a list of public global leagues. Leaderboard of participants displaying their current status in real-time, timer until the end of the challenge, and built-in group chat. General section: Multicurrency wallet Display of balance with automatic conversion of local currencies in real-time. Transaction history with a transparent log of deductions, fees, and winnings. 5. Backend and IoT Integration Requirements Stack: Node.js/Python/Go (at the executor's choice, justified). Connection with IoT: Receiving data packets from an external Wi-Fi module. Speed of sending Push notifications (via FCM) to the smartphone upon an event from the sensor – less than 1 second. Anti-fraud logic: The server must analyze the telemetry data transmitted by the built-in accelerometer (accel_x/y/z). If an event occurs with zero change in acceleration axes, the transaction is marked by the system as suspicious (protection against static holding of the sensor), and the user is sent a warning.