Commerce Marketplace payments

Previous version of my Commerce Marketplace module (not to be confused with farhadhf's module of the same name) stopped just short of supporting payments during the checkout process.

You can read more on what the previous version had to offer in From Commerce Store to Commerce Marketplace, my previous blog post in the Commerce Marketplace series.

This has changed now, after my recent commit pushed to d.o.

Parallel payments support

The biggest step forward since my previous blog post mentioned above was adding initial support for parallel payments.

What are those?

The differences between simple, parallel and chained payments are nicely explained by Paypal's introduction to Adaptive Payments.

In short, parallel payments enable a sender to send a single payment to multiple receivers in a single request. What is important about this concept is that a sender needs to enter their credit card details (or any other details they need to provide) only once, regardless of how many payments are really being made, which hugely improves user experience and makes customer's life much easier.

Now, current version of Commerce Marketplace takes the first step in supporting parallel payments. It provides the Parallel Payment Method Example module, which generally is a copy of Commerce's Payment Method Example, but defined as parallel using 'parallel' => TRUE in payment method definition.

It also provides new checkout page - Review orders, and new checkout panes - Marketplace: Review, Marketplace: Payment and Marketplace: Off-site payment redirect - to be able to support processing multiple orders during one checkout process. (This actually was already described and illustrated in previous blog post in the Checkout pages and panes section.)

Using either parallel or chained payment methods might change the default flow of the checkout process.

Let's imagine a situation in which we are ordering 3 products from 3 different stores, which means entering the checkout with 3 orders belonging to 1 order group. What might happen:

• if all stores for current order group support the same parallel payment method(s):

  • only these common parallel payment method(s) will be offered to the customer during the checkout process (which means no non-parallel payment methods will be offered)
  • the Shipping pane will be displayed only once, on its dedicated Shipping checkout page (standard in DC)
  • the Payment pane will be displayed only once, on the Review order checkout page (standard in DC)
  • Review orders checkout page will not be displayed at all

• in any other case, when there are no common parallel payment methods for all stores for the current order group:

  • all payment methods enabled for a specific store will be offered to the customer
  • both Shipping and Payment panes will be displayed multiple times, once for each order (for each store), on new Reviews order checkout page
  • Shipping checkout page will not be displayed at all

Again - all that is done automatically, no manual configuration of which pane is displayed on which page is required.

Chained payments - no support yet

Besides the Parallel Payment Method Example module there also was another one added here - Chained Payment Method Example, even though chained payment methods are not supported yet. Adding this however will be almost identical to parallel payment methods support, and I am leaving this until the parallel support is finished and works fine.

Other minor changes

• correct usage of store payment method configuration when sending a payment directly to merchants instead of default one (previously it hasn't been fully implemented yet)

• option for admin to choose whether payments should be sent to the main store (marketplace owner, using default payment method configuration saved in rules settings - default behaviour of Drupal Commerce) or directly to merchants (using payment method configurations defined by merchants for their stores)

• improved cart and checkout routing

• improved handling of empty orders (orders from which all product line items were removed)

• initial support for products and orders not assigned to any merchant store

• configuration option to split shopping cart content view on Review pane

What's still on the to do list

These task might be divided into 2 groups - those that I would like to have done before moving the module out of its sandbox status and promoting it to the full project (even if still in dev version), and those which might wait a little bit longer, but still would like to mark them as completed before first stable release.

So, what keeps the module from leaving my sandbox and going full project:

• Finish checkout process

  Even though the most important checkout stage - payments - is now (almost) completed, the full checkout process still needs to be worked on, as the last checkout page - Checkout complete - displays information only for a single, just completed order.

• Finish support for parallel payment methods

  All orders in the current order group have to be processed on each step of the checkout process. AFAICT this is almost the case right now, except the very last step, which is the confirmation page, which still displays message relevant only to the order ID from the URL.

• Support for chained payment methods

  While the current version initially supports parallel payment methods, it does not support chained payment methods yet. This however is pretty easy to add, as the logic behind it will be the same as in case of parallel methods. I am planning on adding this once the parallel support is completed and working well.

• "Repeating" checkout pages

  Talking about repeating pages I mean pages on which all panes should be displayed as many times as there are orders in the current order group.

  To illustrate this with an example - let's imagine a customer ordering from 3 different stores, which do not have any common parallel payment method - this means that such a customer would need to make 3 separate payment transactions for each of those orders. In this situation the Payment pane needs to be displayed 3 times - once for each of those orders.

  The same applies to the Shipping pane, regardless of whether there is a common parallel payment method or not - as shipping costs (which in reality translates to available shipping methods) are based on total amount of each order, therefore the Shipping pane should be displayed 3 times as well, for each order separately, to offer only those shipping methods which are relevant to those specific orders.

  This is best illustrated by screenshots of the Review orders checkout page in my previous post on the subject, on which you can see that all 3 panes on the Reviews order page (Shopping cart contents, Shipping and Payment) are displayed twice, for each order (each store) separately.

  I have started playing with ideas here a bit already, and so far came with something like on the screenshot below, not sure yet though it will be the final version:

  

• Shipping methods configuration by store

  This was requested in the module issue queue, and makes perfect sense - if we are giving store owners control over payment methods and their configuration, we should do the same for shipping methods as well. I haven't really given it any thought yet, and so far don't have any good idea how this could be done in a nice and flexible way, so I'm open to all ideas here - please comment in the issue.

  I guess that would need to be something around being able to create and edit own custom rules being a non-admin/1 user, pretty similar to what granting the Administer rule configurations permission gives, but a little more restricted (without access to general rules settings etc). Thoughts?

• *Re-think current implementation of automatically moving checkout panes

  As mentioned earlier, currently shipping- and payment-related checkout panes are being automatically enabled/disabled and moved around between different checkout pages based on number of stores a customer orders from and their enabled payment methods.

  To be honest, although it seems to work fine so far, I don't quite like this solution, as it decreases flexibility and configurability of the checkout process (it also could cause confusion for those who would want to re-arrange checkout pages and panes themselves - see this issue for an example). I'm not sure about its achievability, but I would like to try to find a better solution here.

• Don't base pane behaviours on the checkout page they are being displayed on

  Also, because of the fact, that checkout panes are being move automatically between pages, some of their behaviours are based on the checkout page they are currently being displayed on - which I don't like too much either. Another element to re-think and re-implement in a smarter way.

• Testing, testing, and even more testing

  Also, have I mentioned testing?

  • In all possible scenarios - as so far I am using almost the same flow each time when developing a new feature.
  • As all possible roles (including anonymous users) - as most of the time I am logged in as admin user/1, which does not test access permissions very well.
  • With other commerce-related modules - at least those more popular ones, and not only other payment methods (for example with Commerce Stock etc).

Not that bad, eh?

Well, at least that's all that popped to my mind so far. There might be more. And most probably will be.

Now, these are the things that I would like to have done before first stable release:

• Introduce concept of store co-administrators

  At the moment each store has exactly one administrator - a user which is assigned as Store owner when creating the store entity. Such user has permissions to edit and delete the store, and has full access to product and order management for this store.

  A very nice feature would be an option to be able to create additional store co-administrators, who will have access to all or some of those store-related settings based on Drupal permissions. For the moment this is just an idea, not started on in any way yet.

• Develop a real-life parallel payment method

  Just to have something real to work with and test with. I guess the very first one should probably be PayPal adaptive payments, providing its own version of both parallel and chained payment methods.

  This is on the very end of my to do list at the moment, so if anyone feels like taking up the challenge, I'd be more than happy to see that happen!

  (Plot twist: don't PayPal's adaptive payments (or parallel payment at least) allow only up to 6 receivers in one transaction?)

Any thoughts, questions, ideas? AMA in the issue queue!

Why it all moves so slowly?

Time, time and time again. Or lack of thereof.

It all happens during my R&D time - which is great when I have it, not so much when there is other client-related work. Money = top priority. Life.

Best solution here? Have a client looking for a site with marketplace functionality, who will sponsor module further development, and taking it to the finish line.

Know of one? Let me know! Or contact Commerce Guys directly.

How can you help?

All kinds of contributions are highly welcomed:

• Code - I have pushed the module code to GitHub, as it is much better playground for developers compared to drupal.org - if you want to help developing the code yourself, feel free to fork from there.

• Ideas - I am always open to new ideas and improvements. Have anything to discuss? Post to the module issue queue, find me on IRC, send me a message in any other way. All your input matters!

• Booze - you know it always helps. And I mean always. With everything. Gittip is the place here. Or Amazon. Or even PayPal. Do your worst.