Release 2.0-RC1

Since we're discussing payment gateways, I'll mention here that I have written a gateway module for PromisePay (https://promisepay.com/) which should be of interest for marketplace projects. Its won't ready for d.o for a while, and because PromisePay is uniquely configurable on the backend (custom transaction workflows, seller payout management, user, company, item instances on the PromisePay system that are matched by uuid to entities on the drupal side, webhooks to get state changes pushed from PromisePay to the app... ) my implementation is split into two modules: 1) the Gateway module commerce_promisepay which is similar to commerce_braintree, using promisepay.js for secure transport, and 2) a promisepay_implementation module. The two are connected by hooks that are invoked e.g. in Drupal\commerce_promisepay\Plugin\Commerce\PaymentGateway\Onsite::createPayment in order to offload the business logic, and by the implementation module using the PromisePay API provided by the main module. The implementation module I will turn into an example submodule of commerce_promisepay at some point.

If anyone is interested in looking at or playing with this, let me know and I'll share.

@ransomweaver
please, post the link to your repo.

I have a drupalcommerce 7.x custom module written for https://every-pay.com/ and need to explore all the possible ways how to port it drupalcommerce 8.x-2.x.

What about availability handling / stock management of products, I don't see it listed here - should it be? Will it be part of Commerce core or a contrib?

In the payment gateway document, https://www.drupal.org/project/commerce_paytrail will be the successor of https://www.drupal.org/project/commerce_suomenverkkomaksut, "Suomen Verkkomaksut" is called Paytrail these days. The commerce_paytrail already has an alpha version for Commerce 2 thanks to @tuutti and will be used in a production site in a month or so.

Hi Bojanz,

Can you add https://www.drupal.org/project/commerce_migs_merchant to the payment gateway spreadsheet?

Thanks,

@drugan, Here is my commerce_promisepay module. I used my implementation module as an example submodule which demonstrates how to plugin custom business logic.

https://bitbucket.org/ransomweaver/commerce_promisepay

Commerce promisepay is now a sandbox project: https://www.drupal.org/sandbox/ransomweaver/2846772

I am porting Commerce Alipay to D8, but waiting to get that project owner role #2843825: Transfer ownership of Commerce Alipay module

I also added Commerce WeChat Pay on D8 https://www.drupal.org/project/commerce_wechat_pay

There is now initial D8 port of Commerce PAYONE module as a sandbox project supporting online credit cards payments: https://www.drupal.org/sandbox/mitrpaka/2849906

Is the ETA end of February or beginning of March still realistic?

There are dev releases for payumoney https://www.drupal.org/project/commerce_payumoney and ccavenue https://www.drupal.org/project/commerce_ccavenue.

Offsite payments for Estonia: https://www.drupal.org/project/commerce_banklink

In this first version we have the main Estonian banklink payment gateways covered. In a later release, we'll be providing a generic gateway option that will allow for configuring most iPizza banklink payments.

It might be a better idea to implement https://github.com/thephpleague/omnipay some how and solve a ton of these payment processors with a single module.

Not sure what the thoughts are.

Taxes were merged. Updating target month as communicated at DrupalCon Baltimore.

I strongly believe that #2827721: AddToCartForm should support all purchasable entities should be a blocker for rc1. The rather harmless title of that issue hides the fact that there's currently a huge problem with Views integration that is also part of the proposed solution there. On some views (maybe it's dependent on whether or not BigPipe serves it?) the wrong products are added to cart on clicking the button, as on form submission the order of the items (and hence the static counter) is exactly reversed to its original order.

I've never tried any patch from the mentioned issue, as I was simply lacking time for that. Instead, I reverted the form ID generation to the state of its last modification, similar to what the proposed patch in #2880939: Wrong product added to the cart does.

Imho it could cause some understandable bad reactions on the release candidate, if many users encounter that problem. Another argument for having this solved before rc1 is the fact that the form ID generation needs to be changed. There seems to be no way around that. This could also lead to some necessary code adoptions in custom code, if you implement hook_form_alter or hook_form_FORM_ID_alter. This suits better into beta stage as well

Subscribing

@Christophe Bourgois you can follow the issue by clicking on the 'Follow' button just below the issue metadata at the top of the page. See https://www.drupal.org/node/1306444 for details.

Are #2876963: Apply consistent BEM class naming and #2877358: Prefix classes needed for JS functionality with 'js-' a requirement for a RC1? @bojanz as of our conversiation on Slack they are.

List of available payment gateways for commerce 2.x : https://docs.google.com/spreadsheets/d/1efOOTDFqweCkAnPkIElEbx4yavXoVZjV... Courtesy of @bojanz

Regarding #27: PayPlug module can be marked as Ludwig compatible now with version 1.1

Amazing RC-1
Exciting!

Authorize.net and Square has updated beta1's for RC1 changes.