Problem with 4b payment module

[torvista]

Sorry to post a woolly question but here goes.

I am in the final stages of my 1.5 upgrade and can't get this payment module to work. I have no other issues.

I have old and new shops (tienda_139 and tienda_15) on the same local server

When I confirm the order and I get transferred to the gateway, I get the payment page displayed correctly with the 139 shop and an error with the 1.5 shop.
The 4b gateway is archaic rubbish, I can't get any error messages from it.
The payment module code is the same in both shops, I have tried the order.php from 139 and the database details are identical for this module.

I just wanted to know if there is anything new in the 1.5 code relating to payment modules that may impinge on old code.
thanks
Steve

[DrByte]

I just wanted to know if there is anything new in the 1.5 code relating to payment modules that may impinge on old code.

Can't think of anything related to payment modules that would have any such impact.

[torvista]

ok, thanks for the quick response..I'll go back to staring at Beyond Compare then

[torvista]

After breakfast, lunch and dinner of red herrings, I find the problem in the http headers.

The initial string sent to the gateway is composed of the order reference, the business number and the language, strictly in that order.

In 1.5 a security token is prefixed somewhere after the return of $process_button_string from the payment module. This causes the gateway to not recognise the business number/name.

In the module, echoing htmlentities($process_button_string) just before the return yields:

<input type="hidden" name="referencia" value="38" /><input type="hidden" name="ccomercio" value="XXXXX" /><input type="hidden" name="idioma" value="en" />

Live HTTP headers shows this data being passed to the gateway:

1.39
referencia=5&ccomercio=XXXXXX&idioma=en

1.5
securityToken=098edf2901a446fd9baf5e1221e26316&referencia=38&ccomercio=XXXXXX&id ioma=en

I've looked further into this but its not obvious enough for me to see where this gets added....

[torvista]

Ok, there is a new line in 1.5 html_output.php that adds a security token for forms using post.

 *  Output a form
 */
  function zen_draw_form($name, $action, $method = 'post', $parameters = '') {
    $form = '<form name="' . zen_output_string($name) . '" action="' . zen_output_string($action) . '" method="' . zen_output_string($method) . '"';

    if (zen_not_null($parameters)) $form .= ' ' . $parameters;

    $form .= '>';
    if (strtolower($method) == 'post') $form .= '<input type="hidden" name="securityToken" value="' . $_SESSION['securityToken'] . '" />';
    return $form;
  } 

In tp_checkout_confirmation_default.php we have the button/form creation:

<?php
  echo zen_draw_form('checkout_confirmation', $form_action_url, 'post', 'id="checkout_confirmation" onsubmit="submitonce();"');

  if (is_array($payment_modules->modules)) {
    echo $payment_modules->process_button();
  }
?>

So the token is being added here.

While I can hack this for this one payment module, I am more interested in how it should be done properly.

thanks
Steve

[DrByte]

Since your payment gateway is incapable of accepting user-submitted parameters, for your unique payment module's requirements, you'll need to hack your checkout-confirmation template file and draw your own form instead of using zen_draw_form(). Be aware that any alterations you make to checkout files/templates/logic/code have a direct impact on your PCI validation.

[torvista]

Ha! No surprises there, PCI is still unknown by most businesses here in Spain.

4b is one of the only three card/atm networks and (in my experience) seem to be coasting along with code, documentation, support and attitude from twenty years ago.

Just to round off, for interest, what do you mean by "user-submitted parameters" as opposed to how it works now?

thanks
Steve

[DrByte]

By "user-submitted" I was referring to "extra" or "unexpected" parameters that their system doesn't recognize or do anything with. Most modern gateways allow you to pass many additional fields, which they often pass back to you when they complete the transaction and send the customer back.