eCommerce: how to avoid double order submission

Level 122

first thing to try is disable any user input button as soon as they click it.

Or did I misunderstand the question?

Next step would be to make sure you are updating the status of the order in an atomic fashion

Level 1

@Snapey We don't controll/own the UI before the redirect to our confirmation page so your first suggestion (disable user input button) is not possible.

The other solution is exactly what I want to learn more about. Isn't that somewhat what I write about with a cache using atomic lock?

Level 122

@mikaeledstrom as part of this process, do you have to send an acknowledgement back?

Level 1

@Snapey No, not to the payment provider

Level 122

you could use redis, but unless you are careful, the problem will be the same.

thread #1. orderref in array? No.
thread #2. orderref in array? No.
thread #2. add order ref to array.
thread #1. add order ref to array

I'm sure you are aware of this already

You can use Laravel's atomic locks to prevent another thread creating a duplicate order, but in your code before you create an order you will need to check if the order already exists. If you put the lock around this initial step then this will prevent two threads doing it at the same moment. Put the minimum code inside the lock.

Cache::lock('addOrder')->get(function () {
    // Lock acquired indefinitely and automatically released...

    // Is there an order in existence
    // yes, exit
    // no? create order
});

// rest of your code

Level 1

@Snapey Cache::lock is what I am learning more about, thank you. a) would you use the block method to trigger an exception? b) the code inside the closure, would you use Cache (e.g. Redis) for the check if there is an order in existance or use database (e.g. MySQL)?

Level 122

@mikaeledstrom you should be able to use whatever you use to store the order

just check if there is already a db record with the same order id, and if there is, don't save and report it somehow

martinbean

Level 80

@mikaeledstrom Payment gateways will send some form of transaction ID or idempotency key to avoid exactly this.

Which payment gateway is this?

Level 1

@martinbean it is a local payment provider. They send a unique order ID, basically a transaction ID. That is how we can find these occurrences, by checking for payments with the same transaction ID. It would be much nicer to avoid it completely.

martinbean

Level 80

@mikaeledstrom So therefore I don’t see the problem? I mean, first off the column in the database should be unique to make it literally impossible for two rows to have the same transaction ID.

It’s also impossible for two requests—and SQL INSERT statements—to happen at the exact same nanosecond. A unique key on the column you store the transaction ID will prevent the second request.

To further ensure an order is processed only once and exactly once, you can push the order creation to a queue. Queued jobs will be executed sequentially, no matter what order or time they were added to the queue. One queue job will create the order. If another queue job thereafter then attempts to write an order with the same ID, then you’ll get an exception because of the unique key constraint violation.

I’d like to give you more concrete answer, but given we’ve not seen any code and your reluctance to name the payment gateway as if it were some national secret, I can’t consult any documentation and say for sure how the gateway should be used and duplicates prevented.