Senior Developer/Agency: Custom E-commerce Platform Integration with Single-Bid Auction Logic

Project Amel

Technical Scope for Hybrid E-commerce & Static Bidding MVP

We require a highly skilled Senior Developer or specialized Agency to implement a Minimum Viable Product (MVP) for Project Amel, a web platform focused on time-boxed product events that incorporate complex conditional transactions and a unique, single-submission bidding component.

Mandatory Technical Strategy

This is a deep integration project, not a build-from-scratch effort.

The chosen developer must leverage and extensively customize a highly scalable, stable E-commerce or Marketplace platform (e.g., Sharetribe, WooCommerce, etc.) to house the custom logic defined below.

Expertise in platform-specific APIs and secure backend customization is non-negotiable.

• Architectural Foundation & Integrations

The architecture must support robust transactional integrity and seamless third-party services:

Platform

Proposal must confirm the base platform and justification for its suitability.

Authentication (SSO): Mandatory integration with at least two third-party Social Sign-On (SSO) providers (e.g., Google, Facebook). User login credentials must not be stored on our servers.

Payment Gateway

Full integration with a major third-party payment processor (e.g.

, Stripe, PayPal) for all transactional flows

Access Token purchase, bid submissions, and final winner payment processing.

Email Service

Integration with a transactional email provider (e.g., SendGrid/Postmark) for automated notifications and the delivery of the discount credit voucher.

• Core Modules (24-Hour Event Cycle)

The system revolves around two synchronized, 24-hour modules per event:

A. Product Event Page (PEP) — Transactional Component

Access Token Sales

The page must handle the sale of a fixed-price Access Token, which immediately triggers the issuance of a pre-defined Discount Credit to the user's account.

Real-Time Progress Indicator

A visible Loading Bar is required. The system must display the percentage calculated.

Admin Mandate (Cost Reduction): The Activation Threshold (Q) will be a static integer value manually input by the administrator during event setup.

The developer's task is limited to the reliable tracking of sales against this static Q value and ensuring accurate front-end display.

Timer Synchronization

A hard 24-hour countdown timer must govern the purchase eligibility.

B. Static Bidding Module (SBM) — Competition Component

Single-Bid Restriction

The SBM must strictly enforce a "one user, one bid" policy per event. Users can only submit a single monetary value (e.g., $X.XX) which cannot be modified or withdrawn.

Concurrency

The SBM runs parallel to the PEP and must respect the same 24-hour countdown.

Finalization

The system must pass all collected single bids to a secure backend script for winner determination only if the PEP's Progress Indicator reaches 100% within the 24 hours.

• Critical Backend Logic & Administrator Workflows (MVP Focus)

The following components represent the highest complexity and must be robust, auditable, and designed for manual administrator control to reduce development cost:

A. Winner Determination and Transparency

Processing Script

Upon event closure and verification of 100% activation, a confidential, server-side script must execute the final winner determination based on proprietary rules (to be provided under NDA).

Post-Event Display

The SBM must instantly display the winning User ID/Alias, the winning price, and a secure, auditable list of all submitted bids for that event.

B. Admin-Assisted Financial Reversal Queue (CRITICAL)

The most critical and high-risk component. Due to budget constraints, the system will not execute financial reversals autonomously.

It must instead manage an auditable queue for the administrator:

Queue Population

The backend must automatically identify and record all required refunds into a secure Refund Queue in the admin panel immediately upon event finalization.

This includes two distinct reversal types

Reversal 1

Access Token fee refund (conditional and non-use of discount credit).

Reversal 2

Conditional Bid amount refund

Admin Interface

The administrator must have a clear interface to review, approve, and manually initiate the execution of these queued reversals.

The interface must log the success/failure of each manual reversal.

C. Historical Data & Reporting

A public page is required to display finalized event data by date, including the winning price and a complete, unfiltered list of all bids submitted in that event.

• Required Deliverables Summary

Full deployment and integration of the core e-commerce platform.

Custom PEP and SBM Modules with synchronized 24-hour timers and the static-Q Progress Indicator.

A secure, auditable Admin Refund Queue and winner flagging system.

Professional, mobile-responsive UI/UX design included in the fixed price.

Working integrations for SSO and Payments.

Please detail your proposed base platform, estimated timeline, and a breakdown of how the custom module development and the critical Admin-Assisted Financial Reversal Queue will be delivered within the budget.

Contract duration of 1 to 3 months.

Mandatory skills

E-commerce Platform Integration (API), Custom Auction/Bidding Logic, Financial Logic Implementation, Payment Gateway Integration (Stripe/PayPal,bank), Third-Party Authentication (SSO/OAuth), PHP (or the dominant backend language of the platform you choose, e.g.

, ), Game UI/UX Design, Mobile-Responsive Design, Real-Time Data/WebSockets (For the synchronized timer and progress indicator), Database Design (SQL/NoSQL) (Essential for managing bids, transactions, and the refund queue)