What the other payment modules do is look for the last order number, add one, and append a random suffix or timestamp, submitting the result with the payment request, but let ZC just do whatever it normally does when actually storing the final order. This accomplishes the desired goal with basically no changes to core functionality. It also prevents accidental duplicate numbers when submitting payments, even with busy sites and race-conditions, because the random number/string differentiates, and on the rare case where there is a clash, reconciliation activities are still very simple to handle when trying to match up numbers with orders (which is rarely a challenge).