Django Store with limited options - django

I want to have a pricing screen with only 4 options avaliable for the user to choose from. After this I need some integration to paypal to recieve the payments. Is it best to use satchmo for something this simple or is there another option available?

you could easily roll your own site if you have only 4 different items and a paypal integration. Paypal makes it super easy to integrate.
What happens if you want offer 5 products down the line? or a differnt line of products? If so it might be the stronger move to go with satchmo.

Related

How to connect a payment system in django?

I'm new to the Django framework and I don't quite understand how to connect the payment system to the site, at the same time, so that part of the payment for the product goes to the balance of the user who exposed it, and 10%-20% of the amount goes to the balance of the service. And what is the best way to connect a payment system for individuals.faces?
So, you need to answer yourself a few questions like:
What payment provider I need? It need to be paypal, stripe or...?
If I know what payment provider I need, is there package for django (or python) for it?
If yes, it is up-to-date?
If no, were there updates to API or solutions described in payment provider documentation?
Are they better in any term?
Depending on these answers, you could go straightforward to implementing payments using external library (for e.g. https://django-paypal.readthedocs.io/en/latest/) or just implement it yourself. In my situation when I implemented paypal payments in e_commerce store I just went with paypal buttons because they were looking better, and they, so far work more nicely.
What also you must mostly implement is something that Paypal calls IPN (instant payment notifications). Stripe, and for example TPay also has IPN-like mechanisms. The IPN is simply an view (functional or generic) that handles payments using data with usually md5 verification, where you update status of order to COMPLETED or et cetera.
The lack of security validation can make endpoint vulnerable to custom requests made by postman, curl or any kind of HTTP-testing tool.
For models - you should write them yourself or use provided by package. This usually means that with multiple payments you store one model per provider with ForeignKey to Order global model that collects all the data. You could use also abstract models for implementing multiple models with similar fields, but this causes some database query issues for additional logic handling (you can't query abstract models, so you need to parse stuff using forloops when you need it instead of using filters).
Frontend is also depending what you will use, but remember about not having price as hidden input :)
The thread is much bigger as it seems, but I hope I gave you point-of-view of the topic.

TWO Silent URL need to setup in the authorize.net

I have two applications which have a different server and using one authorize.net account. I have to put two silent URL in the one authorize.net account. how can i do it ?
You can't have more than one Silent Post URL. In fact, you probably shouldn't be using the same Authorize.Net and merchant account for different sites, but that's on you if you get caught.
You will need to make your Silent Post code smart enough to know which site the payment applies to and then act accordingly. This would probably mean utilizing the description field in the transaction to identify which site it came from. Then your code and use that to determine the originating site and perform whatever actions are necessary.
You also may want to look into Webhooks which offers more flexibility than Silent Post although it is more complicated to implement.

Direct payments between users on Django based website

I am building a website that should allow users to buy stuff from each other. I don't want to be involved in money transactions at all. It will be pretty much something like eBay. Card payments are not a must. Basically user views an item added by another user, clicks on a buy button and finishes the payment using third-party service.
The application will be based on Django and I was thinking of PayPal. I also do not want to pay for Premium accounts as I am not planning to charge users or earn money in any way. Could you please give me some advice on what is the best solution for this kind of project? I have been doing some research on the Internet but I am still quite confused.
Any help is much appreciated, thank you.
I am personally a huge fan of Stripe. It's much easier to work with than PayPal and also much easier to implement. It allows you to add transaction fees if you wish.
I'd read up on it, as it has quite a few solutions ranging from inclusion of a simple JavaScript file that creates Checkout/Pay buttons to designing a custom checkout flow.
Their documentation is extensive, highly geared toward developers, and worth the read.
Good luck!

Django paypal checkout for WHOLE cart

I made a Django online-store site and I need to include paypal checkout system for the cart, but solutions I found online either just for one item only(Buy Now buttons) or something like django-paypal-cart, which is not well-documented and I can't figure out how to make it to the checkout.
Please, give me some hint, maybe good article about how to make your cart items go to the checkout, anything will be highly appreciated, I don't know what else to google now
There are numerous options for tying PayPal into your website or app. Depending on exactly what you're doing or how good you are with web service API's you may choose one or another.
If you want to keep things simple, you can stick with Payments Standard. This is basically what you're referring to about the one item only buy now button, but you can use the cart upload command method to build a form that includes multiple items and pass it all over to PayPal at once.
If you prefer web service API's I'd recommend using Express Checkout. This consists of SetExpressCheckout, GetExpressCheckoutDetails, and DoExpressCheckoutPayment. Read through that general EC documentation to get familiar with the calls and how it all flows.
Another thing I would highly recommend utilizing is Instant Payment Notification (IPN). This is a feature where PayPal will POST transaction data to a listener script that you have sitting on your server any time a transaction occurs on your PayPal account. This includes payments, refunds, disputes, cleared payments that were pending, etc. This allows you to automate tasks like updating your database, sending out custom email notifications, hitting 3rd party web services, etc. and it happens in real-time, so it's very powerful.

pushing content to cell phones

I am working on a photo site and one of more active users asked about pushing content to cell phones. The site is built on django, and I was wondering if anyone knows a good way of allowing users to download and store content (images) on their cell phones?
As a side question... is it possible to accept payment for the content via the cell phone or would that have to take place on the site?
The best way to serve content to a mobile user would be to forward them to a mobile specific site. A lot of places do this by forwarding the user to http://m.mydomain.com/. You can tell if they're using a cellphone by checking against their UserAgent string as Harold said. Find more at: Change Django Templates Based on User-Agent
In terms of downloading, this is pretty phone dependant. On my iphone, for instance, I don't know that I can save images directly from the internet. (This could just be my ignorance, however). I think you're going to run into a lot of discrepencies on the browsers between different mobile devices. How many offer photo downloads vs. not, etc.
For payment, I would suggest keeping it in browser. There is SOO much that could go crazy on a cell phone and money isn't one of those places where I like to take risk. That being said, you could likely look into some sort of sms micro payment system (sorry, I don't have any recommendations) or look at partnerships with carriers such as Verison. Beyond that, I'd say keep it in the App.
Hope it helps.
Check to see if the User Agent of the phone(s) you wish to support is in request.META['HTTP_USER_AGENT']. If so, render mobile friendly templates.