Well, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem.
If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag.
You, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train.
Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln.
That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.
If you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag?
And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
Ok, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI?
You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly.
You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.
If jQuery is compromised you'll detect it and download from different location but for stripe there is no fallback.