You're at a very exciting time in your project. Unfortunately, it's tough to answer a lot of the specific questions without knowing what the application will do. An e-commerce stack will look very different than a realtime multiplayer platform (not really SaaS, but my point remains).
For general advice, I'd say use what you're familiar with. Unless you have very specific requirements, it's not worth sacrificing productivity. The reality is, as it is with all startups, you're resource constrained, so spend your limited resources where they'll have the most impact: building something unique and innovative from parts you understand. Time is the enemy.
Abstract what you can. You mentioned a particular payment gateway. I'd say find a good abstraction library that can act as a layer between your application and any number of payment gateways (stripe, paypal api, etc). Same for transactional email service providers. If you wrap your application in a container (e.g. docker), that improves your ability to deploy to any number of hosting providers, if you outgrow one option. If you're not satisfied with some service or provider, you might get away with just changing configuration.
Of course, there are inherent contradictions above. I said abstract, but I also said time is the enemy: maybe committing to Heroku and it's ecosystem has time saving benefits. That's a tradeoff you'll have to assess, as it's difficult to know your needs and your skill set.
Pick your database for your purpose. If you need well-defined transactions, RDBMSs are the ticket (PostgreSQL, MySQL, CloudSQL..., and use an ORM). Document DBs are nice and flexible. MongoDB is a well known quantity. RethinkDB is geared towards realtime, and if it suits your goals, use it. Of course, you can use multiple DBs and match each to their task (probably the most dubious statement I make; it's true, but if data in one DB relates to data in another, it means more logic at the application layer to connect them and possibly performance implications, so there can be a cost).
Don't look too far forward. Yes, you should adopt generally good design principles (preparing for horizontal scaling, leaving room for caching), but at this stage, you don't know for sure if your product has a market, or even if it's the product you'll end up with (you'll iterate). I'd rather be a victim of success and have a problem to solve, than have put a lot of time and energy into optimizing a product that doesn't have an audience.
Good luck!