When “Created” Orders Become a Headache in E-commerce

Last week I worked on a request from one of our clients for their e-commerce site. Let me walk you through it step by step, because it’s an interesting case and maybe you’d have solved it differently.

The client asked us to list orders with status “CREATED” in the customer’s Order History. Normally, the Order History only shows completed or failed orders. So why show “CREATED” ones?

Here’s the reason:
When a customer checks out in this supermarket e-commerce, they don’t just buy one or two products. They often fill their basket with 20, 30, even 40 items. Weekly or monthly shopping. If something goes wrong during payment, the basket is already transformed into an order in “CREATED” status, and the cart disappears. Customers then complain that they have to repeat the entire shopping list from scratch. And let’s be honest, that’s a pain.

To fix this, we added a “Repeat Basket” button for these “CREATED” orders. If the order failed, the customer can simply click and rebuild their cart without starting all over again. Sounds good, right? But here’s where things get tricky.

The different scenarios

1. The Happy Path
   The user checks out, goes to the bank page, confirms with their PIN or mobile app, and everything works perfectly. The bank sends confirmation back, the order is updated, and it moves from “CREATED” to authorized. No problem here.

2. The Distracted User
   The user tries to pay but doesn’t have their phone, enters wrong details, or lets the session expire. They come back to the site and the order moves from “CREATED” to “FAILED.” Again, no problem — it’s clear the order didn’t go through.

3. The Painful Scenario
   This is the one that keeps us up at night. The user closes the bank page before returning to the e-commerce site. Maybe they entered the correct authorization codes, maybe not.
   So now we have an order in “CREATED” status, and we don’t know if it’s actually paid or not.

How we handle it technically

To deal with this, we rely on two things:

• Webhooks from the bank
  Our payment gateway sends notifications whenever an order changes status. If a payment is authorized, pending fraud checks, or rejected, the e-commerce site gets notified and updates the order accordingly. If the payment is rejected, we cancel the order right away.

• A scheduled job
  Every 30 or 60 minutes, a job runs through all orders stuck in “CREATED” and asks the bank directly: Has this order been paid or not?
  If the bank says it’s authorized, we update the status, notify the customer, send the confirmation email, and start preparing the order. If the bank says it’s still pending, we wait until the next run. And if the bank says it failed, we cancel it.

The risk we face

So far, everything makes sense. Customers get the chance to repeat their basket if something went wrong, which saves them from rebuilding a long shopping list.

But here’s the problem: what if the user repeats the basket while their first payment was actually successful, just not yet confirmed on our side?

Imagine this:

• The user pays, but closes the browser before returning to the site.

• Our system still sees the order as “CREATED.”

• The customer, in a hurry, uses the “Repeat Basket” button and successfully pays again.

Now we’ve got two identical orders and potentially two charges on the customer’s card.

That’s the situation we’re facing.