SQL Trigger to verify account, if not verified dont process stored procedure/transactions
No you cannot use Triggers for this because Triggers do not fire in response to Read-type events (Execute or Select).  Nor should you because, in general, triggers are not an appropriate device for implementing security.

If you want to implement your security token idea on SQL Server(*) there are several general ways to go about it:


Alter your Stored Procedures:  Add an additional parameter to your stored procedures, then have your stored procedures themselves check this.  This is the recommended method.
Wrap your Stored Procedures: If you do not want to alter all of your stored procedures, you could instead do as one of the commenters suggests and write wrappers for all of your stored procedures.  The wrapper has the token as an additional parameter, which it first checks and then calls the actual procedure.  You use SQL-object security to prevent the actual procedures from being executed by anything other than the wrapper procedures.  This approach is not usually recommended because of the extra work and its higher maintenance.  However, this can be alleviated through automation if your database's security, schema and procedure design is structured correctly for it (this is how I do it, though not for this purpose).
A variant of #2 (above) would be to have a single Wrapper Procedure that calls all of the other procedures.  This would require that the first two parameters were the token and the actual procedure name and the rest would be the actual parameters shifted over two places.  The Universal Wrapper would then check the token and if valid, then call the actual procedure.  This is actually surprisingly easy to do (and does not require dynamic SQL either), however, it does also require properly designed security schemas to enable closing other security holes.  This approach is not usually recommended because of it's even higher dependence on properly designed security and schema structures and because auditors do not generally understand it and it makes them nervous.


(* - and this may well be something that is better addressed at the web/app server level, since that seems to be where the weakness is.)