Paypal - How to buy audio using PayPal and download the file immediately after - asp.net-mvc-3

Perhaps someone using PayPal can advise me on the best way to implement the following situation.
I'm developing a website for a non-profit organization and right now we are already setup w/ PayPal and have a "Donate" button on the main page. The website has audio samples and we would like to provide the option for the user to buy the full audio via PayPay. This is nontraditional (at least to me) in the sense that we are providing the purchased audio files for download immediately after payment.
Also, note that there is a lot of Audio files and, if not too difficult, we would like to keep track of sales on each item purchased.
How should I design/implement this situation, while using PayPal.
(On a separate note, in the future I would like to keep track of Users and "who purchases which items", so that in case something "bad" happened during the audio download, the user would have the chance to re-retrieve the downloaded item.)
Technology: ASP.NET 4 (MVC 3)

You may want to look into Paypal Express Checkout that verifies using Paypal's IPN.
This is a long answer and it is best that I point you in the direction of the above and ask that you look up the documentation itself.
Things to keep in mind:
There are more checkout methods aside from Paypal's Express Checkout, don't get these mixed up when you are looking through the documentation.
Some of the Paypal ASP.NET code examples were out of date when I last implemented this (about 3 weeks ago)
This tutorial was quite valuable when I was going through this process.
Code: http://blog.wekeroad.com/2008/10/11/mvcstore-part-22
Video: http://www.asp.net/mvc/videos/mvc-1/aspnet-mvc-storefront/aspnet-mvc-storefront-part-22-restructuring-rerouting-and-paypal
See this post in reference to the check-out process workflow. The main idea is that you will need to verify values using Paypal's IPN. Here is the documentation.
In it's simplest form::
You're going to need to assign order id's of some sort to each transaction.
If the payment for the order is not-confirmed (your default state), do not allow download of the mp3.
If the payment for the order is confirmed, allow download of the mp3.
Keep track of all this information and more in your database and create an Admin section of your app that allows you to view / edit details of all orders.

Related

Selling custom product that doesn't fit well for in app purchase

I'am working on community project for chess players and I use standard in app purchases provided by Google to get credit for functions to be used. I prefer however one big payment for one country (culture) made by some company or major local chess entity, personally dealing conditions, creating data source to fit my app, giving users everything within the culture for free and in return giving the sponsor place in various screens of my application.
I know 3rd party payment processors are not allowed for standard app use.
Breaking Google Play developer policy in this case or not?
Making in app purchase for this is just weird.
How to get money for such a product not breaking Google play rules?
There's a whole website by Google explaining the policies.
I don't work for Google's policy team, and I'm not a lawyer, but here would be my reading:
If you want a user to pay within your app, then use Google's methods. So if you want the person sponsoring the whole country to pay within the App, use Google's payment methods.
What you do as a company to strike sponsorship deals and take payment is up to you, if that payment happens outside the app.
But you should read that website above carefully for yourself, and of course Google Play has the final say.

PayPal checkout options

I've been working on a secure shopping cart and checkout for a website. I'm using PayPal, and I'd read that PCI requirements aren't as much of an issue if we don't store card data on our site, so if possible I'd like to avoid that.
HTML buttons seemed like a promising option, but upon further investigation, it seems like maintaining control of active user sessions may not be possible. Below are my sources that seem to confirm this.
PayPal button return url usage
delete session variables when session id is known but not able to start session
PayPal payments pro is mentioned in the second post, but I'm wondering if it or anything else meets my 2 design constraints as they're implications for the implementation don't seem to gel very well.
If they are losing session data when returned from PayPal with a standard button then they have something else going wrong. That should not be happening.
That said, if you're comfortable working with APIs I always recommend Express Checkout and Payments Pro.
If you prefer REST APIs you can use that for PayPal payments and direct credit card payments.
If you prefer NVP / SOAP you can use the Classic API.
In any case, keeping session data alive won't be an issue, and as you mentioned, as long as you aren't storing any credit card data on your server in log files, in the database, or anywhere then you won't have to worry about PCI compliance.

Laravel & complete Paypal/payment solution

So I'm trying to implement a payment solution for my website and after quite a bit of research, I'm still lacking a complete solution. I'm running Laravel 5.0 and need general shopping cart payment functionality. I thought I would post this to try to create a reference to help others that may be having this issue. I got as far as getting test transactions into the Paypal sandbox and that's where the brick wall has seemed to come in, but a complete overview would be helpful. I’ll list my issues that I need to overcome in order to issues some run into.
Issues needing to be resolved to complete the payment solution implementation
My biggest issue with what I've seen has been receiving the
notification of successful payment processing back, but I'll walk
through what I've seen thus far. I'm not sure how to set up a listener or other methods of detecting a correct payment processing
Dealing with Credit Card information when I’m trying to avoid it
for the time being – I’d like that to be done on the gateway website
Potentially kicking off some of the calls to these APIs in Laravel
when the user checks out
I’m trying to move items to my server, but the development is being
done locally which creates an added issue
The options
There’s simply Paypal
I’ve taken the basic form implementation as far as getting payments into Paypal, but I can’t seem to get payments out. I’ve tried the returnURL and that doesn’t seem to work
I do not necessarily like this option because it seems to be leaving a lot of information in the form that would seem to be better kept private on the server
I’d like to use something complete on git but I seem to find the documentation incomplete
https://github.com/thephpleague/omnipay-paypal
--Not sure how to implement this in laravel
https://github.com/ignited/laravel-omnipay
--doesn’t appear to be being used
https://github.com/net-shell/laravel-paypal
https://github.com/anouarabdsslm/laravel-paypalpayment
--The card information is not intuitive here as that’s what going to
paypal’s supposed to manage
It would be nice to use Paypal express but I don’t see a ton of resources specifically for that.
There's Aimeos.
I don't necessarily feel safe with manually implementing the vsrf
protection and it doesn't seem to offer that much more on the payment
front than
I’m open to others that are complete and charge similar fees to Paypal
Stripe doesn’t work for me. I’m not doing a basic subscription
Any complete thoughts would be greatly appreciated as documentation left short has caused issues in this case. Thanks!
This PayPal PHP SDK will make all of the PayPal classic API calls very quick and easy for you. It's available on Packagist/Composer and can be applied to Laravel very easily.
It supports Express Checkout, Payments Pro, Invoicing, Transaction Search, Transaction Details, Refunds, etc.
This is done in Laravel 4, but I had begun this "PayPal Glass" project a while back to show how the class library / sdk can essentially replicate everything you can do within a PayPal account. Here it is running on my local test server.
So yeah, that SDK should be able to handle everything you need to do with PayPal inside a Laravel project.

Magento: Confusion with Recurring Profiles and Authorize.net ARB or CIM

The next big topic in my new start-up company is recurring billing inside Magento. We will have a few recurring products we'd like to offer alongside some standard one-time products. I've researched the best gateways and so far we think either ARB or CIM from Authorize.net is the way to go.
Some questions come up though such as:
If Authorize.net is going to handle the recurring aspect, what is the point of Magento's built-in recurring profiles system? As far as I can tell it's to integrate with the 3rd party by actually taking the user to the 3rd party site? Using Authorize.net would eliminate the need for recurring profiles right?
Are we limited to purchasing one of two or three $300 modules out there to get started with ARB or CIM? So far Magento only supports SIM or DPM. Or do I have to sit down and extend the built-in Authorize.net payment method? Basically I am trying to say we are on a start-up budget and $300 is a killer at this moment.
If we went with ARB over CIM that means if a customer came back to purchase a second item later on that they would have to re-enter their information (CC #, exp. date, etc.) whereas CIM would have this ready to go...is that the correct explanation?
We need the flexibility to create unique payment schedules during checkout. For example: We will sell a custom website and hosting package. We want to charge the user 50% of the website cost upfront and 50% upon completion and setup a recurring payment for the hosting package all at time of checkout.
Along with question #4, currently Magento's recurring profiles limit nominal items to be purchased separately than regular products. This is not acceptable for us and a customer must be able to purchase all wanted items together in one checkout page.
Sorry for this lengthy post but I'm very curious to see what our options might be given all we want/need to do. Any advise is good advice!
The Magento recurring billing code allows customers to view and edit their subscription inside the Magento webstore, so there's no redirection to third party.
Short answer: yes, or roll your own.
I believe that is the case, but you need to check with Authorize.Net on that.
Not sure what the question is here?
Then refer to your earlier question on this topic that I answered. You can choose to override the core functionality, but you need to familiarize yourself with the reasons why Magento chose to enforce that restriction. I believe that is likely due to a restriction in the Paypal interface, and other recurring billing gateways such as Authorize.Net may be able to cope with one-off and recurring items in the same transaction.
HTH,
JD

How to provide gift card code automatically to user who likes product on the magento based ecommerce site

Is there any way to link face-book like feature with the magento gift card code. Like if any user/visitor likes any product on the site then store administrator want to sent gift code automatically to that user. This should happen automatically without involvement of any manual process.
Thanks,
Rather than sending a gift card code, you should generate a one time use coupon code and send them that.
In terms of tracking the Facebook like, you can use Facebook's FB.Event.subscribe method which is a part of their JavaScript SDK. A simple snippet will allow you to listen for a "like" event, the SDK will then provide you with a callback containing the URL liked (the current page). You can pretty much do whatever you want from there.
Everything you need should be here: Facebook JS SDK

Resources