Problem/Motivation

Current implementation of commerce_elavon_request() only allow fields starting with 'ssl_' to be include in the request to Elavon. This will force merchant to define their custom fields start with 'ssl_' which is confusing with the SSL fields that already existed.

Current implementation:

foreach ($info as $key => $value) {
    // Keep keys starting by ssl_.
    if (strpos($key, 'ssl_') !== 0) {
      continue;
    }
    $sanitized_key = check_plain($key);
    $xmldata .= '<' . $sanitized_key . '>' . check_plain($value) . '</' . $sanitized_key . '>';
  }

Proposed resolution

Remove the restriction.

foreach ($info as $key => $value) {
    $sanitized_key = check_plain($key);
    $xmldata .= '<' . $sanitized_key . '>' . check_plain($value) . '</' . $sanitized_key . '>';
  }
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xlin1003 created an issue. See original summary.

xlin1003’s picture

Status: Active » Needs review
FileSize
553 bytes

Here is the patch to remove the 'ssl_' restriction.

Status: Needs review » Needs work

The last submitted patch, 2: allow-post-non-ssl-custom-fields-2807347-2.patch, failed testing.

wuinfo - Bill Wu’s picture

I think all the keys require to start with "ssl_" prefix. If that is right, it is necessary to have that check. Let me know if I am wrong and send me the latest related documentation from the vendor.

wuinfo - Bill Wu’s picture

Status: Needs work » Closed (outdated)