Decision checklists
This page is for merchants, project managers and agencies who must make store decisions and record why. Each checklist is short; tick what applies and the answer follows. The facts behind each are on the linked page.
Contents
- Price field
- VAT mode
- Customer data
- Shipping
- Payment
- Receipts and basket behavior
- Several sites
- Beyond the kernel
- Archive or remove
Price field
- To do: We sell in more than one currency.
- To do: Prices per currency are set by market, not converted.
None ticked: ezprice. First ticked: ezmultiprice, with automatic or custom prices according to the second.
(Price fields compared)
VAT mode
- To do: All products have the same rate everywhere we sell.
- To do: Rates differ by product only.
- To do: Rates differ by customer country and product category.
- To do: Rates depend on something else (business customers, delivery address, an external service).
First: one VAT type. Second: several VAT types, chosen per product. Third: VAT rules plus [VATSettings] Handler=ezdefault.
Fourth: a VAT handler of your own. (Product categories and VAT rules,
Custom VAT handler)
Customer data
- To do: Guests may buy.
- To do: We need a full postal address.
- To do: We need fields the shipped forms lack (company, VAT number, delivery address).
Guests and full address: ezuser. Short form: ezsimple. Accounts only: ezdefault. Extra fields: own handler.
(shopaccount.ini walkthrough)
Shipping
- To do: One flat amount per order is acceptable.
- To do: Shipping must carry VAT.
- To do: Rates differ by country, weight or amount, or customers choose a method.
Only the first: Simple shipping event. Any other: a shipping handler. (Simple shipping event, Custom shipping handler)
Payment
- To do: Our provider is PayPal.
- To do: Our provider is Authorize.Net and we accept card data passing through our server.
- To do: Our provider offers a hosted payment page or redirect.
First: ezpaypal. Second: ezauthorize. Third: write a redirect gateway. Otherwise: a transparent gateway, with the
card security work that brings. (Payment gateway development)
Receipts and basket behavior
- To do: Guests buy, and should reach their order later:
OrderLinkView=orderreceipt. - To do: Customers buy many items at once:
RedirectAfterAddToBasket=reload. - To do: The payment provider's documentation requires an empty basket before payment:
ClearBasketOnCheckout=enabled. - To do: Computers are shared:
ClearBasketOnLogout=enabled.
(shop.ini walkthrough, site.ini shop settings walkthrough)
Several sites
- To do: One order list, one tax setup and one currency list for all sites is acceptable.
Ticked: siteaccesses on one installation. Not ticked: separate installations or databases. (Multi-store and multisite)
Beyond the kernel
Not in the kernel, so each ticked item is a project:
- To do: Stock management
- To do: Coupon or voucher codes
- To do: Invoices in an accounting system, accounting export
- To do: Shipping labels, carrier integration
- To do: Automatic delivery of files after payment
- To do: Marketplaces
For each: an extension, a workflow event or a handler, built in house or by a partner (What the built-in shop does).
Archive or remove
- To do: The order is finished and must be kept for the records: archive.
- To do: The order is a test order on the live store: remove.
- To do: Data must be erased and nothing obliges us to keep it: remove, and record it.
- To do: This is a test database before handover: the shop cleanup script.
Related pages
- Operating a store
- Merchant path
- Store planning for small businesses
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.