I think the Restore Online Shoppers’ Confidence Act [1] made this impossible in the US. Instapaper would be a third party seller and would be bound by new data pass rules:
(2) the post-transaction third party seller has received the express informed consent for the charge from the consumer whose credit card, debit card, bank account, or other financial account will be charged by--
(A) obtaining from the consumer--
(i) the full account number of the account to be charged; and
(ii) the consumer's name and address and a means to contact the consumer;
and
(B) requiring the consumer to perform an additional affirmative action, such as clicking on a confirmation button or checking a box that indicates the consumer's consent to be charged the amount disclosed
I'd better elaborate here. No, I do not suggest that the 3rd party APIs should pass customer credit cards to instapaper before recieving an API key.
Instead Instapaper should allow developers (or any user) to have more than than one API key/subscription associated with a single card or account. That way if I'm a 3rd party developer, I can create 100 subscriptions myself, and attatch them individually to each program I release to a customer.
The customers information never goes to Instapaper.
My account can be pre-billed if that's what it takes to stay within fincance regulations, but once there's a certain amount prepaid into the account I should be able to create a working subscription key via api.
One benefit of this is that Instapaper doesn't have to worry about dealing with front-line customers---that's the 3rd party developers responsibility. If one customer overuses the API, Instapaper can just cut them off and leave the investigation up to the 3rd party developer.
That way 3rd party apps can create new keys and issue them to their users transparently.