GitLab

Payment PropertyBag was added in 5.20 but it is only when attempting conversion of payment code/processors that we find things that are missing or still need consideration. I'm adding some things here but would encourage @eileen @artfulrobot and others to edit/update this description once we are in agreement.

1. The following parameters should be added:

• trxn_id -> Maps to transactionID.
• installments
• recur start/end dates?

2. To support a phased conversion to propertyBag we should allow exporting as an array: https://github.com/civicrm/civicrm-core/pull/17507 or similar. Alternatively we should document using reflection to access the propertyBag array eg.:

    if ($propertyBag instanceof \Civi\Payment\PropertyBag) {
      $reflectionClass = new ReflectionClass($propertyBag);
      $reflectionProperty = $reflectionClass->getProperty('props');
      $reflectionProperty->setAccessible(TRUE);
      $params = $reflectionProperty->getValue($propertyBag)['default'];
    }
    else {
      $params = $propertyBag;
    }

3. Some parameters should be either be ignored or added to propertyBag in some form during mergeLegacyInputParams such as:

• qfKey
• entryURL
• qf_default..

Note that both qfKey and entryURL can be useful for guessing context though it would be nice if there was a better way to identify the context in which a payment processor was being used. Eg. see https://lab.civicrm.org/extensions/stripe/-/blob/6.4.1/CRM/Core/Payment/Stripe.php#L1063 for an example of qfKey usage which shows that we don't really need qfKey but do need a more formal way of obtaining an errorURL or removing the need for it at all.