Cameroon GCE A Level ICT study materials
Cameroon GCE A Level ICT study resources

Online Booking and Mobile Money for a Hotel in Kribi

Cameroon GCE A Level ICT · Put your knowledge to work in context.

All case studies

Online Booking and Mobile Money for a Hotel in Kribi

Riverside Lodge is a 28-room hotel in Kribi. Bookings are taken by phone and email; receptionists write them in a paper diary, and the same room has been double-booked three times this high season. Most guests are Cameroonians booking from Douala or Yaoundé on smartphones over 3G, but about one fifth are diaspora and foreign tourists who expect to pay online. The lodge has a domain name and a four-page static website built by the owner's nephew. The owner wants online booking with MTN Mobile Money, Orange Money and Visa, plus automatic email/SMS confirmation. The nephew can maintain a WordPress site but has no experience of payment security. The lodge's office has a 4 Mbps ADSL line and a backup generator. The budget is 1,800,000 FCFA for development and 250,000 FCFA per year for hosting and services. The owner has heard that storing card numbers on the hotel's own server is risky. Advise the owner.

1. Recommend the type of website and hosting for the lodge, comparing a static site, a self-hosted dynamic site and a managed booking platform. Consider the budget, maintenance skills, mobile users and reliability.

Read the worked answer

Static site: cheap and hard to break, but it cannot check availability or take bookings; every booking still passes through reception. It does not solve double bookings.

Self-hosted dynamic site (for example WordPress with a booking plugin): flexible and within the nephew's skills to update content, but he must apply security updates, manage backups and secure payments. On shared hosting, a neglected plugin is a common route to data theft. Development cost fits the 1.8 million FCFA budget; hosting may fit 250,000 FCFA a year, but the nephew's time is an unfunded risk.

Managed booking platform: monthly fee or commission, but availability, payment and confirmations are handled; less maintenance and stronger payment security. For 28 rooms, commission may be acceptable during high season.

Recommendation: a managed booking engine embedded in or linked from the existing site, or a WordPress site on reputable managed hosting with a maintained booking plugin. Use HTTPS, daily backups and a support contract. Why: the lodge's core need is reliable availability and payment, not web design; the nephew cannot be the only security administrator. Keep static information pages and link them to the booking engine.

2. Explain how online payments should be implemented so that the lodge accepts Mobile Money and Visa without taking on unnecessary card-data risk. Include the booking-record design needed to prevent double bookings.

Read the worked answer

Payments: do not collect card numbers on the lodge's server. Use a hosted checkout or redirect to a PCI-compliant payment gateway for Visa, and the MTN/Orange Mobile Money APIs or an aggregator for mobile money. The guest is redirected or receives a prompt; the lodge receives a token or transaction reference, not the card number. This reduces PCI DSS scope and the risk of a breach. Use HTTPS everywhere, 3-D Secure where available, and verify payment through a server-to-server callback rather than trusting the browser.

Booking records: tables for Room, RoomType, Booking and BookingNight (or a RoomAvailability table with one row per room per date). Prevent double bookings with a database transaction that checks and inserts availability in one atomic step, or a unique constraint on (RoomID, StayDate). Hold the room for a short period while payment is pending; confirm only on verified payment; release expired holds. Show only available rooms. Send an email or SMS with a unique reference and keep an audit log.

Judgement: a unique constraint plus a transaction is more reliable than checking availability in a web page and hoping two guests do not click at once.

3. Describe how the site should be designed for guests on slow 3G connections and how bookings should be confirmed and secured.

Read the worked answer

Slow 3G design: responsive layout, one column on phones; compress images and use lazy loading below the fold; avoid autoplay video and heavy sliders; minify CSS and JavaScript; use browser caching and a CDN if affordable; limit third-party scripts; make the booking form short and show progress. Provide a phone number and WhatsApp fallback for guests who cannot complete the form.

Confirmation and security: instant email and SMS with booking reference, dates, room type and payment status; a page where the guest can view or cancel with a one-time code. Admin accounts with strong passwords and multi-factor authentication; role-based access for reception; daily offsite backups; keep the content management system and plugins patched; monitor failed logins; publish a privacy notice explaining how guest data is used. Test the booking flow on a real 3G phone before launch.

Judgement: performance is a security issue here - if the form times out, guests phone reception and the double-booking problem returns.