Backend Developer for Cloud-Based EV Charging System

@diektech

Hi — Elias here from Miami. I understand you're looking to develop a cloud-based backend for an EV charging system, focusing on OCPP WebSocket endpoints and integrating Stripe for payment. The goal is to ensure seamless user interactions and reliable payment processing. What usually matters most here is scalability and reliability. A common issue in setups like this is managing real-time communication between charging stations and the backend. The tricky part is ensuring secure payment transactions while handling varying loads without performance issues. My approach would involve structuring the backend with Node.js for efficient WebSocket handling and using PostgreSQL for robust data management. I’d ensure the API is well-documented and user roles are clearly defined for smooth workflows. This aids in stability and makes future enhancements easier. I've worked on similar systems integrating payment solutions and real-time data management, which helps me foresee potential pitfalls and address them proactively. A few questions to better understand the scope: Q1 – What are your expectations regarding user roles and permissions for the charging stations? Q2 – Are there specific automation features you envision for managing charging sessions? Q3 – How do you plan to handle the payment gateway integration with Stripe for split payments? Looking forward to hearing from you.

@ukroficer

Hello, The key build here is a central OCPP WebSocket server with strict state handling, because charger sessions, temporary check-in PIN validation, and Stripe Connect splits depend on correct event sequencing. For this hospitality EV flow, I would keep hotel systems out of the path and make the backend the source of truth for charger status, session metering, and ledger events. - Node.js + TypeScript backend with PostgreSQL for relational mapping. - OCPP WebSocket endpoint, PIN validation, and real-time usage tracking. - Stripe Connect split logic for property tariffs and business premiums. - AWS deployment with logs, retries, and webhook reconciliation. I would structure this as a greenfield, event-driven backend with idempotent billing and audit trails first. Which OCPP version and charger vendors must the wrapper support from day one? I can start by turning the PRD and schema into the MVP service map. Roman

@adeelpirzada

Hi, I am Adeel. I built Boostifai, a multi-tenant SaaS with subscription billing and real-time processing behind a single API layer, so building split payment logic on Stripe Connect and coordinating real-time device data over WebSockets is familiar territory. For rEVflux I would start by modelling the relational schema around charger sessions, PIN validation and metered usage, then wire the OCPP WebSocket endpoint before layering in the Stripe Connect split so tariff routing is isolated and testable on its own. I would like to offer a short written review first: reading your PRD and schema, flagging any gaps in the payment split logic or session handling, yours to keep either way. Is the OCPP version you are targeting 1.6 or 2.0.1?

@Hrolgar

What happens in your system when a charger drops its WebSocket mid-transaction, does the session resume against the same OCPP transaction ID or restart clean? That's the part of this build that decides whether the PAYG numbers a driver sees ever match what Stripe actually settles. Two things need to hold together for that to work: a session handler that tracks charger state (Available, Preparing, Charging, Finishing) independently of the WebSocket connection itself, since 3-phase destination units drop and reconnect more than people expect, and a MeterValues stream that ties usage to the PIN token from the moment check-in happens, not from when the transaction starts. Get that ordering wrong and PAYG billing drifts from what actually got delivered. On the Stripe side, a destination charge with an application_fee_amount handles the electricity/premium split cleanly, as long as the connected account is wired up before the first transaction rather than patched in after. What I'd build for the 1500 AUD: M1: OCPP WebSocket handler, charger registration and heartbeat, PIN token matching, $495, 5 days M2: MeterValues streaming into a live per-session usage ledger, $600, 5 days M3: Stripe Connect destination charge wired to the ledger split, end to end test, $405, 4 days That number holds for the scope above, though how many charger vendors you're certifying against changes the size of the OCPP handler's edge cases, so I'd rather confirm that before M2 locks in than pad the figure now. Are you targeting a specific set of charger models already, and is the PIN token issued by you or by the property's existing check-in system?

@denisSolution

Hi, I'm Denis, a full-stack developer with experience building IoT backend systems and real-time communication layers, including WebSocket coordination, payment processing, and multi-tenant data synchronization. I understand your needs: a central server speaking OCPP natively to chargers, managing guest sessions via PIN validation, tracking real-time consumption, and splitting revenue instantly through Stripe Connect. The core challenges are reliable WebSocket state management, accurate metering data capture, and deterministic payment routing to properties while maintaining your margin. I'd recommend a Node.js backend with robust WebSocket handling for charger connections, PostgreSQL for transactional data (sessions, chargers, properties), and a clean Stripe Connect integration layer that calculates splits before processing. Implementation would follow this sequence: OCPP protocol and charger connection management, session validation and PIN tokens, metering data aggregation, then Stripe split logic. Thorough testing at each integration point is critical since payment splits and charger state must stay synchronized. A key consideration is graceful charger disconnection handling. If a charger drops mid-session, the system must safely pause metering, preserve session state, and resume cleanly upon reconnection. This prevents billing inconsistencies. I'm ready to start immediately. Let's discuss the details. Thanks, Denis.

@rajat07me

The key challenge here is not just standing up a backend, but making OCPP charger communication, temporary PIN validation, session tracking, and Stripe Connect split payouts behave reliably together in real time. For an EV charging workflow, weak state handling or payment-event timing quickly becomes a billing/support problem, so I’d approach this by defining the charger session lifecycle first, then mapping payment and ledger events cleanly around it. I’ve worked on backend builds where WebSocket communication, transactional logic, and third-party API flows had to stay consistent under live usage. For a system like rEVflux, the important part is building a stable central wrapper around open-protocol charger traffic while keeping the payment split logic auditable and maintainable. If helpful, I can also suggest a clean event flow for charger start/stop, failed auth, and delayed payment states. - Which OCPP version are your destination chargers using today: 1.6J or 2.0.1? - Is the PRD already defining the exact Stripe Connect split model you want to use? - Do you want this delivered in Node.js or Go from the start?

@ahmadayaz

With expertise in IoT, Node.js/Go, and FinTech APIs, I am well-equipped to develop a robust cloud server backend for rEVflux EV charging utility. I will ensure seamless communication using WebSockets, meticulous relational schema design, and Stripe Connect integration for payment processing. Security, scalability, and extensibility will be prioritized, with a focus on analytics and automation for continuous optimization. Let's connect to discuss details and plan for long-term success.

@ykarora26

With extensive IoT and FinTech API expertise, I propose to develop the cloud server backend for rEVflux's EV charging utility. I have successfully implemented similar systems using Node.js and have experience with Stripe Connect integration. Could you provide more details on the expected volume of real-time transactions to optimize the server performance? Regards, Yogesh Kumar

@HamparProd

The critical part here is keeping the charging session, meter values and financial state synchronized even when chargers reconnect, duplicate messages arrive, or Stripe events are delayed. I would build the backend in Go or Node.js with PostgreSQL, exposing the required OCPP WebSocket endpoint and maintaining server-authoritative charger/session state. PIN and vehicle/property validation, PAYG tariff calculations and ledger amounts would remain deterministic, with Stripe Connect handling the property allocation and rEVflux platform fee through idempotent payment/webhook workflows. For Stripe, I would also account explicitly for refunds, failed payments, transfer reversals and reconciliation rather than treating the initial payment as the end of the transaction. I can start immediately after award once the PRD, schema, OCPP version and charger test access are confirmed.

@santoshkumars17

With over 5 years of professional experience in both frontend and backend development, I am confident I can deliver a reliable solution for your cloud-based EV charging system. My expertise in Node.js, NoSQL, and MongoDB positions me well to create the open-protocol central server wrapper you're seeking. I understand the complex communication requirements between standard 3-phase destination chargers and your central server and will employ native WebSockets to ensure seamless data transfer. I have also worked with FinTech APIs which is highly relevant for this project as you seek instant tariff splitting via Stripe Connect. My proficiency with API integration will enable me to develop the programmatic backend logic necessary for real-time Pay-As-You-Go usage metrics, routing electricity costs back to the property ledger, and convenience premiums to your business account. Moreover, I always strive to deliver clean, optimized, and maintainable code in all my projects. I believe that's particularly important for mission-critical applications like yours. You'll appreciate my on-time delivery and clear communication style that helps usher projects forward smoothly. Let's turn your vision for rEVflux into reality together.

@ZohaibRoy

⭐⭐⭐⭐⭐ Build EV Charging Cloud Server Backend with WebSocket & Stripe Connect ❇️ Hi My Friend, I hope you are doing well. I've reviewed your project requirements and see you are looking for a senior Backend Developer for your EV charging cloud server. Look no further; Zohaib is here to help you! My team has successfully completed 50+ similar projects for backend development. I will create a robust server that communicates with EV chargers over WebSockets and integrates Stripe for payment processing. ➡️ Why Me? I can easily build your EV charging cloud server as I have 5 years of experience in backend development, IoT solutions, and API integration. My expertise includes Node.js, Go, and real-time data handling. Additionally, I have a strong grip on database management and payment gateways, ensuring a seamless and efficient system for your project. ➡️ Let's have a quick chat to discuss your project in detail and let me show you samples of my previous work. I look forward to discussing this with you in our chat. ➡️ Skills & Experience: ✅ Node.js ✅ Go ✅ WebSocket Communication ✅ API Development ✅ Stripe Integration ✅ IoT Solutions ✅ Database Management ✅ Real-Time Data Processing ✅ Cloud Server Development ✅ Relational Database Design ✅ Payment Gateway Integration ✅ Project Documentation Waiting for your response! Best Regards, Zohaib

@CorporateRD

Being an experienced Backend Developer, I have a thorough understanding of the intricate and evolving nature of IoT-based systems which make me well-suited for this project. My expertise in Node.js/Go, FinTech APIs, and PostgreSQL pairs perfectly with your needs. Having worked on similar projects before, I'm well-versed in building cloud server backends and handling WebSocket communications effectively. In addition to my technical proficiency, I believe in delivering secure, user-friendly, and production-ready software that guarantees long-term growth. My AI-first development approach and experience with Vibe Coding are especially beneficial for this project as it requires a fast, scalable prototype without compromising security. Furthermore, my adeptness in strategic API integration and third-party automation would prove essential while integrating with Stripe Connect for pay-as-you-go usage. With me on board, you can expect clean and efficient code that complements the already existing relational schema. Lastly, my strong focus on business outcomes ensures that your project not only runs smoothly but also aligns perfectly with your organization's targets. Let's discuss your vision

@arslanshahid386

Hi, I noticed your project requires a backend developer to establish a cloud server for rEVflux, focusing on an OCPP WebSocket endpoint and Stripe Connect PAYG Split. With extensive experience in Node.js and API integration, I can develop a robust and scalable backend solution that meets your specific needs. My experience with IoT systems and FinTech APIs ensures seamless communication and secure transaction processing, crucial for bypassing traditional hotel management networks. Could you share more about any existing infrastructure or specific challenges you've encountered with the current setup?

@sanjana22kr

hello there , I can build the rEVflux cloud backend as an OCPP-based central server, covering the charger communication layer, real-time PAYG metering, relational data model, and Stripe Connect split payments. I’ll handle: Node.js/Go backend with production-ready OCPP WebSocket endpoints for 3-phase destination chargers. Charger registration, authentication, connection lifecycle, remote commands and real-time telemetry. Relational schema implementation for vehicles, properties, chargers, sessions, users, PIN/check-in tokens and transaction/ledger records. Secure temporary PIN validation and authorization before charging starts. Real-time energy/session usage tracking, tariff calculation and charging-session reconciliation. Stripe Connect integration for automated PAYG payment collection and programmatic revenue splitting between property electricity costs and rEVflux convenience premiums. Webhook handling, idempotency, payment/session reconciliation, audit trails and failure recovery. Dockerized deployment, environment configuration, logging, monitoring and API documentation. I can work directly from your PRD and database schema and take the backend from architecture through implementation, testing and cloud deployment. Please share the PRD/schema, and I can review the requirements and provide a fixed scope, milestones and timeline. thanks

@TechizeBuilder

Dear Client, I read "Backend Developer for Cloud-Based EV Charging System" carefully and understand you are looking for a full-stack developer who can handle both application development and AI integration. I have experience with NoSQL Couch & Mongo, Inventory Management, Node.js, PostgreSQL, Stripe and can work across the complete stack — frontend, backend, APIs, databases, authentication, third-party integrations and AI features. I can build scalable applications using modern technologies while keeping the codebase maintainable and production-ready. A few quick questions: Which AI models/APIs are you currently planning to use? Is there an existing application/codebase, or will the project be built from scratch? Thanks & Regards, Deepak

@melikatfz

Hi there, Building a robust EV charging backend requires handling high-concurrency WebSocket connections for real-time OCPP messaging while ensuring zero-latency payment splitting through Stripe Connect, and without the right architecture, handling concurrent charging sessions can lead to dropped telemetry data or failed payment routing. I will engineer a high-performance Node.js or Go backend that seamlessly integrates the OCPP protocol, relational session mapping, and instant Stripe Connect PAYG tariff splits to automate property ledger payouts and platform revenue securely. To make sure we are fully aligned on the implementation, here are my questions: 1. Are you using standard OCPP 1.6J or OCPP 2.0.1 for the charger WebSocket communication? 2. Do you have the specific PostgreSQL schema and Stripe Connect account structures already mapped out in the PRD? Drop me a message so we can get started right away.

@longngoc2307

==== Hi - Truong here ==== "OCPP WEBSOCKET + STRIPE CONNECT PAYG BACKEND" - you need the charger, hotel ledger and payment split to stay in sync in real time. I’d build the core service in Node.js with PostgreSQL, using OCPP WebSockets for charger sessions and Stripe Connect for the PAYG split. The important part is making charging sessions safe to resume after a dropped WebSocket, without charging twice or losing meter data. I’d keep vehicle/check-in validation, charger state, session metering and Stripe transfers as separate services with clear transaction boundaries. That makes the backend easier to test now and extend later for more charger models and properties. Can you share the PRD and relational schema so I can confirm the OCPP version, charger message flow and exact Stripe split rules before locking the implementation scope? Looking forward to work with you.

@albertc1996

Reliable WebSocket handling and precise ledger reconciliation decide whether a PAYG charging backend stays dependable under load. Setting up the central WebSocket server to handle charger status cycles and check-in PIN authorization is direct, paired with Node.js to coordinate session metrics. On the payment side, Stripe Connect transfer splits can be triggered programmatically on transaction completion to route property costs and platform fees cleanly. I have built comparable multi-tier transactional backends and custom APIs, such as the architecture in https://www.freelancer.com/u/albertc1996/14028558 . A quick review of the PRD connection events would be my first step.

@ssquare489

The core of rEVflux is the OCPP WebSocket session state plus Stripe Connect settlement logic, so I’d design those as one auditable transaction flow rather than two loosely connected services. One issue before quoting precisely: the attachments visible here appear to be a Safari Travel specification and a vehicle/wheel inventory file, not the rEVflux PRD or relational schema. I can still give an initial estimate from your brief, but I’d finalize scope after reviewing the correct documents. I’d use NestJS/Node.js, PostgreSQL, Redis, WebSockets, Docker, and Stripe Connect. The two priorities would be integrations and maintainability, with charger sessions, meter values, PIN validation, tariff calculation, payment intent state, property ledger allocation, webhook reconciliation, and audit logs kept explicit and idempotent. I’d steer away from trying to split money on every OCPP meter update. Usage should accumulate during the charging session, then be finalized and reconciled at session close before the Stripe Connect transfer logic runs. A relevant project is FileChannels, where I worked with real-time communication, WebSockets, Stripe, multi-user state, and production integrations. Initial estimate: 8–10 weeks, $12,000–$16,000.