This proposal fits very well with the proposed payment flows we are looking at in the Web Payments WG. There are currently two under consideration  but they are fairly similar in many respects and I see an opportunity for the paymentRequest object in these proposals to provide some of the meta-data you describe in yours with regard to things like payment terms.
If we get the payment piece right I can imagine an experience where clicking the content link triggers the payment flow immediately and the user is able to complete the payment in very few clicks (or none if they have configured one of their “payment apps” to automatically make certain payments under specific conditions).
This raises an interesting use case where knowing that a user is already aware that they will have to pay for access to a resource and have confirmed their willingness to do so is useful data to pass to the “payment app” as this could be considered in deciding whether or not to prompt the user for confirmation.
This proposal also has some connections with a discussion currently underway in the Web Payments Community Group  (who authored one of the proposals) about defining a standard for the 402 Payment Required HTTP response code.
Enhancements to the Web Payments API are under discussion as a next piece of work for the Web Payments IG to tackle including the ability to handle loyalty programs (subscriptions may fit into this) and coupons (which could handle the FT’s “send an article to a friend” use case) and more.
I’d encourage you to join both the Web Payments IG and WG to represent the interests of digital publishers.