How Seacom Soft Limited designs GCB Marketplace to remain reliable when payments, webhooks, messages, and background jobs are repeated
Most people never hear the word idempotency, yet we depend on it whenever we tap Pay twice, refresh a frozen checkout page, or receive the same WhatsApp message more than once.
The concept is simple: repeating the same action should not change the result.
Pressing a lift button twice should not summon two lifts. If a bank receives the same payment instruction twice, you should not be charged twice. Software responsible for payments, vehicles, reports, and collections must behave the same way.
At Seacom Soft Limited, idempotency is more than a textbook concept. It is one of the principles that helps Guaranteed Car Buyers and the GCB Marketplace remain reliable when networks, customers, and connected services repeat themselves.
Consider a Simple Car Purchase
Imagine buying a used car online. You tap Pay, but the screen freezes. Unsure whether the payment worked, you tap it again.
You still expect:
- One charge
- One confirmation
- One invoice
- One vehicle sale
- One collection
You do not expect two transporters to arrive, two invoices to be issued, or the seller to be told that the same car has sold twice.
That is idempotency in practice.
The first valid request completes the work. Any identical request that follows should be recognised as the same event and answered with: This has already been completed.
This does not mean ignoring every subsequent request. A genuinely new payment, WhatsApp message, or collection slot still matters.
The challenge is distinguishing a duplicate receipt from a genuinely new event.
Why Duplicate Events Happen
GCB is not a single screen operating in isolation.
A private seller can accept a Guaranteed Price or choose Guaranteed or More, placing the vehicle in front of verified trade buyers. Following a successful sale, several actions may need to happen.
Payment must be confirmed. The vehicle must be marked as sold. A provenance report may need to be generated. The seller may need to select a collection slot. A transport partner may need to collect the vehicle. Buyers, sellers, and staff may need to receive notifications.
These activities involve different systems, including payment providers, calendars, messaging platforms, vehicle-history suppliers, and transport partners.
Any of these systems may deliver the same event more than once.
This can happen because the sender did not receive a response quickly enough and retried. A customer may double-tap a button or refresh the success page. The same checkout may be opened in multiple tabs. Stripe, Calendly, or WhatsApp may redeliver a webhook. Several people may request information about the same registration simultaneously. A scheduled job may also run more than once.
These situations are normal in distributed software systems.
The real problem begins when every repeated message is treated as a completely new event.
Without protection, one vehicle payment could result in duplicate collections, invoices, emails, referral rewards, history reports, or staff alerts.
That is more than a minor technical inconvenience. It can cost money, damage customer trust, and send a transporter to the wrong place.
A Paid Car Must Become Sold Only Once
When a marketplace payment succeeds, Stripe may send the confirmation more than once.
GCB’s payment process is designed so that completing the same sale repeatedly remains safe. The vehicle is marked as sold, and the payment is recorded as paid.
Actions that must occur only after the first successful confirmation, such as issuing referral rewards, recording checkout analytics, or notifying relevant parties, are performed once.
If the event is delivered again, the platform recognises that the sale has already been completed.
The duplicate event must not:
- Sell the same car again.
- Unlock buyer information twice.
- Reward a referrer twice.
- Produce duplicate analytics.
- Send another confirmation unnecessarily.
The same principle applies when a customer purchases a full vehicle provenance check.
A repeated payment succeeded event must not generate another report, send another email, or issue additional bundle credits. If the order is already complete, the system simply confirms its existing status.
One Payment Must Not Book Two Transporters
GCB operates a managed vehicle-collection process.
Collection planning begins only when buyer funds reach an approved, cleared state. Even then, a transporter is not dispatched immediately. The seller must first select an appropriate pickup slot.
Once the slot is confirmed, the collection request can be submitted to the transport partner using a unique booking key associated with the payment.
If the checkout process, payment webhook, calendar event, or retry all attempt to create the same collection, they present the same booking key.
One payment. One collection booking. One transporter.
If a slot has already been submitted, another copy of the calendar event is treated as already processed rather than as a new transport request.
Calendly may also retry a webhook when it does not receive a clear acknowledgement. The application must therefore acknowledge events appropriately, even when a booking belongs to another environment or there is no local record to update.
This prevents unnecessary retries without interfering with genuinely new bookings.
WhatsApp Must Not Answer the Same Message Twice
Trade buyers can receive listing alerts and submit vehicle photos through WhatsApp.
Messaging platforms may redeliver events when acknowledgements are delayed. If an identical event or photo arrives again within a defined period, it should be recognised and skipped.
Without duplicate protection:
- A buyer could receive the same automated reply twice.
- A photo could be imported more than once.
- A contact could be tagged repeatedly.
- The same conversation could trigger duplicate workflows.
Rapid groups of photo uploads can also be processed together, allowing the gallery to be organised once instead of being reordered separately after every image.
The customer experiences one clean conversation, even if the messaging provider repeats an event behind the scenes.
Expensive Lookups Should Happen Once
Vehicle-history information is not free.
If several people open the same vehicle registration at approximately the same time, the platform should not pay for the same external lookup repeatedly.
Provenance requests can be treated as unique per registration for a specified period. The first request retrieves the information, while matching requests reuse the result.
In this case, idempotency maintains data consistency while also controlling unnecessary operational costs.
Paperwork and Alerts Must Not Multiply
Duplicate protection also applies to background processes.
A winning buyer should receive one opening invoice, not several copies because a scheduled job ran twice.
Similarly:
- Staff should not receive duplicate emails for the same captured contact.
- Auction-ending reminders should be sent once within each notification window.
- Low-credit alerts should not be posted repeatedly.
- Mail-failover warnings should not flood operational channels.
- Repeated calendar-signature failures should be grouped appropriately.
The first alert communicates the problem.
Repeating it continuously only creates noise and makes important information easier to miss.
What the Customer Experiences
Ideally, nothing unusual.
The customer pays once and receives one confirmation. One collection is arranged. One report arrives in their inbox. One message thread is maintained.
If the page is refreshed, a button is tapped again, or the network briefly fails, the final result remains unchanged:
One sale. One booking. One report. One reliable experience.
That is the real purpose of idempotency.
It is not simply a clever engineering technique. It is the difference between a marketplace that remains dependable during retries and one that quietly duplicates payments, transport bookings, paperwork, and notifications.
At Seacom Soft Limited, duplicate events are treated as an expected part of modern software, not as an unusual exception.
The platform is designed so that “We have already completed this action” is a valid and intentional response.
In a distributed system, retries are inevitable. Networks fail. Webhooks are delivered again. Users click twice. Background jobs run again.
The engineering challenge is not to pretend those things will never happen.
It is to make sure that when they do, the business does not accidentally happen twice.
