My payment processor supports recurring payments via "credit card tokens".
This means that when someone makes a purchase, either you or the customer will send their credit card to your processor, and the processor will hand you a token back. Unlike a credit card, that token cannot be taken somewhere else and used; it's only valid between you and your processor to represent this one customer. You do not store their credit card; you forget all about it, and use the token instead.
The processor holds on to the credit card number, and whenever you say "Charge this token," they use the card number to effect the charge.
The advantage of this system is that you are not responsible for securing PAN ("Primary Account Number") data, which simplifies your security and audit concerns. If you arrange for your customers to hand their card numbers directly to the processor, without handing them to you first, then you can greatly reduce your PCI scope and obligations.
What's the best way to store these tokens?
Usually, in a database. They don't require the same level of encryption and protection that you would have to use for PAN data, if that's what you're concerned about.
What if my system is compromised and someone get their hands on the tokens?
If someone steals your entire database of tokens, they can't use them to do anything. They're not good for anything except in the context of you sending them to your processor using your credentials, which will get noticed very quickly when customers see they're double billed. (And the only way to monetize that is if your "membership" site ships something valuable, like cases of wine, out to customers, and the attacker could intercept the shipment).