1. Eligibility & Registration

• All bidders must register click on the view and participate at eTender notifications page. and verify their email via OTP before applying or booking slots.
• Payment verification is required. Payment statuses are tracked per bidder-per-tender.

2. Slot Booking & Attendance

• Bidders must book a slot for a tender via the slot booking page. Each booking stores slot start and slot end timestamps (IST).
• Only bidders with a booked and confirmed slot can access bidding page. If a slot exists but is not booked for your email, you will see: "You have not booked a slot for this tender."
• Slots can be limited by max_bidders. The system auto-assigns a group code for each booking.

3. Bidding Window

• Bids are accepted only during your slot time: between slot start_time and slot end_time — server time is IST.

4. Reverse Auction — Bid Format & Limits

Important numeric rules (project-configurable):

• Min Cost and Max Cost define the permissible bidding range. All bids should remain within these limits to ensure fairness and consistency.
  Example: ₹362,500 — ₹657,000
• Minimum Bid Difference (min_bid_difference) and Maximum Bid Difference (max_bid_difference) determine the allowed gap between the current lowest bid and a new bid.
  For instance: Minimum ₹500, Maximum ₹5000.
• The first bid may go up to the max_cost limit (as per your rules). Thereafter, each new bid should be strictly lower than the current lowest bid.

Behaviour summary:

• Bidders must obey min/max and min/max difference rules.

6. Real-time Updates & Refresh

• Client pages poll the server (e.g. every 5 seconds) to fetch current lowest bid and the bidder. This provides near-real-time view of the auction state.
• Only the server-side stored bids are authoritative — client polling does not permit offline/temporary bids.

7. Bid Storage & Result Finalization

• All bids insert into the `bidding` records with bidder info and timestamp.
• After slot end the system (cron job) performs auto-finalization:
  1. Find lowest bid per tender + groupcode.
  2. Send email notification(s) to winner (and optionally admin) — configured to send only once per result.
  3. Admin reviews results and approve with action buttons; final status toggles to be verified and awarded once accepted.

8. Email Notifications & Cron

• Emails are sent using PHPMailer via SMTP , e.g. from support@gulbabafoundation.online.
• Cron jobs (server scheduled) run PHP scripts after bidding deadlines to finalize results and trigger email alerts.
• Emails for a finalized result are sent once.

9. Disputes, Cancellation & Penalties

• Any disputes must be emailed to the admin within 48 hours of result finalization.
• Bidders found to be manipulating bids may be disqualified and blocked by admin.
• Cancellation of bids is not permitted once submitted; admin may cancel results in exceptional cases.

10. Security & Audit

• All important actions (slot booking, bid submission, finalization) are timestamped and logged.
• Admin actions (verify payment, mark winner) should be done from the secure admin panel.