One-Page Checkout: Interoperability Guidelines

One-Page Checkout is approaching its one-year birthday! I've seen OPC successfully integrate with various shipping, payment and order-total modules ... but the list could be larger, especially in the payment-module realm.

The primary interoperability issue between *OPC *(or any checkout-page "consolidator") and a payment-module centers on the collective javascript/jQuery implementation. Newer payment-processors' APIs have become more complicated, resulting in additional jQuery/AJAX constructs within the associated Zen Cart payment-module.

That issue arises when the checkout-page and the payment-module bind to the same DOM event, whether it's the submission of the form or a click of a submit-button. The net result is that some jQuery fragment is not run which, in turn, causes the page/payment-module integration to fail (i.e. orders cannot be placed).

I'd like to propose a set of guidelines used by both the checkout-page consolidators (like One-Page Checkout) and the various payment-modules, identifying which selectors each class of module binds to. This will serve to reduce those jQuery event conflicts and lessen the integration headaches for payment-module developers.

THE PAGE ELEMENTS

There are four (4) elements on the "normal" checkout_payment page that have bearing on the page's form's submissions:

1. The form itself, named checkout_payment.
2. The form's submit button.
3. The form's (optional) credit-class module, e.g. coupons, vouchers, or reward-points, submit buttons.
4. A global javascript/jQuery variable named "submitter". This variable is set by the page to identify whether (0) or not (1) the form's submission requires a payment-module's intervention.

The "submitter" value is set to 1 by the checkout-page consolidator when:

1. The order's total value is 0.
2. A credit-class module's submit-button was clicked.
3. A gift-certificate has been applied to the order and its associated value "covers" the cost of the order.

THE GUIDELINES

A checkout-page consolidator:

1. Does not bind to the checkout_payment form's submission.
2. Either binds to the press of the "Enter" key as an alternate form-submission method or disables the "Enter" key's default form-action.
3. Binds to the click of the form's submit-button and, if present, any credit-class modules' submit-buttons.
4. Sets the value of "submitter" based on the conditions stated above.
5. Performs a javascript/jQuery form-submission if no non-payment-related issues with the order are found.

A payment-module:

1. Binds ONLY to the checkout_payment form's submission, performing its specific processing if the value of "submitter" is 0 AND the payment-module is currently selected.

I'll appreciate any/all comments regarding these guidelines. Once consensus has been reached, I'll make the necessary changes to One-Page Checkout to effect those changes and, hopefully, pull additional payment modules into its realm of interoperability!

Thank you for the update ....