Add iDEAL & Wero Payment Method Type

Thank you for this great patch.

I get the following error message:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxxx.commerce_payment__client_secret' doesn't exist:

Can you please tell me the structure of the database table commerce_payment__client_secret?
Is this an additional table you created manually?

Entities have to be updated to get the table commerce_payment__client_secret created:

drush entity-updates

Hello,

Thank you for this patch, it will help me a lot.

I just had to add a line and a parameter in StripeIdeal.php :

Line 17 : use Drupal\Component\Datetime\TimeInterface;
Line 37 : public function __construct(array $configuration, ... , TimeInterface $time)
Line 38 : parent::__construct($configuration, ... , $time);

Because the parent class needed 7 arguments and they were only 6 in your class.

I just did a rapid test : I copied all the files and replaced all the "iDeal" with "Bancontact" and it worked (I was sent to https://bcr.girogate.de and then my bank page to confirm).

Thanks again !

So, it would probably be easier to maintain (and to avoid code duplication) if we group the common base of those payment methods (the push/synchronous/redirect part from https://stripe.com/docs/sources) ?

But there are small differences between all those sources payment methods from stripe.

It is much better to have separated code for each sources payment method to stay flexible.

So, here is the patch with the 3 payment methods : iDeal, Bancontact and Giropay.
As suggested by drupalfan2, they have no common file, except commerce_stripe.routing.yml

For now, I just applied the modification in #8 and modified the label from "iDeal through Stripe" to "Stripe : iDeal". So, all the Stripe payment methods stays grouped on the "Add payment gateway" form.

(I hope that it's the right way to post patch as I never did it before ...)

We also need a patch for SOFORT Banking through Stripe sources. This should be added too.
SOFORT is one of the most important payment method in Europe (about 13 countries).

I have already made a test a few weeks ago and it worked with minimal adjustments to the ideal patch.
One difference is that the real payment is not really completed after a successful payment through the customer (the money will be transferred whithin few days after payment).
But the Shop needs a "payed or successful" status otherwise the payment can not be closed without error message to the customer. Only some lines of code have to be changed - but maybe there are different ways to implement this.

SOFORT banking (Klarna) through Stripe is still needed.

Noticed that status message has been changed... I have updated the patch.

Reviewing this issue and its patches.

I agree with #14. Bloating and stacking this patch with other sources will cause this issue to languish. Any patch after #5 should be disregarded, as there are problems to sort out with that implementation, and further patches just copy and paste the solution.

1. +++ b/commerce_stripe.routing.yml
   @@ -0,0 +1,13 @@
   +commerce_stripe.checkout.ideal_return:
   +  path: '/checkout/{commerce_order}/return_stripe_ideal/{commerce_payment}'
   +  defaults:
   +    _controller: '\Drupal\commerce_stripe\Controller\StripeIdealPaymentController::returnCheckoutPage'
   +  requirements:
   +    _custom_access: '\Drupal\commerce_checkout\Controller\CheckoutController::checkAccess'
   +    _module_dependencies: commerce_checkout
   +  options:
   +    parameters:
   +      commerce_order:
   +        type: entity:commerce_order
   +      commerce_payment:
   +        type: entity:commerce_payment
   

   I'm failing to understand why we need this custom controller over the onReturn page provided by the payment gateway.

   Is it because we need the additional parameters? But we don't need the parameters if it went straight to the proper route.

2. +++ b/src/Plugin/Commerce/PaymentType/PaymentIdeal.php
   @@ -0,0 +1,32 @@
   +    $fields['client_secret'] = BundleFieldDefinition::create('string')
   +      ->setLabel(t('Client Secret'))
   +      ->setDescription(t('The client secret used to verify this payment with Stripe'))
   +      ->setRequired(TRUE);
   

   Do we really need a new payment type? Is there a way we could just make the secret be part of the remote ID?

   In Square the remote_id for a transaction is two components, concatenated on "|". Could we do the same here?

   remote_id = secret|stripe_remote_id

I've got iDEAL payments added to my Stripe account and will be reviewing this issue.

Regarding #5, I had to add the $time parameter at the end of the StripeIdeal __construct class

class StripeIdeal extends OffsitePaymentGatewayBase {

  /**
   * {@inheritdoc}
   */
    public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityTypeManagerInterface $entity_type_manager, PaymentTypeManager $payment_type_manager, PaymentMethodTypeManager $payment_method_type_manager, TimeInterface $time) {
      parent::__construct($configuration, $plugin_id, $plugin_definition, $entity_type_manager, $payment_type_manager, $payment_method_type_manager, $time);

Should this be updated in the patch?

I have teste #15 (in which #19 is implemented) for bancontact and I got the following error at the last step of the checkout:

Drupal\Core\Database\DatabaseExceptionWrapper: 
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'mymoduledb.commerce_payment__client_secret' doesn't exist: 
SELECT t.*
FROM
{commerce_payment__client_secret} t
WHERE (entity_id IN (:db_condition_placeholder_0)) AND (deleted = :db_condition_placeholder_1) AND (langcode IN (:db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4))
ORDER BY delta ASC; Array
(
    [:db_condition_placeholder_0] => 15
    [:db_condition_placeholder_1] => 0
    [:db_condition_placeholder_2] => fr

    [:db_condition_placeholder_3] => und
    [:db_condition_placeholder_4] => zxx
)

 in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromDedicatedTables() (line 1266 of /var/www/html/drupal8/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

same problem with #5
I assume we need to extend the PaymentInterface as I can see (in the patches) calls like:
$payment->setClientSecret()
or
$payment->set('client_secret', $source['client_secret']);

Looks like we can close this issue as the last dev version include those new paiement gateway.

There hasn't been a commit here.

@bojanz: you are right, but after upadting the module, I can use bancontact, Ideal,...

The patch on comment 18 (from 2018) uses the Stripe Sources API, but Stripe deprecated that API several years ago. Stripe currently recommends using the Payment Intents and Payment Methods APIs instead. If I understand correctly from #3408951: Refactor Stripe payment element for additional payment method types, the path forward for iDEAL support is to implement a CommercePaymentMethodType plugin. Based on that, I updated this issue's title and summary.

(Also update this issue's target version.)

iDEAL will become "Wero" soon (see https://ideal.nl/en/naar-wero). So I'd say we should wait until Wero leaves the preview phase in stripe and then implement that instead (see https://docs.stripe.com/payments/wero).

Also, we should see how Stripe will integrate Wero, they might leave the old iDEAL integration. In that case we should think about whether we should use the new iDEAL / Wero logo, see https://ideal.nl/en/ideal-wero-branding for iDEAL and also implement Wero separately.

Although IMO we should just wait until iDEAL completely turns into Wero and then integrate this payment method type.

iDEAL now IS wero and should be supported. We just ran into a case where iDEAL was enabled on the Stripe side, but is not supported in the module:

Drupal\commerce_payment\Exception\PaymentGatewayException: The selected stripe payment method type(stripe_ideal) is not currently supported

which lead to an unprocessed order (stuck in cart) that was still PAID on the stripe side!

IMHO that should get resolved, and unsupported payment method types should not leave orders vs. payments in such a state? I'll create a dedicated issue for that.

See the Stripe UI: It's a combined logo now!