These are all decisions that each app has to make for themselves, and while sure, some of it could perhaps be rolled into a 'framework' that sits on Django or RoR, it's going to be difficult to get anywhere close to something most people wouldn't have to change.
As the target market for this would almost certainly be developers who can take a few libraries off of GitHub, tailor them to themselves, and have all the above functionality implemented within a day, I'd be surprised to find if something existed in the way you want.
There are a variety[1] of[2] ways[3] you can implement subdomain keys in Django, but each is effectively downloadable from somewhere and installable, possibly just with pip.
Again, there are a myriad[4] of ways to implement payment processing and subscriptions using Django, easily installable, but picking the right one for your application type is up to the architect. Creating one monolithic payment library that supports every possible payment type, subscription method, payment gateway provider, etc., is just asking someone to build a bloated app. I'd much rather drop in 'payments-with-stripe' if I'm using Stripe as my payment gateway than to install 'omni-payments' and have to spend the day configuring it to work how I want, then worry about the size of the codebase and the likelihood of human error.
Like I said, most of the things you're looking for can either be dropped in or just coded in a day.
[1] - http://thingsilearned.com/2009/01/05/using-subdomains-in-dja...
[2] - https://github.com/tkaemming/django-subdomains
[3] - http://code.google.com/p/django-accounts/
[4] - http://www.djangopackages.com/grids/g/payment-processing/