Contrib.social

List offsite payment gateways that support stored payment methods directly, not grouped by payment type

Open on Drupal.org →
Created on 18 November 2021, over 2 years ago
Updated 27 June 2024, about 17 hours ago

Problem/Motivation

I think I understand why this approach exist for onsite payment gateways, as they possibly need to behave differently depending on the payment type if they support multiple. But it's often making it weird to customize things, because you don't see the configured display label.

But for offsite gateways, that is not actually required, because they will need to manually create the payment method on returning/notify themself anyway. So they easily can support multiple payment types and based on whatever the remote site returns, just create the appropriate one.

Another difference for offsite gateways is that they often support a mix of payment gateways and many have configuration options which should be enabled per gateway. So you might have credit cards, for which they can provide a token, but then also support bank payments and services that don't support tokens. But the stored payment method interface is statically defined in code, so you can not decide per gateway entity if it should be reusable or not, leading to very confusing output.

Proposed resolution

I'm not sure if this is an acceptable change for BC in commerce 2.x, so just creating this issue now to clarify that.

Basically, assuming you have an offsite payment gateway that supports stored payment methods, and you have one entity configured with the label "X" supporting credit cards, then the displayed label on HEAD is:

* Credit card

With this change, it would be:

* X

(and the option identifier would also change, which has a chance to break custom form alters. And for this change, the custom display label is likely also Credit card, so nothing would change visually)

If you add a second one, "Y" that supports bank payments or so, then on HEAD, you get:

* Credit card (X)
* Credit card (Y)

And with the proposed change, it would be:

* X
* Y

Related issues

📌 Add checkout settings for payment method behavior Needs review might overlap a bit with this, depending on how that's handled exactly, didn't look at it yet. #2987905: The order in which the "Payment gateways" are listed in the order form is not the same as in the administration panel. → is about a consistent sort order that respects what you have in the backend and doesn't put gateways that support stored methods first. The patch for this will definitely conflict with that.

📌 Task
Status

Needs review

Version

3.0

Component

Payment

Created by

🇨🇭Switzerland Berdir Switzerland

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 5 months ago →
    🇫🇷France solene_ggd

    I wanted to use this patch to get multiple Paypal options (offsite payments) with the right display label. But when I set one of my Paypal options as default payment method with the #13 patch installed, I get this error :

    Drupal\Core\Entity\EntityStorageException : Missing bundle for entity type commerce_payment_method dans Drupal\Core\Entity\ContentEntityStorageBase->doCreate() (ligne 125 de /app/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).

    This is because the payment method type id is not set in the option with the patch, but it is required by buildPaymentMethodForm() method called to construct the default payment option in PaymentInformation class.
    I think this is what @DamienMo wanted to patch in his comment but I don't think he did it the right way.
    I think the condition on offsite gateway should not be on the first condition to build the option but on the one inside that checks if there are multiple methods. This solution allows to keep the payment method type id in the option.

    And to get the payment gateway display label as option label, I change the default call of createLabel.

  • Status changed to Needs review 5 months ago
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 5 months ago
    786 pass, 1 fail
  • Comment 5 months ago →
    🇫🇷France solene_ggd
  • Comment 5 months ago →
    System Message
  • Comment 5 months ago →
    🇫🇷France solene_ggd

    My bad, I did not think my patch could affect on site payment methods. Here is a new patch that should pass tests.

  • Status changed to Needs review 5 months ago
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 5 months ago
    789 pass
  • Comment 5 months ago →
    🇫🇷France solene_ggd
  • Comment 4 months ago →
    vaidas_a

    I tested with commerce 2.38. Patch applied successfully and PayPal payment method label appeared as it should (e.g. 'Pay with PayPal'). Yet, if I proceed with payment, cancel it I'm returned to the order information page with payment method just 'PayPal' instead of the label (behaviour the same as without the patch).

    It just a heads up, I didn't test with 3.x and clean setup.

  • Comment 3 months ago →
    🇫🇷France solene_ggd

    Hello @vaidas_a,

    If you want to see your display label instead of just "Paypal" when you go back, you need to install this patch in addition (on drupal/commerce_paypal module) : https://www.drupal.org/project/commerce_paypal/issues/3420132#comment-15... 🐛 Use payment gateway label instead of Paypal by default Active

  • Comment 3 months ago →
    CRZDEV

    #24 Worked for us using webform commerce order + commerce paypal, thanks!
    +1 for RTBC

  • Comment 25 days ago →
    🇮🇹Italy trickfun

    Patch #24 works fine.
    Thank you

  • Comment about 17 hours ago →
    🇺🇸United States rszrama

    I think this may need to be tested against payment gateway integrations like the Stripe Payment Element. They are technically implemented as offsite payment gateways even though all payment occurs on site. I haven't applied this patch to review the before / after, but I wonder if that use case was considered when this patch was written.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024