4 ms·

Why is Paypal's IPN Terrible? becuase it's terribly complicated and poorly documented. The documentation is scattered and dis-organized and there are dozens of

Why is Paypal's IPN Terrible? becuase it's terribly complicated and poorly documented. The documentation is scattered and dis-organized and there are dozens of different events that can happen, and you have to be prepared to handle them all. Take a look at the IPN Variables: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_admin_IPNReference https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c... There is so much room for error, or for the programmer mis-interpreting what a field means, compared to the other, simple solutions. I'll give you a good reason for not using paypal... paypal freezes accounts all the time, for reasons as simple as 'you made too much money too fast'. Google it, or just watch the front page of HN for a month. I'm not risking my whole business just to use paypal. I understand that you think the rates are high on fastspring, and there are many alternatives if you live in the USA. Try living in another country, we don't have the same alternatives that people in the USA do. As far as I know this is the _only_ alternative in Canada that doesn't require a monthly fee, credit check, merchant account, and that does have an API to sell a SAAS product.

dangrossman 15y ago
> Why is Paypal's IPN Terrible? becuase it's terribly complicated and poorly documented. Hardly. It's an HTTP POST to a script. What could be easier to handle? Read the mc_gross and item_number and update your database. If you want to verify the POST came from PayPal and not someone else that found your secret URL, then you change one variable in the POST data and send it back to PayPal to get a verification response. My PayPal scripts are a couple lines of code. Any competent coder could write and test an IPN script in half an hour... even without reading the docs! Just use the sandbox to send a test POST, look at what you get and write the code to update your DB using the appropriate variables. An IPN handler is a lot less code than integrating any real payment gateway I've used... and PayPal's IPN was easier to handle than Amazon Payments' or Google Checkouts' equivalents. > I'll give you a good reason for not using paypal... paypal freezes accounts all the time, for reasons as simple as 'you made too much money too fast'. So do all payment processors ever in all the history of credit card payments as consumer instruments. This is not a PayPal issue. The only reason you hear this about PayPal is because these businesses didn't try anyone else. Standard merchant account application asks you your estimated gross monthly volume and average ticket size. If your actual volume deviates from this significantly ("you made to much money too fast") they will freeze your account until they can re-evaluate the processing risk. > I'm not risking my whole business just to use paypal. Those stories you see on the front page of HN would've played out the same if they did the same things with a different processor. It's not using PayPal that risked their whole business, it's not informing their processor before launching a product that would change their volume and ticket size, not informing their processor before collecting thousands of charity donations without being a charity, not informing their processor before selling tens of thousands of preorders for an indie game that doesn't exist, etc. The risk would be there when you do any of these things no matter who you use to process the payments.

dangrossman 15y ago

> Why is Paypal's IPN Terrible? becuase it's terribly complicated and poorly documented. Hardly. It's an HTTP POST to a script. What could be easier to handle? Read the mc_gross and item_number and update your database. If you want to verify the POST came from PayPal and not someone else that found your secret URL, then you change one variable in the POST data and send it back to PayPal to get a verification response. My PayPal scripts are a couple lines of code. Any competent coder could write and test an IPN script in half an hour... even without reading the docs! Just use the sandbox to send a test POST, look at what you get and write the code to update your DB using the appropriate variables. An IPN handler is a lot less code than integrating any real payment gateway I've used... and PayPal's IPN was easier to handle than Amazon Payments' or Google Checkouts' equivalents. > I'll give you a good reason for not using paypal... paypal freezes accounts all the time, for reasons as simple as 'you made too much money too fast'. So do all payment processors ever in all the history of credit card payments as consumer instruments. This is not a PayPal issue. The only reason you hear this about PayPal is because these businesses didn't try anyone else. Standard merchant account application asks you your estimated gross monthly volume and average ticket size. If your actual volume deviates from this significantly ("you made to much money too fast") they will freeze your account until they can re-evaluate the processing risk. > I'm not risking my whole business just to use paypal. Those stories you see on the front page of HN would've played out the same if they did the same things with a different processor. It's not using PayPal that risked their whole business, it's not informing their processor before launching a product that would change their volume and ticket size, not informing their processor before collecting thousands of charity donations without being a charity, not informing their processor before selling tens of thousands of preorders for an indie game that doesn't exist, etc. The risk would be there when you do any of these things no matter who you use to process the payments.