[ic] Your favorite method for preventing duplicate orders

[Grant]

> > What is your favorite method for preventing users from placing
> > duplicate orders?  I suppose this could happen if the user refreshes
> > the order receipt page,
>
> One of the things I absolutely dislike is the fact that the form processor
> displays mv_nextpage to the client while the URL is left at process.html.
> Even worse, like you say, the browser knows it is a result of form
> submission and if you refresh the page, you perform the action again.
>
> One way, though probably not the most elegant, to solve this is to
> [bounce href='[cgi mv_nextpage]'] at the end of every action code.
> The bounced page would not be a result of form submission and you could
> refresh it any way you want. The URL would be correct too. And if you
> use cgi/value spaces the right way, [bounce] shouldn't create any problems.
>
> Another solution is, I remember a while ago (2005-onwards) Frederic
> Steinfels posted a patch (for Dispatch.pm IIRC?) that automatically
> solves this directly on IC level. I don't remember if he used
> $Tag->bounce or something else.
>
> > clicks back from the order receipt page and
> > submits the order again, or clicks the submit order button twice while
> > the order receipt page is loading.  Anybody using a non-Javascript
> > solution for this?
>
> I talked to Racke about this some time ago. Basically I had an idea to
> create a "form cache" on the server side. In short, it would cache
> form submissions and let you control (through new variable mv_repeat
> or mv_replay?) how often is a person able to submit the form. In
> general, there should be some control allowing you to specify:
>
>  - to which form names (or all forms) the specific restriction applies
>  - to which field names (or all fields) it applies
>  - when it applies (when the specified fields are the same, or different
>    from previous submission, or in any case)
>  - actual restriction: 1 = once per session, 2/10 = twice every 10
>    minutes
>
> If I could get some more comments on this I might go with
> implementing it. It would solve the "form-replay" problem on the
> right level.
>
> Btw, kind of related info, Authorize.net seems to have this sort of
> thing too. They do not process your payment again if it contains all
> the same data and is submitted (by default) within 2 minutes from
> the previous payment.
>
> -doc

What I've ended up doing here is checking for an empty cart at the
checkout page, emptying the cart and setting a scratch variable after
an order is placed, and if the empty cart message is triggered on the
checkout page while the scratch variable is set, a "your order has
already been placed and your cart is now empty" message appears.

- Grant