Contrib.social

Allow the checkout flow to determine it's payment information pane

Open on Drupal.org →
Created on 4 June 2020, about 5 years ago
Updated 16 July 2025, 11 days ago

Problem/Motivation

Currently the payment pane for checkout is hardcoded to the 'payment_information' plugin in the PaymentProcess pane
to determine if the payment pane is visible and if payment should be processed. This has caused issues when contrib modules or sites have wanted to make significant changes to, or have multiple different versions of payment panes as seen in #2861039: PaymentProcess::isVisible() makes it hard to use an alternative payment gateway selection gateway → , #2982269: Allow creating custom payment_information panes → , #3023373: Overriding PaymentInformation pane kill the payment process → , and #3115045: PaymentProcess is hidden if disable Pane(payment_information) and not working with own Pane Logic → with #2866429: Document how to safely replace checkout panes, especially payment ones → documenting the currently supported approach of using hook_commerce_checkout_pane_info_alter

* Provides the payment information pane.
*
* Disabling this pane will automatically disable the payment process pane,
* since they are always used together. Developers subclassing this pane
* should use hook_commerce_checkout_pane_info_alter(array &$panes) to
* point $panes['payment_information']['class'] to the new child class.

This approach has some issues though. In my use case I have multiple checkout flows and several have highly customized display of payment information or available payment methods which is only really possible by writing a new PaymentInformation pane. The important part is that ultimately all the custom panes are still compatible with PaymentProcess. The issue with using the documented approach is that the hook in CheckoutPaneManager caches the first requests result and never runs it again. For me that means a custom payment pane showing up in all checkout flows when it should only show up in 1.

While all the other issues for this have been closed as won't fix, I still feel there is an argument to be made for allowing this to be more flexible. If developers are skilled enough to write their own payment information pane then they should be trusted to also maintain compatibility with PaymentProcess or to know they also need to implement their own version of that pane.

Proposed resolution

I see several solutions that allow for the same level of control and assurances that PaymentProcess depends on

  1. Allow the checkout flow itself to define or determine which pane is the payment pane. This would introduce a new `getPaymentPanePluginId` method on the CheckoutFlowWithPanesInterface that returns the payment information pane id for the flow. The method would then be called by PaymentProcess to run it's checks. The simplest implementation of this simply has DC returning the string 'payment_information' for all flows extending CheckoutFlowWithPanesBase.
  2. A more complex implementation of #1 in DC could find the payment information pane for a flow by introducing an interface along the lines of ImplementsPaymentInformationPane to assure PaymentProcess that a configured pane is supposed to work the same as the default core one does.
  3. Alternatively the logic from #2 could be baked into the PaymentProcess pane itself. A method could be introduced on PaymentProcess to determine the payment information pane and if none are found simply hide itself as it currently does when it doesn't find a pane with id `payment_information`
✨ Feature request
Status

Needs work

Version

2.0

Component

Checkout

Created by

🇺🇸United States ctrladel North Carolina, USA

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 11 days ago →
    🇺🇸United States ericjenkins

    Re-rolled 3145982-2.patch for Commerce Core 3.1.0 compatibility: 3145982-7.patch →

    Re-roll diff: reroll_diff_2-7.txt →

  • Comment 11 days ago →
    🇮🇱Israel jsacksick

    Just closed ✨ Allow the PaymentProcess pane to work even without PaymentInformation Active as a duplicate.

    Several comments / thoughts:

    1. Regarding the getErrorStepId() method, perhaps we could simply fallback to the previous step ID in case the payment information pane is missing?
    2. Regarding isVisible(), well maybe we should not tie the visibility logic to the presence of the payment information pane? If the payment process pane is added to the checkout flow, then perhaps we can/should assume that a payment should be processed? If no payment should be processed, then I think the right thing to do would be to remove the pane from the checkout flow?
    3. One option that wasn't considered either could be to make this configurable via a setting that would default to "payment_information"? Though this is likely not something that makes sense to be exposed in the UI.
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024