Customize Oscar to support digital products and one-click purchase

[feng...@gmail.com]

Hi Everyone,

I would like to customize Oscar to support virtual products such as paid articles and videos on a mobile platform. Since the product is digital, there is no shipping required. Also, the checkout and order process can be further simplified to this one scenario: 

1. a user browsers a catalog, and click a link that interested him (her). 
   
2. The product detail page shows up and offers a one-click purchase button. 
   
3. Once clicked, a payment page will popup and ask the user to confirm the amount.
   
4. After payment is completed, the website redirects the user to the paid product page.
   

Of course, users can always go to the orders list to find purchase history and do not need to purchase same product twice. After some investigations (and struggling), I am thinking about writing a view for the one-click purchase. The view skips the cart, checkout information and shipping. It directly creates an order with one single product and handle the payment then redirect the user after success.

Can anyone share some ideas if you ever encountered similar scenarios before? I think Oscar is definitely capable to of an elegant solution to my requirement, but I feel quite stuck on where to start.

Thank you all in advance,

FE

[Kamil]

That sounds fairly easy. Start with adding a new view, which can just re-use the relevant code from the regular checkout workflow, minus things you don't need (no shipping address, no shipment, etc). Since the regular checkout process already skips unnecessary steps, perhaps all you need is to redirect to the payment summary page after adding the item to the basket.

K.

[Yi F]

​I guess my real problem is how to combine multiple views from different apps.

I would start with adding a new URL to the app.py of the checkout app and assigning a customized view - OneClickCheckOut to it. 

For the view, some ideas I have in mind right now are 1. the view class imports Oscar classes relevant to the checkout process and create instances to simulate the add to cart to payment process. However, this solution seems fairly hard-coded and reinvented the wheels. Option 2, the view class inherits from classes involved in the checkout flow, but it will be a subclass of more than five classes and definitely looks ugly and cause issues later.

I think a better way to handle this is to define a checkout flow. In my case, add to cart, shipping and checkout preview can be simply skipped. The flow can simplified to click purchase - payment - redirect.

Any advice will be welcomed.

On Mon, May 14, 2018 at 6:27 PM, Kamil <harr...@gmail.com> wrote:

That sounds fairly easy. Start with adding a new view, which can just re-use the relevant code from the regular checkout workflow, minus things you don't need (no shipping address, no shipment, etc). Since the regular checkout process already skips unnecessary steps, perhaps all you need is to redirect to the payment summary page after adding the item to the basket.

K.

--
https://github.com/tangentlabs/django-oscar
http://django-oscar.readthedocs.org/en/latest/
https://twitter.com/django_oscar
---
You received this message because you are subscribed to the Google Groups "django-oscar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-oscar+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/django-oscar.
To view this discussion on the web, visit https://groups.google.com/d/msgid/django-oscar/62f9cf56-d023-45c4-a5f3-ce3e56b67f7a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Yi

[Kamil]

> 1. the view class imports Oscar classes relevant to the checkout process and create instances to simulate the add to cart to payment process.

Actually sounds reasonable - you're re-using most of the checkout code, and can plug in any necessary custom logic in between the steps.

> Option 2, the view class inherits from classes involved in the checkout flow, but it will be a subclass of more than five classes [...]

Incredibly ugly, smells, and almost certainly won't work without even more hacking.

My advice is to just go ahead and build a prototype. If it works, you're 90% there - just clean it up, document it, and ship it ;)

<3,K.