Released: PadLoper (commercial eCommerce platform for ProcessWire)

[apeisa]

I have been spending some long evenings building PadLoper. It is my personal project to challenge myself as a developer, but also something I believe ProcessWire really misses: a solid eCommerce platform. 

I am happy to announce, that I am not very far away from public release, so I did create a little teaser site and email list for all of you that are interested: https://www.padloper.pw/

As many of you now, I also have bunch of eCommerce modules called "shop for processwire". Those remain open source modules, but I am not actively maintaining them (like I really haven't since 2012). All the code in PadLoper is new and it's totally build from ground up. If someone wants to maintain or develop shop for processwire further, I am more than happy for that.

There will be some open source components coming from PadLoper also: at least payment modules, but I might also open source the shopping cart module.

Padloper released 4th October, 2015: https://www.padloper.pw/

[3fingers]

Keep up the good work @apesia, I'm absolutely sure PadLoper will be the e-commerce solution of choice for everyone in here using Pw!

[MatthewSchenker]

Greetings,

Excellent news, and I look forward to being a PadLoper customer!

Currently, I use a combination of ProcessWire, FoxyCart, and Stripe (or Authorize.net) for most of my e-commerce projects. But I would much rather have a full ProcessWire solution (plus Stripe)!!

I'm curious -- can we be fully PCI compliant with PadLoper? Is the credit card information handed to Stripe through the whole process?

Keep up the great work!

Thanks,

Matthew

[remove]

Fantastic!

I hope iDeal payment is included.

[netcarver]

I believe it uses stripe's JS solution - so it should be PCI compliant.

[teppo]

Antti: are you planning to include tools needed for complying with the new EU tax legislation? Just checking, since you've included things like "downloadable products", which would probably benefit a lot from this

[einsteinsboi]

Subscribed to the list, looking forward to testing it

[pwired]

Almost everything is a page. Great, love that a lot !

Does it have "state" of order, e.g. in process, payed, send, closed, returned, denied, etc. ?

Does it have invoicing and print invoice to pdf ?

Paypal only works for the buyer, not for the seller, so

does it allow payments with simple banktransfers ?

Will the downloadable products have protected links ?

Will the module be low on resources ?

[apeisa]

I'm curious -- can we be fully PCI compliant with PadLoper? Is the credit card information handed to Stripe through the whole process?

It depends on what kind of payment gateway you use. If you don't have need for saving the credit card numbers in your service (for "one click checkout"), then there you don't have any need to collect credit card information in your service either. Both payment gateways that PadLoper will ship (Stripe and PayPal) asks for credit card information on their services, so using them makes your service PCI compliant (or to be exact - it removes the need from your service to be PCI compliant, since you are not handling credit card information at all).

Antti: are you planning to include tools needed for complying with the new EU tax legislation? Just checking, since you've included things like "downloadable products", which would probably benefit a lot from this

Yes - although not on the first release. I want to wait little and see how things are developing on that. I have a gut feeling that there are some more changes coming. The tax class system I have in place does already have possibility to define different taxes based on location (country & state supported). It seems that digital products was just beginning, EU will be rolling changes on all sales in upcoming years.

Almost everything is a page. Great, love that a lot !

Does it have "state" of order, e.g. in process, payed, send, closed, returned, denied, etc. ?

Does it have invoicing and print invoice to pdf ?

Paypal only works for the buyer, not for the seller, so

does it allow payments with simple banktransfers ?

Will the downloadable products have protected links ?

Will the module be low on resources ?

Regardind order states: I am currently wondering this one: I found most of those statuses confusing and something where the shop owner needs to define meaning. I am looking for more specific toggles, like:

 - order successful / failed

 - order delivered / not delivered

 - order paid / not paid

What causes me some problems are those custom situations like "returned", "cancelled" etc. I think those cases a little. Then there will be order notes also.

Yes, there will be invoicing and invoice pdf (or printable html - I'll have to see if I am allowed to bundle pdf libraries in this module).

Regarding bank transfers, not sure I understand? You can use invoice, where the payments go into your bank account - but PadLoper will not integrate with your bank.

Downloadable products will have protected links: each link is unique per product & order, and there can be "download rules" defined - like how long it's available and how many downloads are allowed. Downloading a file doesn't require login though.

PadLoper adds very little on top of the ProcessWire - so if PW runs ok on your server, then will PadLoper also.

[Joss]

For things like E-Books, logging in to download is helpful because of possible publishing restrictions. For instance, if the copyright prevents the file from being available on a publicly accessible link.

Additionally, for a shopper to be able to login and see a list of their purchased downloads, complete with links, then that is good too.

[apeisa]

There are cases where required logging in is beneficial. But I think that most often the simplicity of "click a link and download" is what one expects. This also leaves all the stress of creating and managing user accounts etc.

Orders are tied into user accounts, if buyer is logged in while creating the order. So one can create that kind of functionality if required. PadLoper won't offer it out of the box though.

[teppo]

Yes - although not on the first release. I want to wait little and see how things are developing on that. I have a gut feeling that there are some more changes coming. The tax class system I have in place does already have possibility to define different taxes based on location (country & state supported). It seems that digital products was just beginning, EU will be rolling changes on all sales in upcoming years.

Problem might be that anyone planning to pay their taxes properly (and sell digital products to EU) will need this by 1st of January. As long as there's a manual step involved (someone buys a digital product and I ship it, i.e. send it as an email attachment or something like that, manually) this is not a problem, but if the system automates this, the shop owner will have to consider EU tax legislation.

Minimum support would consist of logging two separate details about the users location, such as IP address (perhaps automatically converted to a location) and a separate question for location. If those don't match, there's a problem, but if they do, the shop owner knows where to pay taxes for that specific product.

You're right in that digital goods are only the first step. Unless, as I really (really really really) hope, they eventually realise that this whole legislation is an awful and broken idea..

[Nico Knoll]

I'm really really curious as I'm currently in the need of a shopping (or at least payment + cart + tax) module

[apeisa]

Teppo, most of the big players (others than Google and Apple) are not ready yet. Etsy, gumroad, you name it. This whole thing got everyone by surprise. I actually called to tax office here in Finland two months ago about PadLoper sales. The answer was, that as long as I sell under 8000€ a year, no need to pay taxes - it's enough to just tell about this income (and that way I pay huge side income tax). But my point is that even tax office didn't know about this 2 months ago.

The thing I'm most interested is how on earth EU believes they can even in theory collect taxes from single person from India who sells pdf book online?

For me it seems that micro businesses were just not considered while making these rules and there will be sooner or later new guidelines coming.

[Basil]

great news! can't wait to purchase!

[owzim]

great news! can't wait to purchase!

Ditto!

[apeisa]

I just send first newsletter out with some badly cropped screens: http://eepurl.com/bagVe9

[creativejay]

Hello apeisa, I'm very excited to see that you are developing this module!

I've been holding off on adding a cart to a website because of the intricacies of the way my client wants it to work. I see you support variations in PadLoper, and I wondered if I could run a scenario by you to see if your variations will be ... varied.. enough?

My client makes doll figures to order and there are many options for each one: the color resin it is cast in (which may add to the cost), and optional parts that can be interchanged for either no additional charge or added on for a fee per option. In a single doll order there may be 6 or more options she'll need the customer to select. I might be able to minimize this by one if I separate out the options into separate products, but it would not fit with the way customers are used to shopping for these items if each possible combination has to be a different product.

Hopefully you have good news for me on that angle!

In other, less hopeful news, my client also accepts layaway payments for her orders. Usually there is a % deposit, and then the customer makes payments until it is paid off. I don't suspect there is anything you have currently planned that will allow for the customer to come back to manage their layaway payments, but I figured I'd mention it. I saw you have invoicing built in, I wonder if the invoice amount can be edited by the shopkeeper, to invoice for partial payments, multiple times?

I'm feeling really hopeful about PadLoper, thanks again!

[apeisa]

Hi Jay and thanks for the interest. What you are describing is not something I would recommend doing by using PadLoper product variations. In PadLoper each variation requires page id, so you can build variations using pages, repeaters or PageTable. That allows each product variation have their own unique price and stock.

What you are after are more like perks or modifiers. Like additional services or modifications on product - which either increase or decrease the price and they don't have stock of their own. I have been thinking about that concept and will add those at some point, but you won't find them from first release. Although I am planning good hooks to make it possible to add things like that pretty easily with little custom coding per site.

[Nico Knoll]

I would solve this with kind of child-products. So you have one base product + 5 child products/customizations for example which have there own price and get added to the invoice as separat products.

I'm going to need something similar as I'm working on a "customized skateboards" site.

[Joss]

This is a good case for being able to use a page table to not just create additional pages for a given page, but also to be able to select any existing page table created page. (A bit like a page field, but with the creation advantage of a page table)

In the meantime, you can use a page field. So:

You create a page called Colours. Below that you have children, each representing a colour. Those can have other fields associated, for instance a price field if colours cost differing amounts.

Using your page field, you can select the colour parent and that gives you access to all its children. 

Using ASM select, you can now add lots of attribute parents and their children in the same way. They will need some common fields like a price field so that you can have just one method of adding up the numbers. But other than that you can rely on the individual templates for rendering out the info.

[Pierre-Luc]

Looking forward to try it too. 

Will this support Language* fields? I am currently using Shopify (which we dislike) on the website of a non-profit I manage, and this would be amazing to have. We have roughly 50% French and 50% English people and there's no way to make this happen. One nice thing would be to be able to match output of emails for receipts to the user language (I suppose you store templates for those in text fields?).

[apeisa]

Pierre-Luc: on the product catalog side: everything you have in your PW arsenal, will be in your PadLoper shop also. So multi-language. image galleries etc.. all that kind of things will be done how you like to do them with ProcessWire. So multi-language products are definitely easy thing.

Your idea about multilang emails is interesting - and I have it already covered. I actually don't store any templates in text files (I dislike any templates in text areas). What I have setup is very simple (but may I say clever!) thing.

All the default templates are stored in /site/modules/PadLoper/templates/*.*. Those are normal PW template files. so you have all the template variables and multilang stuff available there. But I don't want anyone to edit those files directly, so you can add same templates into /site/templates/padloper/*.* and PadLoper will use those instead.

So let's say we have email-order-confirmation.php template file. It's by default multilang ready, but if you want to customize it further, you simple copy the file into /site/templates/padloper/email-order-confirmation.php and edit it to your needs. And remember, you have all the template variables available, like $pages, $modules, $config etc.. Many of the templates also get $order variable, which has the current order and all it's information (customer, products, prices, taxes etc).

If you want to use these templates in your own code, it's also simple:

$t = $modules->get("PadRender")->getPadTemplate("email-order-confirmation.php");
$t->set("order", $order); // This template file requires $order variable
echo $t->render();

That make's it sure that you always get the customized version, if you have one, and the default one for those that don't have.

And then of course I have shortcuts for the most common templates, renderCart() etc - but customizing their markup is as simple as others (just creating copy of the file into site/templates/padloper/ folder.

[Pierre-Luc]

Thanks a lot for the precision apeisa. I subscribed to your mailing list, can't wait to have a go at implementing it (and ditching Shopify!).

[-aj-]

Hi Apeisa

I'm excited about checking this out, I have a large number of sites that are stuck in WordPress due to eCommerce functionality being needed (EDD or WooCommerce handling it in those cases). 

I can understand the rationale for making 'everything a page' as it's doing things the processwire way, but I've found that it can cause issues by mixing user or auto generated content (orders etc) with content that may need to be more managed or version controlled. 

Many eCommerce sites are constant 'works in progress' or follow a continuous improvement cycle. Because of this it's necessary to run multiple versions of the site (at the very least 1 staging, 1 production: usually I run 1 local, 1 stage, 1 production). Trying to do so with EDD or Woocommerce is absolute hell because as soon as someone places a new order on the production site the others are out of sync, and I need to write specific migration code or do  DB diff etc to be able to deploy changes. This is because in these systems orders are wordpress posts and order statuses are wordpress comments etc so if I've created a new post/page/anything in my local dev environment and someone has placed an order online, then it's almost guaranteed that we'll have a post ID conflict that we need to contend with. 

The devs of these plugins bascially just ignore it - most users are small and don't do any kind of test etc I'm just bringing it up so that you can see the implication of making EVERYTHING pages, most specifically customer orders. It would be excellent if orders could be separated out to a DB table so that changes can be made to local /staging copies with relative impunity without potentially clashing with user/auto generated content. 

Having a multi-stage development workflow is easy with any CMS if the data flow is unidirectional (with dev as the definitive source) , but things like eCommerce, Forums etc make the data-flow bidirectional (production and dev environments are authoritative sources for different information) and having them mixed up in the same DB table is just a huge mess.  

If I'm missing something here and this is already handled or accounted for then my bad, I just wanted to raise my concern so this doesn't suffer from the same pitfall that these popular plugins suffer from. 

Regardless I'm still very interested to see the progress of this platform. 

Thanks, 

Alex