This issue is for Commerce 2.x

The problem

Commerce does what almost every (webshop) module for Drupal has done at least once: it reinvents the wheel. This particular issue is about reinventing the wheel that processes payments for a Drupal site. In Drupal's history there have been four webshop modules and numerous other projects that (would like to) process payments. The projects that offer payment processing have their own custom platform. The maintainers of the projects that don't usually thought adding their own payment platform was too much work.

This is silly. Processing payments is done in the background for 90%. The other 10% is common, but might need some custom configuration. However, because of this 90% (Hey, Paypal will always be Paypal, whether you want Commerce or Ubercart users to use it to pay their bills), it makes sense to centralize payment handling in a separate module.

Payment

Please welcome Payment. I started this project when I realized I was about to reinvent some of the general payment handling features I had already built for iDEAL. Payment is designed to do one thing, and do it well: it processes payments. It is a hub to which both payment methods and contexts (modules that need payments to be processed) connect. Payment methods and contexts are pluggable and they do not know about the other, which ensures that any payment method works for any context and vice versa. The result? We only need one Paypal module in the entire Drupal world, or one module to link any payment method to Commerce.

Comparison to Pay

Payment is one of two general Payment platforms for Drupal. The other is Pay. Pay is older, but offers less built-in features, yet has more custom abstraction (not the "Drupal way") with less documentation. These are the reasons why I built Payment, rather than build on Pay. I talked to several Drupal developers in Munich and on IRC and it seems they share the same point of view.

Maintainer team-up

Commerce is not the only project that would benefit from using Payment. The maintainers of all four webshop modules (Commerce, Ubercart, E-Commerce, and Basic Cart) all expressed an interest in leveraging Payment. Instead of focusing on four different payment platforms, we can move towards focusing half the time on a single payment platform that works twice as well.

What needs to be done?

I talked to Ryan Szrama at DrupalCon Munich and he expressed his interest in Payment, but had a few concerns. Every use case he mentioned that Commerce Payment couldn't handle, can easily be handled by Payment. The only other major concern was maintainership: Commerce should not depend on a poorly maintained module. I will keep maintaining Payment for at least the foreseeable future. Also, if multiple projects start depending on it, there will be more than enough people to help with maintenance.

There are a few things Payment 1.x can't do and Commerce Payment 1.x can. However, development on version 2 is planned to start this year, which means that we can ensure moving from Commerce Payment 1.x to Payment 2.x will not be a regression by adding necessary functionality.

Why this issue?

Next month, a team of Commerce experts will meet in Paris to discuss the plans for Commerce 2.x. I made this issue to provide useful information to those involved in the process of deciding which modules Commerce 2.x should leverage.

Comments

rszrama’s picture

Priority: Major » Normal
Status: Active » Postponed

Marking this postponed until we get an actual 2.x-dev branch up to link it to; also linking the discussion into the "Open a 2.x branch" issue.

#1467180: Open 2.x Drupal Commerce branch

Xano’s picture

See the newly created Payment handbook for more information.

Xano’s picture

To get an image of the plans for Payment 7.x-2.x, see the postponed issues. Most of them are related to more powerful and consistent DX, or better integration with existing core and contributed modules.

Xano’s picture

I'd like to address a few more issues that people raised over the past weeks:
We need to know Payment will be well-maintained if we're going to depend on it.
This is absolutely true. As you can see I've been maintaining Payment for the past year and I intend to continue this work. If more people start using it, the project will receive more community feedback and patches, which supports maintenance. Also, if Commerce 2 will use Payment in favor of Commerce Payment, then Commerce Payment development time can be spent on Payment if necessary.

Separate projects are more agile
This is true. Splitting off modules that are not specific to Commerce, such as payment processing, currency information, shipping, etc, helps keep Commerce maintainable and allows more agile development. Because those modules are no longer Commerce-specific, people will start contributing to them from different perspectives, which can positively benefit those modules' feature sets. It will also help developers keep the API usable and abstract, because the assumption the code will be used for orders anyway no longer exists.

One e-commerce project to rule them all
Someone told me Commerce is meant to replace all existing e-commerce and payment processing platforms, and its reusable submodules contribute to that. Because of this, payment processing should not live in a separate project. I disagree, for two reasons:
1) At the moment Commerce cannot replace every existing project.
2) I highly doubt Commerce will ever be able to do that. What if someone just wants a simple "buy me a beer"-form, for instance? Commerce would be overkill.
The way I see it is there will always be other modules that in part need to do the same Commerce does. Keeping those 'common denominators' in separate projects allows people to more easily build those modules.

Why replicate line items on payments?
Compare this one to going grocery shopping: you take a shopping cart or basket and walk through the store. You put a handful of products in it and continue to the register (checkout). Your order is everything that is in your cart and lists what you bought, when you bought it and for how much per product. You take out your credit/debit/magic unicorn card and try to pay the €50 you owe the store. The first attempt fails, because you mistyped your pin. This is a payment. The second attempt to pay succeeds, but the cashier forgot to add one last product and you paid €10 less than you should have. The €40 you already paid, is the second payment. You then make a third and final payment for the remaining €10.
The first two payments have line items for all products, except the one the cashier forgot. The third payment has a line item for the product the cashier forgot initially. However, all three payments belong to the same order which lists all products together.
You leave the shop, go home, and check your transaction history with your bank. You see an extra €0.50 was added to every payment, because you had to pay a transaction fee for the card you used. These fees are not part of the order (in this case because the store had nothing to do with it), but you still paid it along with what you owed the store.
In short: order line items describe what products you bought in total. Payment line items describe what products you paid for.

Xano’s picture

Also, I've taken a look at the Commerce 2 roadmap and a lot (if not all) of the features that are to be added already exist in Payment, or can be added by reusing its existing code base.

sinasalek’s picture

That's a brilliant idea,
Payment module already supports to drupal commerce,
it would be great if drupal commerce maintainer could put a note on modules page
introducing the payment module and encouraging users to use it for implementing
payment gateways instead of drupal commercer's built-in payment API
Mentioning this in modules documentation can also be very helpful
because most people don't know that a generic payment API exists, and by the time they find out
they have already written their module
why waste time implementing the same gateway again and again for different api when there is already a solution available

zambrey’s picture

So, is it gonna happen?
I will need to implement a few Polish payment gateways, so I'm wondering if I should go directly with Payment module.
How is current integration with Commerce 1.x? Is it production ready?

sinasalek’s picture

As you can see in the module's page, the latest release is a stable release
http://drupal.org/project/payment_commerce

Xano’s picture

Hi @zambrey! Payment for Drupal Commerce is indeed stable. If you write plugins for Polish payment methods, they'll also be available to people using Ubercart or Webform too, which will widen your audience!

As for the integration with Commerce 8.x-2.x: The plans for Payment 8.x-2.x are being made. Version 2 will be a major rewrite in order to integrate with all the new things in Drupal 8. It will also get more payment-related features, such as built-in support for recurring payments and postponed capture.

Xano’s picture

A number of developers have expressed their interest in leveraging Payment instead of writing payment methods for Commerce directly. I will try to schedule a BoF during Drupalcon Portland where I can answer questions about Payment and Currency, and where future developments can be discussed, such as the port to Drupal 8 and adding missing features.

Xano’s picture

The BoF is scheduled for 14:00/2pm in room A103 this afternoon (Tuesday). We'll do some Q&A, and discuss implementations and future development.

Xano’s picture

Issue summary: View changes

.

rszrama’s picture

Version: 7.x-1.x-dev » 8.x-2.x-dev
Status: Postponed » Closed (won't fix)

I'm pretty sure this has been discussed and decided against. Can leave it to bojanz to reopen if necessary.