ContributionProcessor.php only processes first payment of a subscription.

Some time ago I submitted patches to make ContributionProcessor.php handle recurring contributions. It turns out the patches worked just fine for the first payment of a subscription, but would fail for subsequent payments. This was because I was not altering invoice_id in the incoming payment, and so the system would fail to add the contribution because it would detect a duplicate contribution with the same invoice_id. Additionally, it would try to add a new record in the civicrm_contribution_recur table instead of trying to update any existing record. The following patch to CRM/Contribute/BAO/Contribution/Utils.php should fix all this, and has been tested on our 3.1.3 system:

http://code.creativecommons.org/viewgit/civicrm.git/commit/?h=cc_production_3.1.3&id=d45be78424d75c8834455501601421a822fa1dcb

This tiny patch to ContributionProcessor.php simply maps PayPal's subscriptionid field to CiviCRM's processor_id field (which is also used by the patch above):

http://code.creativecommons.org/viewgit/civicrm.git/commit/?h=cc_production_3.1.3&id=8b5b8c63000735e73567ce6baa96fe4030a8b81a

NOTE: without special handling in advance, recurring payments with ContributionProcessor.php via Google Checkout will not work because, unlike PayPal, Google does not send any ID that can uniquely identify a given payment as belonging or being associated with a certain subscription. As far as I have been able to figure out so far the only way to get around this is manually with merchant_private_data.