`processor_id` and `trxn_id` is not properly being set on recurring contributions with PayPal Pro
Overview
When a user submits a new, recurring payment on a site that uses PayPal Pro, the processor_id
and trxn_id
are immediately set to a long alphanumeric string on submission and these values are not getting updated with the proper format (a shorter, alphanumeric string that starts with 'I-') that is sent back from PayPal.
This causes an immense issue if the user then wants to cancel their recurring contribution because even though it may seem canceled in CiviCRM, the payment is not canceled on PayPal's side, and so the user continues to be charged. This happens because the PayPalPro IPN is no longer being properly set in the CiviCRM database, so when the request to cancel the recurring payment profile goes to PayPal, it does not have the correct processor_id
needed to cancel it.
Reproduction steps
- If you don't already have one, set up a PayPal Pro Sandbox account that has DPRP enabled for testing recurring payments. Add the API credentials (found in Activity > API Access > NVP/SOAP API integration) of this sandbox account to CivCRM as a test payment processor.
- Fair warning, this set up process with PayPal was not that easy, so if you don't have PayPal Pro, I wouldn't recommend trying this
- From your PayPal Pro Sandbox account settings, go to Notifications, then click Update on Instant payment notifications. If your site is not publicly accessible to the internet (i.e. a local dev site for testing), then set up a webhook.site listening endpoint.
- Submit a new, recurring contribution (while not logged in on CiviCRM and using a PayPal generated credit card for testing) using the PayPal Pro payment processor.
- On the web UI of webhook.site, take a look at the
recurring_payment_id
for the POST request that has'recurring_payment_profile_created'
as the'txn_type'
. - In CiviCRM, either with the API explorer or however you look at the data in the databases, look at the
processor_id
andtrxn_id
in thecivicrm_contribution_recur
table. - You will find that these strings don't match.
Current behaviour
The processor_id
and trxn_id
are being set to long alphanumeric strings, such as 'e13d51f14f7fff9fb6923820022ebc77' upon submission of a recurring payment on a CiviCRM installation that is using PayPal Pro. These values are stored in the civicrm_contribution_recur
table and become problematic for updating or canceling recurring payments.
Expected behaviour
The processor_id
and trxn_id
should be set to (and stored as) the PayPal Pro IPN that is generated when the 'txn_type'
is 'recurring_payment_profile_created'
. The PayPal Pro IPN is an alphanumeric string that notably starts with 'I-', such as 'I-818V5WCCXF2H'
Additional Info
Some backstory - a few years ago, processor_id
was initially set to NULL
and was later updated with the IPN. In that scenario, the logic that CiviCRM used (in /CRM/Core/PaymentPayPalProIPN.php
) made sense, as it checked if that value was set and returned early if it was. However, PR #21539 added processor_id
to parameters that get passed to the recur()
function in PayPalProIPN.php, so the code that sets the value of processor_id
(and trxn_id
) to the properly formatted IPN was not being reached.
@JonGold and I currently have a PR with a fix for this in the works, but are doing further testing with a client.
Given that this issue has been going on for a while (9 months, at least), there are many recurring contributions that have a malformed processor_id
. The PR that will be submitted also includes a check for when 'txn_type'
is 'recurring_payment'
(i.e. subsequent recurring payments) to update the processor_id
and trxn_id
to the proper format, if needed.