Handle notification requests

Yes well but this makes it necessary to add the devel module as a dependency, otherwise it woun't work! (Because drupal_debug() is not a core function).

fixed typos

I love the work done so far, but this module is kinda useless for production without notification support I believe. I'm not fully into Adyen or the commerce module, but it doesn't seem to be very difficult to fix this. Doesn't the notification service simply send the same parameters as the original redirect (just POST instead of GET)? In that case, shouldn't this just work?

$payment_method = commerce_payment_method_instance_load('commerce_adyen|commerce_payment_commerce_adyen');
  $adyen = (object)$_POST;
  
  $hmacData = $adyen->authResult.(isset($adyen->pspReference)?$adyen->pspReference:'').$adyen->merchantReference.$adyen->skinCode.$adyen->merchantReturnData;
  $merchantSig = base64_encode(hash_hmac('sha1',$hmacData,$payment_method['settings']['hmac'],true));
  
  if ($merchantSig!=$adyen->merchantSig) {
    watchdog('commerce_adyen', t('Received adyen response with invalid HMAC signature.'), array(), WATCHDOG_ERROR);
    drupal_set_message(t('Commmunication failure. Please contact the system administrator.'), 'error');
    // we don't call commerce_payment_redirect_pane_previous_page($order) here
    // because we cannot trust the data we received
    drupal_goto();
  }
  
  $order_id = (string) db_query('SELECT order_id FROM {commerce_order} WHERE order_number=:order_id', array(':order_id'=>$adyen->merchantReference))->fetchField();
  
  switch (check_plain($adyen->authResult)) {
    case 'AUTHORISED':
      $order = commerce_order_load($order_id);
      _commerce_adyen_transaction_save($payment_method, $order, $adyen, COMMERCE_PAYMENT_STATUS_SUCCESS);
      break;
    case 'REFUSED':
    case 'CANCELLED':
    case 'PENDING':
     watchdog('commerce_adyen', t('Received adyen notification with refused payment'), array(), WATCHDOG_ERROR);
      break;
    default:
      watchdog('commerce_adyen', t('Received adyen response with invalid authResult.'), array(), WATCHDOG_ERROR);
     break;
  }
echo '[accepted]';

I Just would like to know if I'm not missing anything.

Hello guys,

I developed some E-commerce project with your module and I implemented handle notification requests.

Please check my patch.
Best regards.

Not sure why this has been marked as Closed (Fixed) as this hasn't been committed to the module!

Changing status to Needs Reivew.

Ok so, this patch actually appears to be quite useful, rather than the placeholder callback!

I'm testing it today, so will report back.

Ok so the patch looks good, but there was an issue where there was a custom function to return the variable name instead of the standard variable_get causing a fatal error.

Re-rolled the patch with the custom variable get functions changed to variable_get.

Hello!
Thank you for your review.
Where have you found a custom function which returns the variable name causing a fatal error instead of the standard variable_get?

Hey,

Lines 121, 128, 135 of your patch were referencing the function 'eurail_site_variable_get' instead of 'variable_get' :)

Also with more testing of this patch I have realised that with a commerce payment settings form we should be saving into the $settings array, not the Drupal variable system, as unless you have already saved these variables elsewhere these changes will never be saved / picked up.

I have re-rolled the patch again, to switch using the correct commerce $settings to store the basic auth option | username | password, and consequently in the access callback for the notifications basic auth check, we now get the settings from the payment rule instance.

Also added stricter string comparison of the details, === instead of ==.

Found one more issue, other than that think we are good :)

In commerce_adyen_commerce_adyen_handle_notification_authorisation,

There is no check to see if

$order = commerce_order_load($notification->merchantReference);

returns a valid order, so the subsequent call to

  _commerce_adyen_transaction_save(
    $payment_method,
    $order,
    $notification,
    COMMERCE_PAYMENT_STATUS_SUCCESS
  );

fails, as we might not have a valid order loaded from the $notification->merchantReference.

Found this issue out using the 'test notifications' functionality with Adyen in the config panel, the response I got back for the test_AUTHORISATION_1, test_AUTHORISATION_2, test_AUTHORISATION_3, test_AUTHORISATION_4 tests was not [success] as this code was causing a Drupal entity error to be output before we actually get to return [success].

Modified the last patch I uploaded to ensure we only try to save the transaction if the $order actually loaded :)

Slight modification to @rossb89's patch - we found the transaction was being saved twice and thus triggering rules to send duplicate emails.

Needs re-roll.

+++ b/commerce_adyen.module
@@ -322,13 +362,129 @@ function _commerce_adyen_handle_response() {
+  echo "[accepted]";

Menu callback must not print anything!

@BR0kEN
I think you didn't work with Adyen, because it required '[accepted]' string in response.

@Andrew.Mikhailov
I think you didn't work with Drupal, because it requires menu callback to return something and delivery callback - to deliver.

http://cgit.drupalcode.org/commerce_adyen/tree/commerce_adyen.module#n254

+++ b/commerce_adyen.module
@@ -15,18 +29,18 @@ define('LIVE_URL', 'https://live.adyen.com/hpp/pay.shtml');
+    'title' => 'adyen response',

title should not be specified for MENU_CALLBACK.

I'll close this ticket since 7.x-1.x will no longer be maintained.