Payment Processing in Rental and Sharing Services: Architecture and Implementation Costs

In the rental business, payment processing is not a technical detail—it is the foundation of the business model. Everything else—the fleet, the app, the marketing—works only as well as this component is built. In sharing services, payment is a real-time distributed system where banking operations control physical hardware. Any architectural flaw in this part of the system directly translates into lost revenue.

From an engineering perspective, the task is to synchronize Bank → Backend → Device so that money becomes the control signal for the hardware.

Why Payments in Sharing Are a Complex Engineering Challenge

In classic e-commerce, a transaction ends with a payment. In sharing, it is the opposite:

• The service begins before the final payment.

• The final amount is unknown in advance.

• The asset is already in the customer's hands.

The system's goal is not just to "process a transaction," but to eliminate the risk of capital loss during the rental process through a chain of managed events.

Payment Circuit Architecture

1. Tokenization — Card Binding

The user enters their card details via the bank's SDK once. The service receives a Token—a digital key that allows charging the card in the future without re-entering data or SMS confirmation.

• Engineering Tip: At this stage, idempotency keys are critical. Without them, a network glitch or a double-click from a client can lead to duplicate charges and a wave of chargebacks.

2. Hold — Deposit Pre-authorization

At the start of the rental, the system performs a pre-authorization (hold). This is the primary gatekeeper: if funds are insufficient, the device will not unlock.

• Benchmarks: Scooters (~€5–10), Cars (€50–150).

3. Incremental Charging

A core feature of sharing services. If a rental lasts a long time, the backend triggers a chain of automatic partial charges. This requires complex retry logic to ensure the rental isn't interrupted by a momentary bank delay. Without this, the service essentially operates "on credit."

4. Capture — Final Settlement

Upon completion, the held funds are converted into a real payment, any excess deposit is released, and the system automatically generates a fiscal receipt.

Technology Stack

• Node A: Payment Provider.

  For example: Stripe, CloudPayments, or Yookassa. The choice of provider does not change the overall architecture—only the integration layer (API) changes. PCI DSS compliance remains entirely on the provider's side.

• Node B: Backend Middleware (Node.js / NestJS, Go, Python).

  The "brains" of the system. This is where event queues (Kafka/RabbitMQ), hold/capture management, and protection against race conditions live.

• Node C: IoT Level.

  The device communicates with the server via the MQTT protocol. It is resilient to poor network conditions and consumes minimal traffic.

  Scenario: Bank → Backend → MQTT → Device → Unlock.

Integration Approaches and Development Timelines

Infrastructure and Development Costs

Infrastructure (Unit Economics):

• IoT Module: $50–120 per device.

• Cloud Fiscalization: ~€30/month.

• M2M SIM: ~€2/month.

Development (Stage Estimates):

• Payment Provider Integration: $3k – $6k

• Hold / Capture Logic & Billing Engine: $4k – $8k

• Incremental Charging System: $4k – $7k

• IoT Control Integration: $6k – $12k

• Queues & Fault Tolerance (Kafka): $5k – $9k

A full production-grade launch typically takes 2 to 4 months of development.

Common Implementation Pitfalls

• Unlocking the device based on a single synchronous bank request.

• Lack of reconciliation (automated cross-referencing between bank data and your database).

• Lack of retry logic for incremental charges.

The Bottom Line

In the sharing economy, money becomes a control signal for physical hardware. If this circuit is designed correctly, the service scales without cash flow gaps, manual operations, or increased financial risks.

We design and launch resilient systems — dev48.org.