CiviCRM Community Forums (archive)

Hi Eliet,

I think we have the same problem. I'm running Civi 3.4.7 on Joomla 1.5.
Can you post the 'Merchant reference ID' from a recurring payment that failed? This can be found in the Profile Details page on Paypal.
It should look something like this (taken from a recurring card payment):

i=1c7cc06ef652fb91820e0ad4539xxxxx&m=contribute&c=1&r=73&b=6164&p=1

I think the issue is that Paypal Express only sets the 'i' parameter, so the above example looks like this (taken from an Express Checkout payment):

i=1c7cc06ef652fb91820e0ad4539abb0b&m=&c=&r=&b=&p=1

When the IPN posts to Civi, it gets rejected claiming there's 'No Module Parameter Found'. In other words, it doesn't know if the callback refers to a contribution or an event. This is set by the m= parameter.
Even if you force Civi to default to contribution - it still fails, as there is way to match to a donor ID (c=<donor_id>).

Would you confirm that it's the same issue by checking a Merchant ID from a failed payment? Then maybe we can get advice on whether to change the PayPal Express form, or the PayPal IPN that's supposed to do the matching.

Thanks for the reply, Lobo.

I've had a go at making the changes myself. I'm no expert - so there may be gaping flaws in the rewrites.
The altered files are attached and could be copied over the following files (renamed to xxx.php):

/<joomla_root>/administrator/components/com_civicrm/civicrm/extern/ipn.php
/<joomla_root>/administrator/components/com_civicrm/civicrm/CRM/Core/Payment/PayPalProIPN.php

Basically, the ipn.php file checks for the presence of an invoice_id and (combined with the absence of a module, assumes a contribution) - this in turn is used to compare against the original recurring payment. From that, PayPalProIPN.php retrieves the other details (such as contact_ID, recurring_payment_ID etc....)

I've tested it using the sandbox and live - and left a fair bit of logging in to check it's working okay.
Any suggestions for code improvements would be very welcome!

Here they are. I had copied the originals to .bak - so I hope this is right....

Hi Deepak,

Sure, I'll take a look and give it a go.
The method of using the invoiceID means, for us, that historical subscriptions will keep working.

But I've found the file ../Payment/PayPalImpl.php which I think is the right one.
I'll let you know how it goes!

Hi Eileen,

I think you're right.  And changing the workflow wouldn't address the problem for historic donations - which can go on for years!

Finding another way of linking the recurring donations to the donor record was of more use to us, using the method explained in my second post.  However, this has had the frustrating side effect of creating duplicate donation records for new sign-ups - as the workaround doesn't distinguish between a 'recurring_payment_profile_created' and 'recurring_payment' transaction type.

I'm looking into ways of marking the 'recurring_payment_profile_created' type as 'pending'. This is then completed with the correct amounts (ie. fee, net & total) and transaction ID when the second IPN callback occurs (usually a minute or two later from PayPal).

I've tried several code changes to the 'recur' function - but have not had much luck so far. If anyone has any pointers, it would be much appreciated!

I have updated the ticket with what we are using

http://issues.civicrm.org/jira/browse/CRM-12679#comment-52205

I have this working of 4.2-d7 (git@github.com:fuzionnz/civicrm.git)

the above gives detailed information of what bits have been submitted to which versions of core - but the bit that actually makes it work has not been submitted & I have no immediate plans (funding) to do that