It's difficult to give you a detailed answer as a lot will depend on the actual code you use to implement this process. The first and arguably most important thing to consider is input AND output validation on the data supplied by the user. There are plenty of good resources out there about that, http://www.owasp.org/ springs immediately to mind as the "go to" for that.
In terms of your actual approach, I would suggest that rather than having ScriptA.php POST to ScriptA-verify.php you should POST to ScriptA.php and handle the verification in there. By all means accomplish this by performing an "include" of ScriptA-verify.php but what this means is that you do not have the added complexity and consequently risk, of posting data back to ScriptA.php if ScriptA-verify.php returns a problem. The original form data will be available to you from your sanitised variables derived from $_POST (do not use $_POST directly, see above wrt validation).
The $_SESSION superglobal is "pretty secure" but there's a decent post here which you can find out a bit more from: Altering a $_SESSION variable in PHP via XSS?. There are others on Security StackExchange too.
I don't get a warm, fuzzy feeling that your check of $_SESSION['userid'] is going to be particularly bombproof though a lot of that will depend on knowing other specifics of the process you are developing. For example, ability to session hijack if session is conducted over HTTP not HTTPS, PHP configuration settings on your server, etc.
Another question I would ask is what checks are in the other pages that this login will protect otherwise you are potentially vulnerable to such things as Insecure Direct Object Reference. In short, don't assume that people will always come through landing.php to get to "secured-page1.php". If there's nothing in secured-page1.php to ensure a valid session all your efforts are in vain.
I also don't see anything which is going to protect your users from CSRF attack. Again it depends what the application actually does but if the only check before loading a page is for a valid session then it would be trivial to force a user's browser to request specific pages such as password resets or such like. Again, the OWASP site can help you here.
This is something of a quick taster, brain dump answer. If you can give more specific details of the code behind your app and possibly your experience level it may be possible to give you more low level and thorough advice.