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:
- The form itself, named checkout_payment.
- The form's submit button.
- The form's (optional) credit-class module, e.g. coupons, vouchers, or reward-points, submit buttons.
- 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:
- The order's total value is 0.
- A credit-class module's submit-button was clicked.
- 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:
- Does not bind to the checkout_payment form's submission.
- Either binds to the press of the "Enter" key as an alternate form-submission method or disables the "Enter" key's default form-action.
- Binds to the click of the form's submit-button and, if present, any credit-class modules' submit-buttons.
- Sets the value of "submitter" based on the conditions stated above.
- Performs a javascript/jQuery form-submission if no non-payment-related issues with the order are found.
A payment-module:
- 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!
Bookmarks