Yes even if you just want to change the seed number you would still have to implement that interface and register it. I think Patrik showed good samples, but in your case you probably just need the simplest one.

Cool, just checking I was on the right track. Here's what I wrote in the end (in case it helps anyone):

[ServiceConfiguration(typeof(IOrderNumberGenerator))]
public class CustomOrderNumberGenerator : IOrderNumberGenerator
{
    private readonly int BaseOrderNumberSeed = GetBaseOrderNumberSeedFromConfig();

    private static int GetBaseOrderNumberSeedFromConfig()
    {
        var configValue = ConfigurationManager.AppSettings["BaseOrderNumberSeed"];

        if (string.IsNullOrEmpty(configValue) || !int.TryParse(configValue, out int baseOrderNumberSeed) || baseOrderNumberSeed < 0)
        {
            return 1000000;
        }

        return baseOrderNumberSeed;
    }

    /// <summary>
    /// This custom implementation will take the internal OrderGroupId and pad it with
    /// a random number of two digits (between 10 - 99) on the end. These are then added
    /// onto a base number (to avoid overlap with legacy system order refs).
    /// Typically this will be a base number of 1,000,000 - so, for example, and order
    /// with OrderGroupId 123 will get an OrderNumber like 1012353 (where the random padding
    /// is 53).
    /// </summary>
    /// <param name="orderGroup"></param>
    /// <returns></returns>
    public string GenerateOrderNumber(IOrderGroup orderGroup)
    {
        var internalOrderId = orderGroup.OrderLink.OrderGroupId;

        var randomNum = (new Random()).Next(10, 99);

        var orderIdWithRandomNumPadding = internalOrderId * 100 + randomNum;

        var orderNumber = BaseOrderNumberSeed + orderIdWithRandomNumPadding;

        return orderNumber.ToString();
    }
}

Note the summary comment for what I am trying to achieve :)

Looks good, but remember that the default implementation is also registered by ServiceConfiguration. To make sure yours is used instead of the default one, you should register yours in an initialization module that depends on Commerce InitializationModule. Wrote about this in details in my 2nd book :)

Are you meaning that because I'm using the [ServiceConfiguration] attribute that mine might happen to early? So I should move this to an initialization module dependant on Commerce to ensure my registration happens after?

So far testing my code works, but perhaps there's a race condition risk here?

Yes. It is working by pure luck.

Thanks for the pointer, have changed this (and a few others) to configure in the initialization module after Commerce. We never had any issues mind you, but better safe than sorry :)