Tell HN: PayPal is borked for most merchants
11 comments
What surprised me (last night as I wrote my paypal integration) is that Paypal's API is broken by design. Horribly.
Even their new APIs are based on the IPN "reliable messaging" notification system. But there's nothing reliable about it:
* You receive a message from Paypal
* You post it back to Paypal
* You get back "VERIFIED" or "INVALID"
* The burning stupid: This postback is also what acknowledges the message and stops the retries.
In other words, your code must either:
1) Commit transactions in your database based on unverified information, then figure out how to revert the changes if the message comes back invalid. Or:
2) Verify the message (stopping retries) and then try to commit your transaction, possibly failing and losing the IPN message entirely. Your customer may never get his product enabled.
Oh, and let me mention that the verification postback can happen only once. It's impossible to build an idempotent handler for IPN messages.
Paypal's documentation and sample code push you towards solution #2. This is just negligent. I've built porn-serving infrastructure that was a thousand times more robust. People trust this with real money?
And don't get me started on Paypal's near-useless morass of documentation. And the fact that IPN messages don't have any kind of unique identifier.
Technology FAIL.
Even their new APIs are based on the IPN "reliable messaging" notification system. But there's nothing reliable about it:
* You receive a message from Paypal
* You post it back to Paypal
* You get back "VERIFIED" or "INVALID"
* The burning stupid: This postback is also what acknowledges the message and stops the retries.
In other words, your code must either:
1) Commit transactions in your database based on unverified information, then figure out how to revert the changes if the message comes back invalid. Or:
2) Verify the message (stopping retries) and then try to commit your transaction, possibly failing and losing the IPN message entirely. Your customer may never get his product enabled.
Oh, and let me mention that the verification postback can happen only once. It's impossible to build an idempotent handler for IPN messages.
Paypal's documentation and sample code push you towards solution #2. This is just negligent. I've built porn-serving infrastructure that was a thousand times more robust. People trust this with real money?
And don't get me started on Paypal's near-useless morass of documentation. And the fact that IPN messages don't have any kind of unique identifier.
Technology FAIL.
This is wrong. All you have to do is return a "200 OK" and PayPal will stop sending IPNs. You don't even need to perform the validation postback at all. It's completely optional.
As bpreit pointed out, sending the "200 OK" response is what stops the IPN retries. The verification postback is a red herring; you can do it zero times, one time, or a hundred times, and if you don't send a "200 OK" response to the IPN, it will be retried.
So the correct strategy is: 1. Receive an IPN from Paypal. 2. Post it back to Paypal. 3. Make sure the response is VERIFIED. 4. Idempotently handle the payment. 5. Send "200 OK" response.
Step 4 needs to be idempotent in case your server dies or times out before sending the 200 OK response, but there's no way to avoid this without potentially losing messages. (I can't remember what the theorem is called, but in a lossy system it's impossible to avoid both messages being lost and messages being duplicated.)
Paypal has 99 problems, but its IPN processing isn't one.
So the correct strategy is: 1. Receive an IPN from Paypal. 2. Post it back to Paypal. 3. Make sure the response is VERIFIED. 4. Idempotently handle the payment. 5. Send "200 OK" response.
Step 4 needs to be idempotent in case your server dies or times out before sending the 200 OK response, but there's no way to avoid this without potentially losing messages. (I can't remember what the theorem is called, but in a lossy system it's impossible to avoid both messages being lost and messages being duplicated.)
Paypal has 99 problems, but its IPN processing isn't one.
This happens far too often. It's time to get a real merchant account...
A couple of useful links I found on here:
Use http://activemerchant.org for rails implementation of authorize gateway and http://feefighters.com to find and setup a merchant account (awesome service)
A couple of useful links I found on here:
Use http://activemerchant.org for rails implementation of authorize gateway and http://feefighters.com to find and setup a merchant account (awesome service)
Yet another validation of our (fivesecondtest.com) decision to stop supporting PayPal. No other "financial institution" fails so comprehensibly at so many basic fundamentals. My merchant account costs me a small fortune, but it's worth it for the amount of pain and suffering PayPal have caused us...so glad we're not having to suffer again through this.
[deleted]
OT, but is the PayPal bashing necessary? I know everyone loves beating up on PayPal, but for a big company they do still bring some innovation to the space - take their micropayments service (https://micropayments.paypal-labs.com/). How else can I process a $1 payment and only pay 10¢?
Innovation is only valuable if it improves the situation. Paraphrasing George H Smith, "Inventing a new method of torture may be innovative, but that doesn't make it good."
Thanks, I just had a weird message from a customer saying they never received their order... but I have no record of a payment from them. I suspect this is the cause :(
I am just getting into doing paypal payments through one of my websites. I found a opensource framework for C# and looks like it works well. I only expect payments of up to $5.00 at the moment, but I am open to new solutions. Anyone have a better place to make payments for purchases on a website?
Hopefully, there will be a framework for C# developers for this alternative...
Hopefully, there will be a framework for C# developers for this alternative...
Uh oh. Looks like their update didn't go as planned. Last notice says they're rolling it all back.
We just did a test transaction on our account with Payflow Pro and everything seemed to work fine. Wondering if it is fixed and we just missed some transactions earlier in the day.
Or maybe we are just lucky and did not get affected?
Or maybe we are just lucky and did not get affected?
[deleted]
Our payments using payflow pro and payflowpro.paypal.com seem to be processing normally. I think this only affects one processor, or merchants using "Website Payments Pro Payflow Edition," after reading the linked page.
They are supposedly keeping merchants up to date here: https://www.x.com/community/ppx/system_status/payflowstatus/blog/2011/03/18/bulletin-system-maintenance-notification
That page hasn't been updated for the last 2 hours.
What they aren't mentioning is:
- The new endpoint for PayFlow processing is down (payflowpro.paypal.com [66.211.171.141])
- The old endpoint for PayFlow processing is also down (216.113.190.148)
- When it was up earlier delayed capture payments failed
- Anything related to trying to process new recurring payments also seems broken
Thanks PayPal !