Include additional order details in Payflow payments via a custom event

+    if ($order->hasField('shipping_profile') && !$order->get('shipping_profile')->isEmpty()) {
+      $shipping_profile = $order->get('shipping_profile')->entity;

This is odd.
Commerce Shipping doesn't add such a field. Why would we add integration for a non-Shipping-provided field?
Sounds like we need an alter mechanism (== event) instead.

1. +++ b/src/Plugin/Commerce/PaymentGateway/Payflow.php
   @@ -210,15 +212,124 @@ class Payflow extends OnsitePaymentGatewayBase implements PayflowInterface {
   +      'invnum' => $order->getOrderNumber(),
   

   The order number isn't populated until the order is placed, so this will be empty.

2. +++ b/src/Plugin/Commerce/PaymentGateway/Payflow.php
   @@ -210,15 +212,124 @@ class Payflow extends OnsitePaymentGatewayBase implements PayflowInterface {
   +    if ($order->hasField('shipping_profile') && !$order->get('shipping_profile')->isEmpty()) {
   +      $shipping_profile = $order->get('shipping_profile')->entity;
   +      if ($shipping_profile instanceof ProfileInterface) {
   +        $parameters = $this->populateShippingProfileParameters($parameters, $shipping_profile);
   +      }
   +    }
   

   I think we should just remove this, for now. Or check if shipping module is enabled.

3. +++ b/src/Plugin/Commerce/PaymentGateway/Payflow.php
   @@ -210,15 +212,124 @@ class Payflow extends OnsitePaymentGatewayBase implements PayflowInterface {
   +  protected function populateBillingProfileParameters(array $parameters, ProfileInterface $profile) {
   

   Why should this be split out of the main function?

I'm attempting to tackle this from another direction - similar to how the CheckoutSdk.php handles modifying the PayPal request params. Perhaps, we should allow the parameters to be specified via an Event Subscriber when the payment is created via Payflow. I've incorporated a few changes that create a new Event for Payflow payment creation, and that dispatch said event within the createPayment() method.

Custom modules should be able to subscribe to the PayPalEvents::PAYFLOW_CREATE_PAYMENT event and modify the request parameters as needed.

It appears that the latest test failure is due to a previously existing "Symmetric array destructuring" assignment - this feature was introduced in PHP 7.1 (I'm assuming that the test runner is using PHP 7.0?). This is the offending code block from line 296 of src/Plugin/Commerce/PaymentGateway/Payflow.php.

[$key, $value] = explode('=', $bodyPart, 2);

Otherwise, it appears the tests were successful.

@shaunole thanks for doing this work. I've found myself needing to conditionally set the paypal comment1 field for a project and having an event subscriber to modify the values before going to paypal would be extremely helpful.

Resolved remaining test failures. We should be good to merge this into the next release.

+1 from me on the approach - we should have request / response events for every API integration. This just needs the docblock at https://git.drupalcode.org/project/commerce_paypal/-/merge_requests/8/di... fixed and it's ready to commit.

Thanks @rszrama. The Dockblocks have been updated. Thanks for the feedback.

The PHP7 test failure is unrelated as its being caused by the void return type being specified in commerce_paypal/tests/src/Kernel/IPNHandlerTest.php::setUp() function declaration. Including the return type was intentionally introduced in commit https://git.drupalcode.org/project/commerce_paypal/-/commit/0741a59b3203... and released in 8.x-1.0-rc4.

Thanks for the updates. Merging this in via the CLI ... I still don't know how to use GitLab to squash / retitle merges. 🤷🏼‍♂️

Great! Thank you @szrama. I appreciate the review and feedback.