GitHub User: andrei4002
By using includes there, the polymorphic association is loaded in the best possible way (meaning that first it runs a query to load the feed items, and then, judging by the id/types it does a query for each type, and not for each instance, which from my point of view it's the best possible way to do it)
I had a more difficult problem posted here where I wanted to do an includes on the polymorphic model to eager-load other associated models, but ended up doing a manual sweep
It's not a problem, it's how paypal works. If you create a recurring profile, you'll get a recurring payment sometime during the start day of that profile.
If you request an initial amount too, you'll receive the initial payment sometime during the day that you create the profile AND a recurring profile payment during the day that the profile actually starts (if you create it with the start date set as today, the customer will be billed twice during today)
The request_payment called before creating a recurring payment charges the customer instantly, and has nothing to do with the recurring profile itself (it's a totally separated payment)
Having these in mind, a couple of ways of doing this would sound like this:
1) Create a request payment, and if it passes, create a recurring profile, starting today+30.days (not sure it's very cool, n'or consistent)
2) Create a recurring profile starting today, and process the billing in your application by using an IPN listener when paypal sends it (maybe give the user a period of I dunno, 24-48 hours for the "Complete" IPN answer to come from paypal, in which he could use your app)
Amaizing episode here. A railscast over cancellation/changing plans and other events like these that might happen would be awesome!