How to properly implement message driven architecture?

To begin with I lately revisited my old online shop project to review and refactor my code and I spotted a huge design flaw basically my TransactionCompletedEvent was doing things it shouldn't be doing in the first place, the event was doing those things:

1. Mark the checkout as paid
2. Create shipping record
3. Generate invoice
4. Send email to the user that the payment was processed by the server

It's clear that there are too many responsibilities and too many things that can go wrong along the way.
My idea was to instead of doing each of these tasks I could introduce eventual consistency and create a simple message que in the database with a worker working in the background hooked up to crontab(it would execute every 5 minutes or fire up the worker when there is a new message pushed to the que, the worker would create a lock file to be sure only 1 worker is processing the message que). It would make the project more flexible and bugs wouldn't interrupt the whole process.

The message would hold the following props:

• messageId(UUID)
• createdAt(DateTime)
• messageClass(string representation of the class path to recreate the message)
• payload(serialized message)
• status(Enum - DISPATCHED, ERROR, PROCESSED)
• errorMessage(string/stringified exception)

Is this approach message driven architecture compliant or am I kinda reinventing the wheel?

DISCLAIMER I am aware of amazon's SQS, rabbit MQ and other message queues but I want to simplify the setup for testing purposes