Contrib.social

Separate stored payment methods from new in the Payment Checkout Pane

Open on Drupal.org →
Created on 23 November 2020, about 4 years ago
Updated 28 August 2024, 4 months ago

Problem/Motivation

When choosing a payment method it should be clear which is an existing payment method and which is adding a new method.

Steps to reproduce

For an example of going back to edit the payment information after previously selecting a payment method see:

Proposed resolution

The payment options list should be grouped into saved and new methods.
The should be an action to "initiate" adding a new payment method if a saved payment method is pre-selected.

See Amazon for an example of how this can work

Remaining tasks

Most tasks can be extracted from the patch in ✨ Allow a store to always collect a billing address before payment method selection Needs work

Split PaymentOptionsBuild to be able to getStoredOptions and getNewOptions
Split the Payment Options list on the Payment Information pane
Allow the

User interface changes

This will change the checkout UI which could affect the CSS styling of the form - however reviewing the target classes that are used these should stay the same, even though there will now be two radio lists.

API changes

PaymentOptionsBuilder::getOptions should be kept for backwards compatibility

Data model changes

None

✨ Feature request
Status

Needs work

Version

3.0

Component

Payment

Created by

🇬🇧United Kingdom dwkitchen London

Live updates comments and jobs are added and updated live.
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 4 months ago →
    🇮🇱Israel jsacksick

    Now that the 3.0.0 release is approaching, I'm having second thoughts about this change. The "Add payment method" label doesn't make sense in the case there is no payment gateway implementing the SupportsCreatingPaymentMethodsInterface.

  • Comment 4 months ago →
    🇳🇴Norway zaporylie

    Re #21 I think it's SupportsStoredPaymentMethodsInterface. that is a problem not SupportsCreatingPaymentMethodsInterface

    Offsite gateways may implement the former without implementing the latter. Onsite gateways always implement SupportsCreatingPaymentMethodsInterface therefore it also implement SupportsStoredPaymentMethodsInterface

  • Status changed to Needs work 4 months ago
  • Comment 4 months ago →
    🇮🇱Israel jsacksick

    I reverted this today... So marking this as needs work considering 🐛 Payment Information fieldset label is misleading if mix of gateways supporting and not supporting stored payment methods is available Active and other inconsistencies found.
    After discussing this further internally, I now believe we should attempt to provide a better alternate UX via an alternate pane or something... Or a behavior you can toggle within the existing pane via settings. This would be a less disruptive change and would allow people to optin/optout of this change....

  • Comment 4 months ago →
    🇳🇴Norway zaporylie

    Rather than opt-in or -out as a part of pane plugin definition I think it would be beneficial for the codebase upgrading efforts (strong typing, etc) if we could provide an alternative plugin class, compatible in behavior (ie. pane form submission result) with the current one. The new plugin class could be swapped via hook_commerce_checkout_pane_info_alter. In that scenario, the site-wide checkout.settings config could control which class to use for the Payment Information checkout pane plugin. The old class would throw deprecation error as mentioned in https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... → . The old class would be the default for existing sites, and the class with a modernized UI used by default on new Commerce installations. During Commerce 3.x lifecycle one can change the plugin class back and forth and old, legacy class as well as the option to change it will be removed in the 4.x

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024