One-Page Checkout [Support Thread]

[lolwaut]

As @dbltoe indicated, setting the input-field to contain the current Gift Certificate amount would result in a possibly-unwanted use of GC funds for the order. That's why the amount is indicated as text below the input field itself.

I don't see how that is possible, since you cannot apply more gift certificate funds than the total of an order. The system won't let you do it. If you apply $50 in gift certificate funds to a $30 order, you will still be left with $20 in your account. And the funds aren't applied until the user specifically clicks the APPLY button, so I feel this is not an issue as it relates to my suggestion.

[lat9]

I don't see how that is possible, since you cannot apply more gift certificate funds than the total of an order. The system won't let you do it. If you apply $50 in gift certificate funds to a $30 order, you will still be left with $20 in your account. And the funds aren't applied until the user specifically clicks the APPLY button, so I feel this is not an issue as it relates to my suggestion.

My point (and I believe @dbltoe's as well) is that pre-populating that input field with the current GC amount will result in the order being placed with GC funds if the customer's not 'watching'. I'll note that that's not necessarily what the customer wants to do.

[lolwaut]

My point (and I believe @dbltoe's as well) is that pre-populating that input field with the current GC amount will result in the order being placed with GC funds if the customer's not 'watching'. I'll note that that's not necessarily what the customer wants to do.

You're right. I misunderstood.

Actually, now that I am fully testing this, if the gift card field is populated with anything but $0.00 and the order is submitted WITHOUT clicking the "Apply" button, Zencart actually throws an error: Your order's details have changed. Please review the current values and re-submit.

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?

[lat9]

You're right. I misunderstood.

Actually, now that I am fully testing this, if the gift card field is populated with anything but $0.00 and the order is submitted WITHOUT clicking the "Apply" button, Zencart actually throws an error: Your order's details have changed. Please review the current values and re-submit.

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?

It's actually One-Page Checkout's processing that issues that message. That's because the order (upon submittal) contains that GC value, but the previous record of the order didn't. That's to 'protect' the customer (and the store) from any misleading charges.

[dbltoe]

@carlwhat For this to be implemented properly, the checkout submit process would need to ignore that field. This might be more complicated than I initially thought. Does your plugin address this?

Best asked in the support thread for the mod.

That clearing of the credit-card fields, IIRC, was a PCI-compliance-related change. What I will look into is the possibility of clearing only the CVV number field, so that all the information doesn't need to be re-entered.

I have found that the more you leave in the forms, the easier it is for the spammers to try to get their stolen cards to work. With just the CVV, all they need do is 999 checks (9,999 for AE) to see which one works. The Zip would be 99,999 which is still doable for the hacker. Turn both off and they will probably bother someone else. And, they will spread the word that you have created a testing ground.

It's always a delicate balance between convenience and security.

[niccol]

I am not sure whether this is alterations I have made or if it is a bug. Still looking at it. Maybe someone can advise me :-)
The file I am looking at is modules/pages/checkout_one_confirmation/header_php.php

Line 203 reads:

                        $_SESSION['shipping']['extras'] = (isset($quote[0]['extras'])) ? $quote[0]['extras'] : '';

The problem is that for a shipping module that has not previously set 'extras' it adds a empty field to the session. Not a problem by itself but then later on we get to ln 278 or so:

$session_end_hash = $checkout_one->hashSession($currencies->format ($order->info['total']));
if ($confirmation_required === false && $order_confirmed === true && $session_end_hash !== $session_start_hash) {
    $error = true;
    $messageStack->add_session('checkout_payment', ERROR_NOJS_ORDER_CHANGED, 'error');
}

Because the session has been amended the error is added. Nothing has actually changed but the hash values will not match.

I find that this is a better version of the line:

                        if(isset($quote[0]['extras'])) $_SESSION['shipping']['extras'] = $quote[0]['extras'];

Perhaps I am missing something though? Or perhaps it is due to a fairly highly modified store. If one of the experts can chime in then that would be great.

Nick

[lat9]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

[niccol]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

True.

I had read that file but somehow missed the first lines of the function. What a numpty.

[mc12345678]

OPC's observer class (which performs the session-hash) doesn't include $_SESSION['shipping']['extras'] as being pertinent to the hash.

But if the condition was understood correctly, on the initial run through of the hash, wasn't $_SESSION['shipping'] not set to begin with? Thus the first cycle would not have that session variable and then when checking for the change, the extras key would be removed but now the shipping session variable would be present?

I say that because of the fix that appeared to work for the OP.