- Business Foundation
- Generating typed business foundation classes
- SQL meta-model
- Extending meta-models
- Exporting and importing meta-models
- Working with SQL Records
- Working with entity objects
- Filtering and sorting
- Business meta-model
- Product variants
- Bundles and packages
- Related entries
- Catalog events
- Commerce rendering templates
- Catalog content provider
- Assets and media
- Metadata Plus
- Order system overview
- Order manipulation
- Order processing
- Calculating orders
- Extending order classes
- Changing default implementation
- Rounding totals for different currencies
- Order notifications
- Order events
- Searching for orders
- Order object model and database diagram [Legacy]
- Order management classes [Legacy]
- Order addresses [Legacy]
- Shopping cart [Legacy]
- Checkout process [Legacy]
- Recurring orders [Legacy]
- Changing order number sequence [Legacy]
- Taxes [Legacy]
- EPiServer.Commerce.Sample guideline [Legacy]
- Scheduled Jobs
- Customizing search
- Configuring facets and filters
- Creating a search provider
- Configuring Solr search provider
- Configuring Episerver Find search provider
- Find integration
- Warehouses and inventories
- Workflows and activities
This content is archived. See latest version here.
Last updated: Jul 14 2016
Changing default implementations
When working with the Episerver Commerce order system, to replace implementations, the dependency container must be updated to use your new classes. Refer here for more information.
The default implementation for IOrderRepository is architected so that it does not need to be replaced to provide custom implementations for different order types. Instead, you register implementations for ICartProvider, IPurchaseOrderProvider, and IPaymentPlanProvider to change the behavior of IOrderRepository.
Use this interface to listen to and act on order repository events.
Use this interface to change the default implementation of loading and persistence of shopping carts.
Use this interface to change the default implementation of loading and persistence of purchase orders.
Use this interface to change the default implementation of loading and persistence of payment plans.
Use this interface to create implementations of the order system object abstractions. You almost certainly need to change the default implementation if you create a custom order provider, which uses different objects for persistence.
Use this interface to determine a shipment's default warehouse. You need to change the default implementation if you have multiple fulfillment warehouses, because the default implementation only supports one fulfillment warehouse.
Use this interface to adjust inventory. You need to change the default implementation if you integrate with another system for inventory checks.
Use this interface to determine if a line item is valid in terms of active status and availability dates on the entry itself as well as the catalog. You need to change the default implementation if you have other criteria which determine if a line item is valid.
Use this interface to get the currently-placed price for an line item, and update it if necessary. You need to change the default implementation if you have additional pricing rules outside of what is implemented in the configured pricing provider.
Use this interface to process payments on an order. You need to change the default implementation if you are not using configured payment providers to handle payments.