The above answer might be a bit dated. Modern SaaS applications that want to serve SSL for multiple customer domains will use SNI. SNI is "Server Name Indication" (RFC 6066; obsoleted RFC 4366, RFC 3546) is an extension to Transport Layer Security which allows the client to tell the server the name of the host it is trying to reach.
This is much more efficient than older ways of handling this, like UCC or even worse, 1 IP per certificate. This is also why traditionally, getting custom domains secured would be a cost that gets passed to the customer. It was and is fairly common to see the platform charging $X/mo for custom domains as an additional feature. That's because of the costs involved in running custom domains.
If you're looking to develop something like this today, you'd start out with SNI and serve certificates that way. Depending on your stack, this can be really easy to do (NodeJS) or really hard (traditional apache/nginx based app-proxies). Usually the difficulty is taking in the incoming SNI request and matching it up with your database or other application logic to make sure you're serving the correct cert for that request.
As mentioned, you might be in luck if you're using Node. There are some great libraries that help with this if you want to serve certificates provided by Let's Encrypt and you want to dynamically provide a certificate based on data in the incoming request. For example https://git.coolaj86.com/coolaj86/greenlock.js is a library that helps you with some of this.
Lastly, if you're looking for a third party solution, there's https://clearalias.com, which basically allows you to bypass the difficulties of serving SNI SSL certificates by offering it as a service if you're not particularly keen on managing and maintaining your own SNI layer.