ALL unique constraints (that would include a primary key) involved in a partitioning scenario MUST have the partition column defined as part of the base index definition (subset of the index key) - (not merely an included column). In your example, you would not be able to partition the nonclustered primary key because orderdate is not part of the base index definition.
I don't think you will achieve your goal of
Add partitioning to table to make deletion of old orders non-blocking/quicker
by using partitioning due to the simple fact that the primary key cannot participate in the same partition scheme/function as the clustered index which you want to partition. Even if you partitioned the primary key on its own partition scheme/function by ID, these two indexes will not be aligned such that you could use partition switching to efficiently delete data with a minimum of logging.
In my opinion, you could create a nonclustered primary key and include the orderdate column which might help the engine find the rows you want to delete faster, but you'd still probably need to do batch deletes in chunks to limit the amount of locking involved.
I just don't think partitioning is the answer for your problem.