Amusingly, this was part of the original design of Certbot, which made a distinction between “renew” and “deploy” based on the idea that users would want to inspect their certificates manually before starting to use them. We ended up finding that almost no users ever wanted to do this.
There are various workarounds that are probably possible with Certbot. One is that you could edit your Apache configuration to point at a specific version of the certificate in /etc/letsencrypt/archive instead of /etc/letsencrypt/live. The old versions are always all retained in /etc/letsencrypt/archive, but we normally don’t suggest referring to them specifically because your web server won’t autoupdate to a new certificate following a renewal. 
If you point to a version in /etc/letsencrypt/archive, you can then manually change your Apache configuration to point to a newer one when you’re ready for it. The new versions will be visible there, so you can view them and upload them to PayPal.
Basically, we didn’t make this behavior the default (or even particularly conveniently available) because it requires so much manual intervention, and very few users see that as a benefit rather than as an inconvenience. But it looks like it would be a benefit to you in this case.
The files in /etc/letsencrypt/archive are like the ones in /etc/letsencrypt/live, but they’re numbered (with successive versions that increment on each renewal). You should always use a matching privkey, cert, and chain set because their contents correspond to each other. (Remember that at some point chain will change, although it probably typically only changes once every few years.)