GMax Mart
Home Services Pricing Portfolio FAQ Reviews Blog Support Careers Change Language

Forms & Privacy

Preventing duplicate form submissions and double orders

· 7 min read

Preventing duplicate form submissions and double orders

A customer on a patchy 4G connection taps "Place order". Nothing visibly happens for four seconds, so they tap again. Your warehouse now has two orders for the same sofa, the customer has two payment messages from their bank, and somebody has to sort it out. Duplicate form submissions are one of those problems that never appear in a designer's mockup and show up constantly in real operations. This article explains why they happen, what each type costs, and how to find the ones already sitting in your data.

The companion article in this series covers the server-side defences. This one is about understanding the problem well enough to know which defences you actually need.

Why the same form gets submitted twice

The impatient double tap

The most common cause by far. The button gives no feedback, the page appears frozen, and tapping again feels like the obvious response. Touch screens make it worse: a slightly long press can register as two events, and users accustomed to unresponsive apps tap repeatedly by habit.

Refreshing after submission

If the result of a form post is rendered directly rather than redirecting to a new URL, pressing refresh or the back button re-sends the data. Browsers warn about this, but the warning is easy to dismiss and the wording means little to most people.

Network timeouts and retries

On a weak mobile connection, the request may reach your server and be processed while the response never makes it back. The customer sees an error, tries again, and creates a second record of something that already succeeded. Apps and some HTTP clients also retry automatically after a timeout, doubling the request without anyone touching anything.

Gateway callbacks and redirects

Payment flows are especially prone to this. The gateway may send a server-to-server notification and also redirect the browser back to your site, and if both paths create the order, you get two. Retried webhooks are normal behaviour, not a fault.

Honest re-submission

Sometimes a person really does fill the form twice, because they were not sure it went through, or because they wanted to correct a typo and submitting again seemed easier than calling.

The damage, by type of form

  • Online store checkout: two orders, double stock reservation, two delivery slots blocked, and possibly two charges. Refunds cost gateway fees and take days to reach the customer's account.
  • Enquiry forms: two team members call the same person about the same job, which looks disorganised, or a lead is worked twice and counted twice in your reporting.
  • Appointment booking: two slots consumed, so a customer who wanted one appointment blocks another person from booking.
  • Registrations and signups: duplicate accounts with the same email or phone, which breaks login, OTP flows and loyalty points.
  • Anything that sends a message: two SMS or WhatsApp messages, two emails, real money spent per send.
  • Reporting: inflated conversion counts, which make your advertising look better than it is and lead to bad spending decisions.

Beyond the direct cost, there is the trust damage. A customer who sees two debits from their account, even if one is only a hold that will drop off, will call you worried and may not shop again.

Why the customer usually blames you

It is tempting to file this under user error. From the customer's side, though, the sequence looks like this: they pressed a button, nothing happened, they pressed it again, and the business charged them twice. In a review, that becomes "they took double payment". Whether the second tap was reasonable is beside the point commercially.

There is also a fairness issue. Duplicates cluster among customers on slower connections and older phones, which in India often means exactly the customers you are trying to reach in smaller towns. A checkout that only behaves well on fast broadband quietly penalises them.

How to find duplicates already in your data

Before deciding how much to invest in prevention, measure. These checks take an hour with your developer or with an export into a spreadsheet.

  1. Group by customer and time. Look for two records with the same email or phone created within two minutes of each other. That window catches almost all accidental duplicates.
  2. Compare content hashes. Combine the important fields into one string and look for exact repeats on the same day.
  3. Check your refunds. Count how many refunds in the last six months were issued because of a repeated order; your accounts team usually remembers.
  4. Look at payment gateway records for two authorisations of the same amount to the same customer minutes apart.
  5. Check your messaging bill for repeated sends to one number.
  6. Ask the people who clean it up. Whoever handles your enquiry inbox will tell you in thirty seconds how often it happens.

Write the numbers down. If duplicates are two percent of orders on a store doing decent volume, the fix pays for itself quickly. If you get one a month on a contact form, a small change to the button is enough.

Reduce duplicates in the interface first

Interface changes will not make your system correct, but they remove the majority of accidental repeats and cost very little.

  • Respond to the click instantly. Change the label to "Processing…", show a spinner, and disable the button so a second tap does nothing.
  • Keep the button big enough and spaced, around 48 pixels tall, so a fumbled tap does not land twice.
  • Redirect after a successful post to a separate thank-you URL, so refresh reloads a harmless page.
  • Tell the user what a timeout means: "We did not get a response. Check your orders page before trying again" is better than a generic failure message.
  • Show the order or reference number prominently so the customer can confirm whether the first attempt worked.
  • Keep confirmation pages fast and light, since a slow success page feels like a failure.

Test all of this deliberately on a throttled connection. Chrome DevTools can simulate a slow network, and it is the quickest way to see what your customers on weak signal actually experience.

What to do next about duplicates

Start by counting what you have, then fix the button feedback and the post-redirect behaviour this week, since both are small changes. Treat those as damage reduction rather than a cure: the network will still time out, and gateways will still retry. The durable fix lives on the server, which is where the next article in this series goes. For stores where double orders and repeated charges are already costing money, our team can review the checkout flow end to end as part of online store development.

Frequently asked questions

Is disabling the submit button enough to prevent duplicates?

No. It stops the impatient double tap, which is the most common cause, but it does nothing about refreshes, network retries, gateway callbacks or anyone posting directly to your endpoint.

How do I tell an accidental duplicate from a genuine repeat order?

Time and content together. Identical details within a couple of minutes is almost always accidental; the same customer ordering the same item a week later is a real second order. When in doubt, hold the second one and call.

Do duplicate submissions affect my analytics?

Yes. They inflate conversion counts and can make campaigns look more profitable than they are. If duplicates are common, exclude them before reporting on advertising performance.

Should I automatically cancel the second order?

Safer to flag and hold it for review rather than cancel silently. Automatic cancellation occasionally removes a genuine order, and the customer never finds out until the delivery does not arrive.

Thinking about a website?

See what a package covers and what it costs, or ask us about your own project.

Read next

Thinking…