If you are new to Django Oscar, then you can read these blog posts to understand how to create your own e-commerce shop using django-oscar and how to customize django oscar models, views and url's.
Django Oscar Checkout Flow covers the most use-cases. You can skip steps you don't need, or just write your own checkout views.
In Oscar the checkout process is laid out like this:
Logged in users will be automatically redirected to the next step.
Anonymous users are prompted to sign in, or to proceed as a guest.
NOTE: Even as a guest user, oscar still collects their email address.
Logged in users are offered the choice of either to enter or choose a shipping address from the existing user addresses.
Anonymous users are asked to enter shipping address details.
Info - When the user enters a shipping address, then this address will be saved in the session and later saved as ShippingAddress model instance when the order is successfully submitted.
In this step the user is allowed to choose a shipping method. Oscar by default provides only Free shipping method. If you want to add your custom shipping methods, you can add them here in this file in app named shipping by customising 'Repository' class.
By default, this view will load all the available shipping methods using the shipping Repository.
If there is only one shipping method available then it is automatically seleted and the user is redirected onto the next step. Otherwise, a page is rendered where the user can choose from the available methods.
NOTE: Before doing all these, this view will check whether shipping is required for the basket or not. If not required, then it directly selects NoShippingRequired method and redirects the user to next step.
This view should be customised to collect any information like choosing the method of payment plus any allocations if payment is to be split across multiple sources.
The oscar default behaviour will directly redirect to next step.
This view should be subclassed and customsied by all django oscar projects because no payment is taken by default.
If any sensitive details are required (Ex: bankcard details) are collected in this page. Along with these details billing address details can also be collected here, if required(get_default_billing_address() method can be used to prepopulate the form)
If the forms are in-valid then payment-details template is re-rendered with the relevant error messages.
Otherwise, if the form data is valid, then the preview template can be rendered with the payment-details forms re-rendered within a hidden div so they can be re-submitted when the 'place order' button is clicked.
Note: By this process, we avoid writing sensitive data to disk.
This view is called when the user clicks 'place order' button in preview page. If any forms are submitted in payment details page, then you should override handle_place_order_submission() method to re-validate and then build the submission dict using build_submission() method and call submit() method passing this dict.
The submit method generates an order number, freeze the basket so it cannot be modified any more and attempts to take the payment for the order by calling handle_payment() method.
The handle_payment() method should be overridden for handling payment and recording the payment sources (using the add_payment_source method) and payment events (using add_payment_event) so they can be linked to the order.
If payment is successful, then it places the order.
Finally, summary of the order with all details to shown to user using thank-you view and template.
Django-CRM :Customer relationship management based on Django
Django-blog-it : django blog with complete customization and ready to use with one click installer Edit
Django-webpacker : A django compressor tool
Django-MFA : Multi Factor Authentication
Docker-box : Web Interface to manage full blown docker containers and imagesMore...