LeCoinDine
A production C2C marketplace spanning listings, messaging, card and wallet payments, carrier shipping, refunds and seller settlement. I built the backend transaction and integration workflows behind the mobile product.
Source code is private. The case study focuses on transaction flow, order-state consistency and carrier or payment integration behavior rather than internal commercial data.
- Product model
- Peer-to-peer marketplace
- Channels
- iOS · Android · web operations
- Timeline
- 2024
- My role
- Backend engineer
- Context
- Private commercial product
- Delivery scope
- Orders · payments · shipping · operations
01
Product surfaces
Product surfaces
Distinct product surfaces made school, association and campus responsibilities visible before getting into the backend architecture.
Marketplace discovery
Customer-facing discovery, listing selection and pre-checkout product state.
Order creation and checkout
Card or wallet purchase path converging toward one shared order lifecycle.
Merchant and order operations
Operational handling of order, shipping and settlement states after purchase.
02
Problem and constraints
Problem and constraints
A marketplace sale crosses systems owned by different parties: Firebase holds product and user state, Stripe moves money, carriers create and track shipments, and mobile clients need a coherent status. A partial update can expose a sold item, lose settlement context or misinform both users.
Customer and merchant views must stay consistent
A partial transaction update can expose a sold item or leave each side seeing a different order reality.
Two payment paths, one product contract
Saved-card and wallet-balance purchases must converge on identical order semantics.
Carrier behavior varies by provider
Relay lookup, address formats and shipment creation differ by carrier.
Operational recovery cannot depend on the client app
Unsynced delivery or settlement states need reconciliation outside user requests.
03
My exact ownership
My exact ownership
I designed
- The shared order lifecycle used by both saved-card and wallet-balance purchases.
- The separation between customer-facing order flow, merchant-side handling and service integrations.
- The service boundaries around payment, carriers, relay lookup and location resolution.
I implemented
- Backend routes and services for accounts, listings, orders, wallets, messaging and payments.
- Card and balance payment flows with Stripe Connect seller transfers.
- Shipping workflows over Mondial Relay, Relais Colis and address geocoding services.
I collaborated on
- Operational reporting, administration workflows and customer-status behavior across the mobile product.
- The alignment between marketplace UX and transaction-state constraints.
03
Objectives
Objectives
Order consistency
Keep buyer, seller, product, payment and shipping records aligned through the sale.
Payment convergence
Normalize card and wallet purchases into one transaction model and fee calculation.
Carrier abstraction
Expose one shipping workflow while retaining provider-specific adapters.
Operational recovery
Reconcile unconfirmed, unsent and undelivered orders outside user requests.
04
System architecture
System architecture
Flutter · web · buyer and seller flows
Flask · auth middleware · domain routes
Firebase · products · orders · wallets
Stripe Connect · carriers · maps · email
Customer apps, transactional backend state and carrier or payment services stay separated so order semantics do not leak into individual integrations.
Technology stack
API
Flask · Firebase Admin · Gunicorn · APScheduler
Commerce
Stripe Connect · Wallet ledger · Invoices · Refunds
Shipping
Mondial Relay · Relais Colis · Google Maps
Clients & operations
Flutter · Firebase Messaging · Email · Papertrail
05
State model
State model
The order lifecycle coordinates listing availability, money movement, shipment and seller settlement across two payment sources.
Listed
The product is visible and remains owned by the seller.
Checkout started
Buyer, carrier, relay point, fees and payment source are resolved.
Order confirmed
Payment succeeds, the order is recorded and the listing leaves the catalog.
Delivered
Delivery confirmation closes the buyer flow and enables settlement.
Alternate transitions
Payment failure
No confirmed order is created and the listing remains available.
Cancellation or report
Operational handling interrupts the standard delivery and settlement path.
The visible order lifecycle coordinates product availability, payment confirmation, shipment and seller settlement instead of treating them as unrelated events.
07
Engineering challenges
Engineering challenges
Coordinating a sale across systems
No transaction spans Stripe, Firebase collections, carrier APIs and notifications.
Use an explicit order lifecycle, deterministic transaction IDs, Firebase batches for catalog moves and scheduled reconciliation for incomplete states.
The workflow remains eventually consistent and requires operational repair paths, but every subsystem has a defined source state.
If each subsystem updates independently without a shared lifecycle, sold items reappear and support loses confidence in order truth.
Card and wallet parity
Payment sources have different settlement mechanics but should not create different product behavior.
Calculate amount, shipping and platform fees once, then converge both paths on shared transaction, shipment and catalog operations.
Provider-specific identifiers still need storage and refund branching.
If each payment path grows its own order behavior, refunds, settlement and user status drift apart.
Normalizing carrier constraints
Carriers accept different address formats and shipment parameters.
Normalize and truncate user data before dispatching to carrier-specific service adapters.
Some provider behavior stays conditional, but route handlers remain independent from carrier protocols.
If carrier protocols leak into route logic, shipping bugs multiply and order handling becomes hard to change safely.
08
Failure modes & mitigations
Failure modes & mitigations
Payment succeeds but order confirmation lags
Deterministic transaction IDs and shared order creation logic reduce the chance of money movement without a traceable order state.
Duplicate checkout submission
The order lifecycle and catalog move logic prevent one listing from being sold twice through repeated client actions.
Carrier or delivery dependency fails
Carrier integrations stay behind services so order handling can surface failure explicitly and recover operationally.
Order remains incomplete after the request ends
Scheduled reconciliation jobs close stale orders, refresh delivery states and restore operational visibility.
09
Technical decisions
Technical decisions
One order lifecycle
Product removal, payment state, shipping data, buyer and seller records and conversation status are updated as parts of the same purchase flow.
Two payment sources
Saved-card and wallet-balance purchases converge on the same order model, fee calculation and seller settlement path.
Shipping behind services
Carrier and geocoding integrations are kept outside route handlers so pickup-point lookup and shipment creation can change independently.
10
Security & operations
Security & operations
Revoked-token verification
Protected operations validate Firebase ID tokens with revocation checks.
Role boundary
Administrative routes add a cached admin-membership check after authentication.
Operational scheduling
A single scheduler process runs order reconciliation, delivery checks and maintenance jobs with dedicated logs.
Traceable failures
Request context and scheduler events provide enough transaction context for support investigation.
- Authentication middleware on account, order, payment and wallet operations.
- Request and error logging with transaction context for operational follow-up.
- A single scheduler instance enforced across production workers with a file lock.
11
Delivered system
Delivered system
Implementation outcomes — no unverified commercial metrics.
One order semantics
Card, wallet and multi-item purchases share transaction and delivery concepts.
Recoverable lifecycle
Scheduled jobs close stale orders and refresh delivery states outside the request path.
Provider isolation
Payment and carrier integrations can evolve behind service boundaries.
Operational visibility
Order, scheduler and request events support customer and transaction investigations.
What I learned
“In a peer-to-peer marketplace, payment and shipping are one operational lifecycle: each state change affects the buyer, seller, listing and platform balance.”