Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
F
Financial
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 82
    • Issues 82
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Development
  • Financial
  • Issues
  • #133

Closed
Open
Opened Jun 08, 2020 by mattwire@mattwireDeveloper

Enhancements to Payment PropertyBag

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?
  1. 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;
    }
  1. 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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: dev/financial#133