One-Page Checkout [Support Thread]

Rick, the OPC debug file is generated (and accumulated) on a customer-id basis so that I can infer the transitions from the main (checkout_one) to confirmation (checkout_one_confirmation) pages.

Note that the error message is indicating that something has changed between the main-page's submission and the confirmation page's processing and "normally" isn't displayed.

Send me a copy of the myDEBUG and OPC debug files and I'll see what's up.

Files sent via email.

The only thing changed was the radio button to select payment method prior to clicking submit the first time. I dunno.

Rick, it looks like those prowebs order-totals are interfering with the OPC's "has the order changed" checking. I've requested a copy so that I can see what's going on.

I'm guessing that you set the OPC debug level to "full" to generate those PHP notify logs; it's normally sufficient to just use the "true" setting to get the OPC log generated. The "full" setting was added for additional debug and is not normally needed.

Yes, I set to full because I figured that would tell you more.

Disabling the prowebs OT, still generates myDEBUGS (still set to full). The fileset includes 5 OT but I am only using 2 of them.

Rick, when the OPC log is set to "full" you'll normally get a slew of logged notices, usually due to a constant's redefinition.

When you disabled the prowebs order-total modules, did that enable the checkout to proceed without issue? If not, would you first delete that OPC log, re-run the checkout with the prowebs OTs disabled and then email me that log file?

Good morning Cindy,

Deleted myDEBUG-OPC files
Changed OPC log from Full to True
Prowebs OT config set to false (disabled)
Checkout payment using auth.net SIM completed without any errors on the customer side.

myDEBUG-OPC generated. CustNumber appended to the end. Probably normal ? ~33kb filesize

No RED banner either :smile:

RixStix:

Good morning Cindy,

Deleted myDEBUG-OPC files
Changed OPC log from Full to True
Prowebs OT config set to false (disabled)
Checkout payment using auth.net SIM completed without any errors on the customer side.

myDEBUG-OPC generated. CustNumber appended to the end. Probably normal ? ~33kb filesize

No RED banner either :smile:
Hey, Rick, thanks for the update. I'm going to have to add those prowebs order-totals to the list of "known to be incompatible" items and I'll note that Authorize.net/SIM is "known to work".

With the OPC debug set to true, a myDEBUG-OPC log will be generated (and they're normally quite large, as you've seen).

No problem. I didn't want you to spend too much time 'futzing' with things that are out of your control.

I could always remove those OT mods and find a different way to provide customer selectable Signature and Insurance requirements during checkout that are independent of specific shipping methods.

Enjoy the rest of the weekend.

Pleased to report that the Nochex payment module works with OPC. So, that's another one for the list of compatible payments mods :smile:

Cheers / Frank

frank18:

Pleased to report that the Nochex payment module works with OPC. So, that's another one for the list of compatible payments mods :smile:

Cheers / Frank
Thanks for that, Frank. I'll update the documentation to reflect that Nochex has been found to be compatible!

lat9:

Thanks for that update, @LightBrown. Which version of COWOA did you use for the integration?

V 2.6, I think.

A report that quantity discounts 1.12.1 & preview 1.12 (paid mod) works with OPC ...

Thanks for that, haredo!

My apologies if this is a silly question, but how does this plugin differ from the Paypal Express Checkout that comes standard with Zencart?

ttfan:

My apologies if this is a silly question, but how does this plugin differ from the Paypal Express Checkout that comes standard with Zencart?
This plugin provides a reformatting of the checkout pages, so instead of going from checkout_shipping to checkout_payment to checkout_confirmation your customers will normally see a consolidation of those three pages into a single checkout_one page. Depending on the payment methods that your store uses, your customers might also see a confirmation page.

Essentially, the checkout process gets a bit more streamlined by this plugin's processing.

I do love this plugin. :smile: I have a client using Klarna for payment. I was expecting it would be a problem, and it is. I get 'the details of your order have changed' error. Klarna isn't a popular payment module, so not sure if you want to try and tackle this one or not. If yes, I can send the error log.

James, what happens after you edit the following block in /includes/modules/pages/checkout_one_confirmation/header_php.php:

// -----
// There are some payment methods (like eWay) that "replace" the confirmation form via the HTML they return on
// the "process_button" payment-class function.  Rather than hard-code the list in code, below, the following
// constant will be updated as additional payment-methods that make use of that interface are identified.
//
if (!defined ('CHECKOUT_ONE_CONFIRMATION_REQUIRED')) {
    define ('CHECKOUT_ONE_CONFIRMATION_REQUIRED', 'eway_rapid,stripepay,gps');
}

to include that Klarna payment method, presumed to have a payment-module-code of klarna:

// -----
// There are some payment methods (like eWay) that "replace" the confirmation form via the HTML they return on
// the "process_button" payment-class function.  Rather than hard-code the list in code, below, the following
// constant will be updated as additional payment-methods that make use of that interface are identified.
//
if (!defined ('CHECKOUT_ONE_CONFIRMATION_REQUIRED')) {
    define ('CHECKOUT_ONE_CONFIRMATION_REQUIRED', 'eway_rapid,stripepay,gps[B],klarna[/B]');
}

lat9:

James, what happens after you edit the following block in /includes/modules/pages/checkout_one_confirmation/header_php.php:

// -----
// There are some payment methods (like eWay) that "replace" the confirmation form via the HTML they return on
// the "process_button" payment-class function. Rather than hard-code the list in code, below, the following
// constant will be updated as additional payment-methods that make use of that interface are identified.
//
if (!defined ('CHECKOUT_ONE_CONFIRMATION_REQUIRED')) {
define ('CHECKOUT_ONE_CONFIRMATION_REQUIRED', 'eway_rapid,stripepay,gps');
}

> to include that Klarna payment method, presumed to have a payment-module-code of klarna:
> ```
// -----
// There are some payment methods (like eWay) that "replace" the confirmation form via the HTML they return on
// the "process_button" payment-class function.  Rather than hard-code the list in code, below, the following
// constant will be updated as additional payment-methods that make use of that interface are identified.
//
if (!defined ('CHECKOUT_ONE_CONFIRMATION_REQUIRED')) {
    define ('CHECKOUT_ONE_CONFIRMATION_REQUIRED', 'eway_rapid,stripepay,gps[B],klarna[/B]');
}

That might have fixed it. I'm getting an error back from Klarna that the phone number is mis-formatted so I'll track that down now.

jeking:

That might have fixed it. I'm getting an error back from Klarna that the phone number is mis-formatted so I'll track that down now.
In the next release of the OPC, I'm going to just move that PHP definition into an admin-configurable setting; it'll make these "special" payment methods easier to deal with.

lat9:

In the next release of the OPC, I'm going to just move that PHP definition into an admin-configurable setting; it'll make these "special" payment methods easier to deal with.

There's always something. :smile:

Once I get this working, I'll confirm if there are any other issues or if this was all that's needed.