

Ask HN: Is it ok to bypass the final PayPal confirmation? - MattBearman

I'm currently updating BugMuncher to use the PayPal API for payments, and it's always frustrated me that the process required by PayPal is:<p>1 - click order button on your website
 2 - login on paypal.com
 3 - review and confirm order on paypal.com
 4 - review and confirm order on your website<p>It's always seemed to me that step 4 is unnecessary, but all the PayPal API documentation says it has to be there.<p>Normally I wouldn't dream of going against PayPal, as I know they love to freeze accounts, but I just ordered an SSL certificate from NameCheap, paying with PayPal, and they bypassed step 4! Once I confirmed on paypal.com, it took me to an order complete page on NameCheap, I didn't ever confirm the order on their website.<p>Do you think that if a big company like NameCheap get away with it, it would be ok for me to do?
======
patio11
Which Paypal product, specifically, are you using? Many of them do not require
_customer confirmation_ after the redirect, they just require _that you
confirm_ the purchase took place (i.e. all you have to do is flash a message
saying "OK, we charged you money." and let the folks get back to whatever they
were doing.)

e.g. BCC has sent people to a page which says "Thanks for your order" and has
instructions on the next step they should take, for the last five years, and
this has never been an issue.

I emphasize again that it depends on the product you are using. (Plus, if
you're big enough to have an account rep, you can get requirements waived.
Same goes for just about every company that exists, by the way. The TOS, heck,
the API itself is negotiable if you bring in enough business.)

~~~
MattBearman
Thanks for the detailed response, I'm using the API to set up recurring
payment profiles.

I see what you mean about bigger companies having more clout, so it's probably
best I just keep the double confirmation in for now at least.

------
dholowiski
If I were you I would skip paypal all together and use someone else. Paypal's
IPN (a sort of API that you can use with free business accounts) is beyond
terrible, and their real API is only available with paid accounts. If you live
in the USA there's no excuse for using Paypal. If you live outside of the USA,
you just have to look harder for alternatives (I found fastspring, for
Canada).

To answer your question - if you're using the real API (not IPN) then you can
handle the full transaction on your site, without ever sending the user to
paypal. I think you get this with paypal 'website payments pro'.

~~~
dangrossman
> Paypal's IPN is beyond terrible

Why? It does its job, and it does it reliably. Compare to the new hotness
"Stripe" which attempts to offer an IPN lookalike, but theirs doesn't actually
work since it doesn't re-notify if your endpoint is down/broken. PayPal's
does.

> If you live in the USA there's no excuse for using Paypal

I'll give you a few excuses:

* 232 million registered accounts

* Brand recognition and trust your site doesn't have yet

* The only way for most US small businesses to accept the preferred payment method of many countries where credit cards are not the norm

* Lower transaction fees than almost any merchant account and 3rd party payment provider, with no required monthly fees

* Sophisticated fraud detection for free

* 100% immunity from fraudulent payments for shipped goods for registered buyers

If you're going to suggest someone else not use PayPal, at least give them a
truthful reason.

> I found fastspring

Which charges 5.9%-8.9% instead of 1.9%-2.9% and pays you twice a month
instead of daily (PayPal Auto Sweep) or whenever you want... among all the
possible alternatives to PayPal, that's one of the worst I've seen. Even if
this company assigns you a personal account manager who sits at a desk all day
just waiting to take your calls, it's irrational to give up 6% of your profit
margin to use them. Some businesses don't even _have_ a 6% profit margin,
handing 5.9% of every payment to the processor (that's only giving 1-2% to the
card network) would simply put them out of business.

~~~
dholowiski
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&c...](https://cms.paypal.com/us/cgi-bin/?cmd=_render-
content&content_ID=developer/e_howto_admin_IPNReference) 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
> 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.

