Is paypal a suitable system for handling event ticket payments. All I want to do is create a page with event details, a list of hOw many tickets are left and a secure payment handling. Systems like eventwax seem to charge for use of there system and then paypal charges you too. I just dont get why people are paying twice. Also does anyone have any other recommendations for similar sites like eventwax
Google Checkout lets you do something that will work for you. Basically you create a Google Docs spreadsheet that follows a special format and contains the items that you sell and the quantities remaining. Then, you can make an HTML button that you can embed in your page. When a user clicks the button, it processes the selling of a specific item from that spreadsheet. Google handles everything else automatically - it subtracts one from the quantity field in the spreadsheet, processes the payment and sends you an email with the purchase and shipping details. Little to no programming required.
Of course, this can't work with PayPal.
First off, paypal comes in many different flavors. From the simple they host the order form and process payments way on up to all you do is pass them the credit card info and charge amount and they process it.
With that in mind I don't believe they support selling a limited quantity of items. This is something you would have to provide with your site.
Which leaves us with: are you asking a "how do I code this" type of question or something more general. If the former then please provide language and what you have so far. If the latter, then you might try at http://webmasters.stackexchange.com
Now regarding eventwax charging for usage, that is a perfectly legit thing to do. They are providing a service which allows people to sell a limited number of things, ensure that those things aren't over sold (which can be difficult depending on your db transactional experience), and handle payment processing.
All said and done there are really several companies which will get a piece of the action so to speak. Paypal is one, the credit card companies are another. If you are using paypal's payflow pro gateway then there is at least two other companies involved: your bank and the transaction processor themselves.
Which leads us to why people pay companies like event wax. Quite frankly, it's easy they don't have to screw around with programming something, and it works right now. There's a lot that can be said about doing things this way. Usually you just include all of this into the cost of doing business.
Related
As a developer, I want to know what are the advantages of using PayPal API?
I know there are a ton of APIs out there to use, but if I will use the PayPal API specifically, what are the benefits of it?
Typically people use the PayPal API if they have a business that wants to process payments via PayPal. It's not a developer question.
Your question becomes, really, what are the advantages of processing payments with PayPal? And there may be interesting answers to that question but this isn't the place.
Edit:
Ok I did think of something that can be added from a developer and solutioning perspective
Look at the demo code here
See how easy that is. Now actually click one of the buttons. See how the window emerges, and how quick and natural the payment experience is for the user--with the originating website staying loaded in the background.
Think also about the security of this payment experience. All the buyer's financial instruments are saved and stored at PayPal; nothing is shared with the (potentially new/unfamiliar) ecommerce site they are paying, whereas PayPal is a relatively trusted name by many millions of buyers.
So, TL;DR : it's very easy, it's very quick (no retyping things) and secure, and people trust it enough to actually send you money and hope you will deliver on the new product/service you are offering
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
Suppose some online retailer uses XYZ Bank's payment gateway. Is it possible to do the job of filling in card details and proceeding through the entire process using a script? If yes, is it legal?
Update:
To make the question more clear, I'll give a scenario.
Suppose the retailer we're talking about is Amazon, and I wan to use a card/netbanking (not PayPal). I want to be able to place an order on Amazon using a script which does the job of filling my cart and making the payment. Say the cart thing has been taken care of. How do I automate the payment process now? If it's allowed that is. Card details etc will not of some user, but my own, so no security issues with that I suppose.
The payment API would usually support something like this. For example, if we look at Paypal's direct payment api, they provide secure means for you to pass credit card numbers, etc to Paypal to process the payment.
If you are thinking to do this to process recurring payments, then you are doing it the wrong way. You should never store any credit card details unless you are PCI-DSS compliant. This takes a lot of work and auditing, so it is somewhat rare for small and medium companies to do it. For recurring payments, store the credit card numbers with your payment gateway (most should provide a means to do this) and the gateway should return a token to store. Every time you want to charge the card, simply pass the token to your gateway.
Given the new information:
What you are trying to do is to automate the browser (that's the best way to do it). You could write a script that connects to Amazon, loads the page, fills in the POST variable, send it back, get results and so on, but it is not very robust. For example, if amazon changes the name of a few post variables or even the markup, then your script would fail.
The best way to do this is to use a Browser Automation framework. Selenium is prbably the most popular and most well known. It is often used to automate testing user interfaces, but it is also useful for doing something like you are suggesting. You can use Selenium IDE which is a Firefox addon to quickly reproduce and replay recorded actions. For something more advanced and highly scriptable, try Selenium WebDriver.
As for whether this is legal or not, I don't see why it shouldn't be legal if you are using your own credit cards and what not.
If you are using your own credit card details it's at your own risk so very minimal legel issues. But it's always a good idea to store & transmit(SSL) card details encrypted for some peace of mind. But if it's for wider public you will need to look into PCI guidelines and matching class requirements.
I have a VoIP calling company for a Russian market with a Russian website where people can sign up for an account, buy credit and make calls. My service is not even popular and I have only ~100 customers. Recently, I had around 10 fraudulent users who used stolen credit/debit card or PayPal accounts to make payments. Even though my website is in Russian, I had fraudulent customers from Somalia who purchased $50 worth of credit with stolen information. Two days later after fraudulent user signed up & used up their credit, I received email from PayPal saying that those transactions were "unauthorized (transactions)." PayPal gave me 10 days to resolve this dispute and make refunds by talking to people whose financial information was compromised. After hours of arguing and debate, I had to make refund and accept the loss. But, is this how it works? What if I had 100 fraudulent customers who purchased $1000.00 worth of credit? How can I insure myself against this? Note that my service was in Russian, what if I had English website for everyone to sign up? How do you protect your service against such things?
Some of the measures I can think of are:
Customer must activate their account via verification email (Already implemented)
Accounts are by default aren't activated, I have to manually
activate them (Customers may not like this)
Calling the new customer at provided phone # to make sure if he
really signed up (I hate this one)
All of your advises and opinions are appreciated!
I worked at a similar company (no names) and the only thing we could do that actually solved the problem was to have the users sign up with a credit card, billing the minimum amount from their card while generating a code that was included in their statement (a'la "VoipMaster (4711)")
They then had to look up their credit card bill (many banks let you do it pretty much immediately online) and enter that code at our site. In other words, the user had to have access to the credit card bill to sign up, not just the credit card information.
I think that pretty much stopped fraud cold, but it's hard without marketing research to tell how many valid users didn't sign up because of it.
Its just the pitfall of accepting online payments. You do not lose $1000 worth of money when you have to refund though. Paypal should not charge you any fee's for reversing the money and therefore you have not lost anything apart from a small amount of time.
There are some things you could do to try and prevent this happening in the first place. The biggest thing would be to chose one or more vectors and then detect any changes on those vectors. A change would then need to have a secondary authorisation.
For example you could say that if you try and use a different paypal account to the last one you used, then you must go through confirmation stage.
Another one could be that if you purchase more than a certain limit then you go through the confirmation stage.
If your IP address changes you go through the confirmation stage (not so good, but its an idea nonetheless).
The confirmation process/stage could be anything you deem suitable to ensure to the best of your ability that they are legitimate. For example you may require email confirmation from them or require them to wait 24 hours for the credit to be given (provide a phone number they can call you on to fast track maybe).
Theres no sure fire way, but the harder you make it the less it will happen. Theres hundreds of things you could do based on the simple theory i posted above. Nevermind more complex things you could possible use. At $50 a time i would assume they are using your site as a test site to ensure the details all work ok, before going on to using them for larger payments elsewhere or transferring money to there own accounts. So if you make it harder for them to do that,, they will find somewhere else to test them.
I'm trying to integrate a payment mechanism to my site. The scenario that I need is not trivial and can be explained by the following example:
User pays upfront for a subscription program (i.e. receiving Netflix). User is able to make changes to the subscription (i.e. change number of movies checked out each time from 4 to 2)
User is able to buy additional one time purchases via the provider's site (Netflix) supplied by 3rd parties. These items (i.e. popcorn, snacks) get billed to the same credit card as the subscription without having to go through the process of resubmitting the credit card information.
Of course, my site takes also a small fee for the transactions :-)
I was wondering if this is supported by PayPal, Google Checkout or someone else.
Thanks.
The Paypal api can handle all of those processes.
I seem to have dropped the ball on what kind of answer you wanted so I'll leave it at that.
If you have some feedback, more direct questions I will try to answer as much as I can
--
The money would best go through you first, unless somehow you can convince your customers its normal to bill them per item. Also if they pay by credit card you should only bill them once as you would incur fees on every payment. I don't know of anyway to bill once but distribute the payments.
As for the paypal docs..
Very good resource, there is also some sample code for most major web languages
Also this will get you started if you don't have a developer login
Their developer support is also pretty good. One thing a lot of people seem to screw up when starting out with the paypal api is not setting the latest version in the configs so don't forget to update that to the latest release. :)
Disclaimer..
Yea I know there is a lot of bad press about paypal and crazy stuff happening, but they do get the job done most of the time, its not my fault the customers love to use it.