Imranet

Designing and Delivering a Tokenized Digital Auction MVP with Reliable Real-Time Bidding for Imranet

Ecommerce SystemsProduct EngineeringSystem Integration

Executive Summary

Imranet operates a daily auction model for brand-new products in original packaging, positioned at prices below merchandise value, and differentiated by a voucher-based refund (50%). In this context, process credibility—clear rules, correct bid ordering, and consistent outcomes—is a core operational requirement, not just a UI concern.

Kulkul Technology delivered an MVP web-based auction platform to replace fragmented/manual auction coordination with a centralized system managing auction items, bidder registration, bidding flows, and transaction monitoring in one environment. The MVP included a landing page, domain and hosting setup, an admin panel, and both auction and product modules.

A CEO-level requirement was a smooth sell–bid–buy cycle—specifically a ticket/token model for bidding and integrated payment support. Kulkul integrated Xendit so users can purchase bidding tokens, and added OTP integration to support access control and user verification during onboarding.

A technically decisive aspect for real-time auctions is handling near-simultaneous bids (race conditions). In auction systems, concurrency must be handled at the transactional level to preserve bid ordering, token balances, and winner determination in an auditable way—because inconsistencies are externally visible and directly undermine trust.

Business Context

Imranet operates in a “trust-sensitive” domain: auctions are competitive, time-bound, and outcomes must be defensible. Kulkul’s case study frames the objective as more than putting listings online—building an operational backbone that supports real-time dynamics while preserving administrative control and data integrity. This aligns with what typically drives adoption in digital auctions: transparency and process discipline matter as much as experience.

The primary business driver (per Kulkul’s published case study) was replacing manual/fragmented auction coordination with a centralized system capable of managing bidder participation, item listings, and transaction workflows in a more transparent and scalable way. In practice, this kind of consolidation usually reduces operational friction (manual reconciliation, status syncing, miscommunication), although the case study does not publish quantitative KPIs.

In Indonesia’s context, local payment acceptance is a real constraint: digital retail payments and payment infrastructure remain a policy focus (Bank Indonesia’s Payment System Blueprint 2025). Implementation-wise, Xendit (the gateway used in this project) supports “Money In” methods such as Virtual Accounts/bank transfers, credit cards, and e-wallets, and provides channel activation processes tied to account verification—sometimes requiring additional documentation; credit card availability may also depend on risk assessment. Operationally, “payments enabled” is not just API integration—it depends on business readiness and channel activation/compliance steps.

From a governance standpoint, an auction platform processes personal data (accounts, contact/verification via OTP) and transaction data. In Indonesia, the core legal framework for personal data protection is Law No. 27 of 2022 (Personal Data Protection). Electronic system and electronic transaction operations sit within Indonesia’s regulatory context (e.g., Government Regulation No. 71/2019 and the amended ITE Law). The public case study does not specify compliance design, so this is treated as an operational consideration (unspecified in published deliverables).

The Challenge

Structuring the Full Sell–Bid–Buy Cycle

Auctions are time-bound, state-driven processes. Digitization required precise state definitions and transitions to ensure consistent and conflict-free execution.

Preserving Bid Integrity Under Concurrency

When multiple users bid simultaneously, the system must manage race conditions accurately to ensure consistent and fair auction outcomes.

Overall, the project required an MVP that is “operable” (not a click-through prototype), because the CEO defined completion criteria: scheduled auctions, ticket/token purchase to participate in bidding, and a smooth sell–bid–buy flow enabled by integrated payments (examples: cards, bank transfer, and e-wallets such as GoPay, ShopeePay, Dana, OVO). At the same time, the platform had to remain clear for bidders while giving administrators operational control.

The core trade-off was speed-to-market (MVP) without sacrificing transactional integrity and trust under real-time contention. The highest-risk areas are (a) auction state and winner determination (race-condition-prone) and (b) token crediting based on payment status (duplication risk if callbacks are not idempotent). Transaction systems literature emphasizes atomicity and isolation to ensure correct and failure-resistant state transformations.

Our Approach

Kulkul decomposed requirements into operable core capabilities: a landing page and production environment (domain/hosting), an admin panel, product and auction modules, Xendit payment integration for token purchases, and OTP integration. This is a pragmatic MVP approach because it (1) establishes operational foundations (admin + workflow), (2) treats token-based participation as a core workflow rather than an add-on, and (3) reduces abuse and improves process control via OTP verification.

For race conditions, the public case study does not disclose the exact technique used, but simultaneous bids are typically handled via standard concurrency control strategies. Academic foundations distinguish locking (pessimistic) from non-locking “optimistic methods.” On Ruby on Rails, ActiveRecord supports optimistic locking (via lock_version) and pessimistic locking (row-level locking via SELECT … FOR UPDATE).

The Solution

Kulkul’s published deliverable is a “fully functional” web application for the auction service, including a landing page and a payment system. Concretely, Kulkul built the MVP landing page, set up the domain and hosting, and delivered an admin panel plus auction and product modules.

To support the token/ticket-based bidding model, the website was integrated with Xendit so users can purchase tokens for bidding. From a payment operations standpoint, Xendit supports multiple “Money In” methods (e.g., Virtual Accounts/bank transfers, cards, and e-wallets) and provides channel activation flows tied to account verification and potential additional compliance steps; credit card availability may depend on risk assessment. For e-wallets, payment flows can be redirect-based or non-redirect/push depending on the partner (e.g., OVO vs DANA), which means the application should credit tokens only after receiving definitive callbacks/status.

OTP integration was added to support user verification and access control (the provider is not specified in the case study). In Indonesia’s context, handling OTP and account data should align with the PDP legal framework. (Specific compliance implementation is not described—unspecified.)

On bid integrity under race conditions, the public case study does not disclose the exact approach. However, “two users bidding at nearly the same time” is typically addressed through atomic transactions plus concurrency control (e.g., row-level locks or optimistic version checks). In Rails, row-level locking via SELECT … FOR UPDATE is available through ActiveRecord pessimistic locking. From a systems standpoint, the key is deterministic bid decisions (accepted/rejected) with a clear audit trail (who, when, which auction, and token status) to support monitoring and dispute resolution.

Results & Impact

Unified System

Centralized Auction Operations

All auction activities are managed within a unified system, reducing fragmentation and improving data transparency.

Trustworthy Execution

Preserved Bid Integrity

The platform reliably handles simultaneous bidding, protecting auction credibility.

Operational Readiness

Production-Ready with Payment Integration

The platform was deployed with domain, hosting, and integrated payment and verification systems, enabling real operations.

System Integrity Is the Foundation of Transactional Platforms

“The Imranet project illustrates a recurring pattern in transactional platforms: business value comes from process discipline. Auctions require deterministic decisions under concurrency because “who won” cannot be ambiguous. The transaction concept (atomicity, consistency, durability) is foundational for ensuring auction state transitions are correct and failure-resilient.”