Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.3.3
-
Fix Version/s: 4.4.0
-
Component/s: CiviContribute
-
Labels:None
Description
A payment extension provides a payment class (deriving from CRM_Core_Payment) identified by a payment method name.
On IPN requests, the following static method is always called:
CRM_Core_Payment::handleIPN(), which calls
CRM_Core_Payment::handlePaymentMethod().
The latter fetches the payment processor by civicrm_payment_processor_type.name.
If two payment processor instances exist in the database for the same processor type, then this will be ambiguous, and CiviCRM will likely load the wrong processor instance.
Result: The IPN fails.
Attachments
Activity
Yes. We need to load the processor by id, not by processor type name.
At the same we need to be backwards compatible.
'processor_name' => @$_GET['processor_name'],
'mode' => @$_GET['mode'],
So, we should check if a $_GET['processor_id'] is available, and if it is, load by id.
Otherwise we do the old thing and load by processor type name.
I can work on a patch, yes.
(maybe tonight)
Hi!
I am sorry I dropped this..
but it seems it is being taken care of by you guys now? I am very ok with that! 
And the pull request seems solid to me.
(though I did not test it)
Kurund, assigning to you for QA.
Looks good to me, merged and closed.
I think we need to send payment processor id to the payment processor and then use that during ipn callback. It would be great if you can submit a patch ( PR ) for this.