Idea Summary
Include a Payment region definition with attributes for keys and options, principally for Stripe. 

Use Case
I think I did my first PayPal integration about 16 years ago with APEX. A good chunk of consumer-facing apps includes a way for money to change hands. It's always the same field requirements and procedure calls, and I don't anticipate doing fewer payment implementations in the future. When I implement now, I follow something similar to what Lino did a Blog series on – js/css at the page and a static region on a page for the elements. A package on the back end to handle the secret/REST handshake. He made a nice tweak to what I was doing before, so kudos to him for that! It's all well and good when taking CC, but it does feel like I'm back in HTML DB again in that it's the one thing I still do today that I did close to the same way so long ago. It's always the same or similar code, just with different option values. I'd love a declarative approach for a payment gateway, and I do think it would be more secure. 

Preferred Solution (Optional)
I think the most secure and consistent method for doing this in APEX would be as a built-in region instead of misc page javascript and css with html regions. The latter works, but a Payment region just seems logical to me since it's the same variables/options each time, and we want it as secure as possible. Stripe has the Elements that can be leveraged, including Card and the newer Payment Element (which is awesome!). I'm working on the latter now and am admittedly stuck, and that's where the “Wouldn't it be cool if this didn't need to be cobbled together” thought came from.  :) So……it's selfish. BUT I wouldn't suggest it if I didn't see it as being something a good chunk of the user base would love as well.