Right now you might be saying that we could have implemented what we have so far using a database table for temporary users, and that all we'd need is a cleanup batch job to clear out the users that never follow through. However, to do so would be to miss the great flexibility that sagas offer.
At their core, sagas are entities that contain multiple message handlers with shared state, but they also offer the ability to set a timeout, which is like setting an alarm clock to wake you up at some point in the future. This ensures that the process does not have to stop just because no new messages come in.
But better than just an anonymous alarm clock, we're also able to pass the state into the future, so not only will our saga wake up on command but it will also know why.
In our case, we want two timeouts. When the user first attempts to register, we want a wakeup call two days later, so that we can remind the user to complete the registration, just in case they get busy and forget...