Suitable schema to record email sent and response received and invoicing in DB
Assuming the system handles only a few actions per second and only millions of ids, either flavor of schema design should work well enough.

I can think of no strong argument for, or against, splitting the confirmations off into a separate table -- performance, sparseness (or lack of) in the Confirmations table, 1:1 relationship, coding convenience, purging, etc.

If you anticipate hundreds of actions per second or billions of ids, then you should sketch out more details, including INSERTs, UPDATEs, and SELECTs.  Plus consider a purging policy (which might include PARTITIONing by date).

You've had the foresight to think about the 'right' design -- Good.  Suggest you plan on significant redesign after maybe a year of use.  Build a layer between you application an MySQL.  Then focus on the application without fretting over the schema design.  With luck, the impact of the redesign will be mostly limited to the 'layer'.

For example, the layer would be asked to SendConfirmation(id); it would then either UPDATE (if one table) or INSERT (if 2 tables).