eBangladesh

Overview

eBangladesh's hardest engineering problem wasn't the shopping flow — it was payments. Four Bangladeshi gateways (bKash, Nagad, uPay, aamarPay), four incompatible integration patterns, four different failure vocabularies, and a checkout screen that couldn't be allowed to know or care which one a customer picked. On top of that: a large share of the target userbase is on mid-range Android devices with inconsistent connectivity, so the app also had to stay usable — browsing, cart, checkout warnings — when the network wasn't.

I built the Flutter mobile app at Codeboxr, designing the payment abstraction layer, the offline-tolerant cart, and the connectivity-aware UX that made the app usable across the country, not just in areas with reliable signal.

The Problem

E-commerce penetration in Bangladesh outside of Dhaka required a different approach than traditional marketplaces. Customers in semi-urban and rural areas needed local coordinators they could trust, local payment methods they already used (bKash, Nagad), and an app that worked reliably on mid-range devices with variable connectivity.

eBangladesh's model of having a physical coordinator in every square mile needed a mobile app that made both browsing and buying frictionless for users across the country.

My Role

I built the Flutter mobile app at Codeboxr — responsible for architecture, implementation, and delivery:

• Designed a payment gateway abstraction layer — unified bKash, Nagad, uPay, and aamarPay behind a common PaymentGateway interface with a single pay(amount, orderId) contract. Each gateway's WebView redirects, token management, and error normalization are sealed behind that interface; the checkout screen never touches a gateway directly.
• Chose Provider over Bloc or Riverpod — the app's state graph is relatively flat (cart, auth, connectivity), and the team context at Codeboxr favored Provider's simplicity. The tradeoff was accepted: less compile-time safety for faster onboarding and fewer boilerplate files across 15+ screens.
• Implemented a local-first cart backed by shared_preferences — users can browse, add to cart, and manage wishlists entirely offline. Cart state persists across sessions without requiring authentication, reducing checkout friction for first-time users.
• Built connectivity-aware UX using connectivity_plus — on network loss the app degrades gracefully: cached product data remains browsable, cart operations work offline, and the user is warned before attempting payment without a connection.
• Optimized for mid-range Android devices (2GB RAM, Android 8+) — profiled on real devices throughout development. Used ListView.builder everywhere, kept widget trees shallow, deferred non-critical initialization with addPostFrameCallback, and standardized image loading via cached_network_image with fixed dimensions and shimmer placeholders.

Technical Decisions

Payment Gateway Abstraction

Four gateways, four integration patterns — bKash and Nagad use WebView redirects, uPay uses a custom SDK, aamarPay provides a direct card form. Each returns different response objects and error codes. Rather than branching on gateway type throughout the checkout flow, I defined a common contract:

abstract class PaymentGateway {
  Future<PaymentResult> pay(double amount, String orderId);
}

Each gateway implementation encapsulates its own redirect flow, token lifecycle, and error normalization behind that single method. The checkout screen depends only on the interface — adding a fifth gateway means writing one new class, touching zero checkout code.

Local-First Cart Without an Account

E-commerce apps typically require login before adding to cart. I chose shared_preferences (not SQLite) for the cart and wishlist because the data is small (a list of product IDs + quantities), session-scoped, and doesn't need querying. This lets users build a cart before committing to sign-up — a deliberate product decision to reduce abandonment in a market where users are cautious about sharing credentials.

Connectivity-Aware Architecture

Rather than wrapping every network call in try-catch, connectivity_plus feeds a singleton stream into Provider. Screens subscribe to connectivity state and adjust their UI accordingly: product grids remain fully browsable from cache, the checkout button shows a warning banner when offline, and the cart badge continues to update. This decouples connectivity logic from business logic — no screen needs to know how connectivity is detected.

Technical Stack

Challenges & Solutions

Challenge: Four different payment gateways, each with a distinct integration pattern, error code vocabulary, and sandbox behaviour. Keeping the checkout flow consistent regardless of which gateway the user chose was complex.

Solution: Built a payment gateway abstraction layer — a common PaymentGateway interface with a pay(amount, orderId) method. Each gateway implementation handles its own redirect flow, token management, and error normalisation behind that interface. The checkout screen only knows about the interface, not the gateways.

Challenge: Product images from vendor systems were inconsistent in size and quality, causing layout jank as images loaded.

Solution: Standardised image dimensions via cached_network_image with fixed width and height constraints and a shimmer placeholder. Images are loaded lazily via ListView.builder so only visible items trigger network requests.

Challenge: App needed to work on budget Android devices (2GB RAM, older Android versions) that are common outside Dhaka.

Solution: Profiled on a real mid-range device throughout development. Used ListView.builder everywhere, kept widget trees shallow, and deferred initialisation of non-critical services using addPostFrameCallback.

Outcome

• A single PaymentGateway interface absorbed all four gateways' quirks — adding a fifth would mean one new class and zero changes to checkout code
• Local-first cart and connectivity-aware UX kept the app fully browsable and largely usable through the connectivity gaps common outside Dhaka
• Rendering and initialization work tuned specifically for 2GB-RAM, Android 8+ devices, profiled on real hardware rather than emulators
• Post-launch monitoring drove targeted fixes that meaningfully reduced the crash rate
• Live on Google Play, with the platform at ebangladesh.com