I've implemented something very similar to what you describe. Any time the user wanted to fund his/her account, he/she had the option of either providing a credit card number, or, if applicable, re-using the last credit card.
In this implementation, I just stored the last four digits of the "default" card at Stripe locally, in my own database table. When building the credit card entry form, the server looked for this stored value, and, if present, the server rendered a checkbox back to the browser, labeled something like "Use Credit Card XXXX XXXX XXXX 1234". If the user checked the box, then my code would submit a transaction to Stripe indicating that the default card should be used.
Three factors led me to this design:
1) We wanted to be able to list funding transactions (both successful and failed) for our users. These listings needed to show the last four digits of the credit card number, to give the user necessary context information about each funding attempt. Perhaps we could have queried Stripe transaction by transaction when building this listing for the user, but that seems like a lot of back-and-forth. So we really wanted to store "last four digit" info anyway.
2) Storing the last 4 digits of the credit card did not seem like a big security risk. It's customary to show the last 4 digits in less secure situations. So, while we did not want to store full credit card numbers in the database, we thought that storing the last 4 digits of certain cards was acceptable.
3) It was simple. There was no need to manage a list of card numbers for each user, but the vast majority of use cases for something like that were (in my estimation) addressed anyway.
Presumably, if someone got the last 4 digits from our database, and then intercepted Stripe traffic from our site, they might have some sort of head start on decrypting this traffic. But this is a far smaller risk than storing real credit cards would be.