Commerce now in beta

Commerce makes it easy to sell online exactly the way you want. Extend functionality with our Payment Methods and Modules or build your own.



Commerce: Work in Progress

Commerce is currently in invite-only beta testing. We've got ambitious plans to make Commerce the best e-commerce solution available for MODX. In this roadmap, we're publishing our plans and progress towards v1.0. Once we hit that, we'll update the roadmap with our plans beyond v1 which includes features like subscriptions, Ebay/Amazon integration, an improved status workflow editor, and lots more.

Send us a note via [email protected] or post on our community forum if you have any questions or feature requests.


The road to Commerce 1.0

Currently we're focusing on getting Commerce to version 1.0. That version number represents Commerce being ready for production, and having all the baseline features we decided on.

Not all features and ideas have made it onto the list for version 1.0. We'll work on those in the releases to follow. Be sure to send us your feature requests so we can properly prioritise each of them.

The statuses on the roadmap roughly go in this order: Planned > In Progress > Almost Done > Missing Documentation > Complete.

Also see the Features List for a run-down of all the (already implemented) features, and Development for a list of released versions and realtime insight into our internal bug/feature tracker.

  • Commerce was built with extending in mind, so making it modular in a way that you can extend it with modules is very important. Just need to create some sample code for developers to show how to register their modules.

  • OmniPay is a popular PHP library that abstracts away the implementation details of different payment providers. This means there is a standardised API that can be used with pretty much any payment provider out there, provided there is a driver for it available. See the other roadmap further down this page for the specific gateways implemented or planned.

  • Whereas SimpleCart tightly connects a payment gateway to a payment method, these are separate concepts in Commerce. This means you can create many instances of a single payment gateway.

    Payment methods can be given both a fixed and percentage-of-order price, and can also be restricted to certain order totals. These features combined with the separation of payment methods and gateways enables a lot of control over how customers can pay their orders, and what that costs.

  • For complete control over the pricing of payment methods, Commerce allows you to extend the payment methods to calculate the payment price any way you'd like. Out of the box it has fixed price and percentage of order total pricing, with restrictions on order totals that can use the payment method.

    By extending the payment method it's possible to tailor the payment method price to the cart, for example by looking at specific products or the total number of items purchased. This process is similar to building custom shipping methods, but needs to be documented specifically for payment methods.

  • Shipping methods can be configured via the admin area of Commerce. It allows you to set a fixed price, or a percentage of the order total as fee for the shipping method. It's also possible to set a minimum and maximum order amount for a shipping method to be available, so you get a flexible solution out of the box.

  • Aside from the tweaks still needed to shipping methods in general, the ability to create custom shipping method classes with bespoke logic for determining the shipping price (for example based on product weight, size or quantity) is available and documented in the developer docs.

  • Theming/templating is done with Twig. This is a template language not too different from the MODX templates, however it has a couple of interesting features that make it a lot more powerful. Thanks to these features we can keep the number of unique templates to a minimum, and it gives more flexibility in how for example your cart or checkout is built. The templates are also stored in files, making it easier to keep in version control. The templates can either be in the commerce directory or another defined path.

    One of those features is support for partial themes. If only one template file needs to be changed, only that file has to be duplicated and edited; all the other templates will fall back to the default.

    The templating basics are documented. Documentation on specific template files and an introduction to Twig would be good to add still.

  • Modules can hook into an EventDispatcher from Symfony 2 to essentially fire plugins on events throughout the Commerce core. This enables modules to influence core behaviour with a clean upgrade path. There's some high level documentation available for this already, however that needs to be improved and expanded to include a list of all available events and how they can be used.

  • For information on how statuses, status changes and status change actions work, check the documentation. This has been mostly implemented from an architectural standpoint and is reflected in the dashboard.

  • The merchant dashboard is a big part of Commerce that includes everything from order management to reporting and configuration. It's built html-first with javascript enhancements. The dashboard is mostly done, however there are still tons of small (and bigger) tweaks that we'll continue to make based on your feedback through the alpha and beta.

  • Commerce has basic multi-currency support. See the documentation for details.

  • As products and the catalog are considered separately by Commerce, snippets and models (or modules) need to be available that can be used to link products to a resource-based catalog. A basic implementation of this is available and documented. There's also a custom Products TV which is a cleaner and more flexible way of dealing with products in the catalog.

  • Similar to the Resource Catalog, the necessary tools for interacting with an existing SimpleCart catalog needs to be developed and documented. Planned before v1.0.

  • Address validation in the checkout is done with modules, of which 3 are available out of the box. The basic validation just checks if the configured fields are filled in, if the email address is valid, and if a proper country was selected. The country validator allows you to whitelist/blacklist specific countries that should be able of placing orders (or not). The EUVat Validator module checks if a provided VAT registration is valid.

  • The reports and exports cover a wide range of topics, including product sales, taxes, orders and addresses exports. Technically this roadmap item will never be completed, but we've reached a set of reports that covers the most important aspects for v1. Lots more reports will be added in the future based on your requests.

  • The merchant dashboard allows you clean up most object types. Some of these use a safe soft-delete, where the object stays in the database for historical accuracy, while some others are permanently removed when you hit the delete button.

  • The checklist on the configuration page in the merchant dashboard offers some guidance on things to check while going live, as well as strict requirements. This checklist is also extendable, so modules can add more checks to it.

  • Emails and other forms of communication related to an order are managed through order messages. Before the beta the plan is to extend this system to have statuses, so that messages can be in "draft", "queued" or "sent". That will allow (third party) integrations to asynchronously send messages that are in the queue.

  • By integrating with TaxJar Commerce can automatically handle US Sales Tax.

  • The EU VAT module handles providing the tax rates for all EU countries. The EU VAT Validator module added in 0.2 handles validating a vat_registration address field with the VIES database. With both modules enabled, you can set the EU VAT module to implement the Reverse Charge mechanism to charge 0% VAT on international business to business sales, with verified VAT numbers.

  • The checkout already supports user accounts, but it doesn't have the feature where on the address step you optionally provide a password and it creates an account for you. This would be a really great feature we'd like to add to Commerce for v1.

  • Commerce has pretty verbose steps at the moment. These can be combined into a single AJAX-powered checkout experience, which we aim to have available as either a module/theme/documentation before v1.

  • The dashboard (as in, the first page visible when you browse to Commerce in the manager) offers a sales graph and some basic information. We're planning to extend this, and make it extendable through modules, so it can provide better information at a glance. Send us your ideas for what you'd like to see.

  • Invoices will function through the status workflow system where you can define at what point during the order handling an invoice is generated. The goal is to make this support PDF invoice generation, or make it pluggable so that PDF invoicing can be added.

  • The ability to list and interact with previous orders when you're logged in.

  • The ability to set sale prices with a from/until date/time which are automatically updated on the site as the time comes along.

  • With the UserProfileAddress snippet it's already possible to prefill previously used addresses, but this will be extended to offer the customer a simple option to select from their previous addresses. When selected it will not create a new address record, instead re-using the same object.

  • The component is already somewhat mobile friendly, but not entirely. Especially the navigation does not work well on smaller screens like phones or tablets. This will be addressed before v1. The dashboard will also be made to use more AJAX so full page refreshes are not needed as often, which should also improve the user experience.

  • Order information is currently read-only. For concept and processing orders it will be made possible to add/edit addresses and to change order items and quantities. There are some aspects to this, mostly related to changing order totals and requiring additional payments/refunds, that are not completely worked out yet.

  • Integrating with Google Analytics or Adwords for conversion tracking can already be implemented through custom templates, but instructions or a module that accomplishes this will be added before v1 to make it easier.

  • For example to allow reseller or VIP users to purchase items at a discount. Probably implemented as a new tab under Discounts in the component, or could perhaps also use user(group) settings.

  • Status change actions are fired when a status is changed. A Slack status change action will be able of posting orders to a configurable Slack channel as another way to receive notifications.


Payment Gateways

The list of Payment Gateways below shows you which gateways are currently complete, in progress, or planned to be added. It also lists gateways that are unconfirmed, which means that we received a request for it before, but not enough to make it an immediate priority. Eventually we intend to add all gateways we can but for now which ones will be available out of the box depends on how many requests we get for each.

A large part of the prioritization here happened following the Early Access Survey in October 2016.

  • Implemented. This uses the more recent PayPal express checkout experience.

  • Uses Stripe.js with a custom form to give full control over the markup.

  • Can be used both as a "catch all" to allow the customer to choose a payment gateway on the Mollie checkout page, or it can be configured to use a specific payment method for more control over the experience.

  • Offers credit card and PayPal, as well as some other integrations including Apple Pay if enabled on your account.

  • Authorize.net has been implemented with (fairly new) Accept.js implementation. This requires JavaScript, but is also the cleanest PCI-free implementation Authorize.net offers.

  • Implemented with the Paymill Bridge PayFrame integration for reduced PCI compliance requirements.

  • Allows customers to pay with a wide range of payment methods.

  • Popular in the UK. Integrated with their hosted checkout option, so off-site PCI-compliant payments. Added in v0.9.

  • Originally planned for beta, we've put this on the back-burner for now due to some issues.

  • We're considering adding this gateway. Additional requests for it will help make it a priority sooner.

  • We're considering adding this gateway. Additional requests for it will help make it a priority sooner.

  • We're considering adding this gateway. Additional requests for it will help make it a priority sooner.

  • We've not received enough requests to confirm this gateway yet. If you need it, let us know!

  • We've not received enough requests to confirm this gateway yet. If you need it, let us know!

  • We've not received enough requests to confirm this gateway yet. If you need it, let us know!

  • We've not received enough requests to confirm this gateway yet. If you need it, let us know!

  • We've not received enough requests to confirm this gateway yet. If you need it, let us know!


navigateup

Disclaimer: Viewing non-Euro pricing

You are currently viewing prices in a non-Euro currency. Please be advised that these prices are estimates, based on data by Open Exchange Rates.

While we offer this currency converter hoping our users find it convenient, all purchases are made in Euro, and the final amount charged can vary depending on payment provider, day, time of day and a number of other factors outside of modmore's control. There are no guarantees on accuracy and modmore nor Open Exchange Rates can not be held liable for errors.

×