In the documentation for IPN, it says things like "Check email address to make sure that this is not a spoof". But I cannot see what to do when that is the case, and how I tell PayPal I want to reject a transaction. E.g. do I sent back a 400 instead of a 200? Or alter the POST data in some other way?
Or do I just ignore the message? (The problem with that is that PayPal will keep re-trying, which is wasted bandwidth for us, but also means it takes longer for the user to hear about the payment failure.)
Background: I realize sending it back to PayPal and getting the VERIFIED message back handles most security issues. But in my case, there is some unique ID information in the custom field. If that is missing, or does not validate against the DB, I want to reject the payment. I want my customer to see it failed, so they know to go and use a fresh form. The alternative is to accept the payment, and then have to involve a manual process trying to work out who the payment came from, and then possibly do a manual refund. (Other reasons to do this might be that the inventory has sold out in the split second between them seeing a product on the site and clicking BUY.)
The payment didn't fail. PayPal is notifying you that the payment succeeded: not asking you whether you want to accept it. You can't reject it at this stage.
Simple send back a 200 code to let Paypal know you received the IPN, otherwise Paypal will try to send the IPN response repeatedly.
IPN is Instant Payment Notification. After the payment paypal notify you the result of the payment. Check if connection VERIFIED, and next if if the payment is Completed and mark the result in the database.
If you say to PayPal the ipn address in the cart, Paypal send you the notification. You can't say to paypal: "yes please, send me a notification" and when receive say "why you send this?" If you put ipn in cart form you can provide a ipn url with code 200, not 404. Or remove ipn value in the cart form
Related
I'm using paypal adaptive payments to make transaction via paypal. Although few of transactions are taking more than 6 hours too receive IPN.
I've gone through forum posts and their documentation, I came through - https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/
"Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
The callback is taking more than 6 hours is way too much. any suggestions ?
I've built several custom carts. On average, I see the PayPal IPN come back within 2 minutes at the longest, and usually recurring payments take longer than single payments because they send two IPN messages, not just one, on the initial setup. I usually take the 'custom' property and put a unique identifier that I have permanently cookied. So, even though I may see an initial IPN come in on a recurring payment, I wait for the one that says that txn_type is subscr_payment and also that payment_status is Completed. You can't really trust a subscription payment as being paid unless you see that second message. And if it's a single payment, then I look for txn_type to be web_accept and payment_status to Completed.
The way I handle things is to redirect the customer to PayPal to purchase using the form button technique. The customer pays and then gets redirected (thanks to the form hidden vars I created initially) back to my own custom cart URL that I specify. I call that URL the payment-confirmation script. I display a message with a progress bar to please wait while their payment is being confirmed with PayPal. I hold them there 10 seconds and then redirect to the receipt. It is on the receipt where I check the database to see if my IPN script has already processed this order. If not, then I redirect them back to the payment-confirmation script again for another 10 second progress bar delay. My receipt uses a session cookie to ensure I never send them into a loop more than one time to the payment-confirmation script. So, the customer waits another 10 seconds and then comes back to the receipt page, where I test again, reading my permanent cookie on the 'custom' property that I saved, versus the 'custom' property that comes in from the IPN that I use as the order key in the database. Usually within the first or second 10 second delay, the IPN has come in and I can proceed. However, if the IPN has still not come in, then I redirect to a friendly error message saying that their payment cannot be confirmed and to call our call center to remedy the issue. Our call center techs then see the delay problem in PayPal, back the other transaction out, and sell to the customer over the phone manually, instead.
My question is very simple and no related to any kind of troubleshooting its just to get the information about the IPN
Lets say:
I have a system Paypal integrated activated IPN and working fine
someone tried to Price Jack a product and changed the price from 200$ to 2$
My IPN detected that and informed me about that issue (through mail as i set in my IPN).
My question is will paypal still process that payment and accept that 2$ and redirect user to my success page? or it will stop the processing the payment?
Ofcourse I have the proper handling of that and will not update the database
but question is will those 2 dollar will get processed in my paypal?
if yes is there any way to stop paypal from processing?
Note that there're multiple ways to protect your payment button code (price and other details) and also a very rare chance that an HTTPS payment request got "price-jacked" by a man-in-the-middle attack or malicious fraud activity, but still a valid question to be clarified.
In this case, the $2 will be processed just as a normal transaction to PayPal, and the asynchronous IPN will only be triggered by the event of payment completion. That's when your website backend will reconciliate and detect the "price-jack" by IPN callbacks, after the payment processing but not before.
Eventually, the transaction (of $2) that has taken place would be in sccope of fraud activity & dispute issue, and to be reported and handled by PayPal customer service
I've recently wrote my IPN listener script to manage purchases for my website. Whenever a user submits a payment, there is a custom hidden field with their USER ID as the value. I know that to identify if the message is a REFUND, it'll have the post parameters:
reason_code = refund
Now my question is, when PayPal notifies my IPN listener of the refunded item, will it still send the exact same post data (including my custom field so I can manage the user accordingly due to thei) that was sent when they purchased the item?
I hope I made my message clear and that it's not too confusing.
Thank you.
Yes, when you issue a refund you will receive the same custom variable back in the refund that you passed over when you charged the buyer. It will have the same value that you set. I also just tested this to make sure there were no issues with this feature, and it is working as it should.
I have Google for almost 10 hours and it seems a bit unclear.
When I create a "Subscribe" button with my own "notify_url" will PayPal send an IPN to that URL when each recurring payment is made?
Paypal will use the same notify_url that you pass for every recurring payment on that same subscription. An example, may help.
If you pass a notify_url that contains the order id, like:
http://www.mydomain.com/paypal_ipn/{$order_id}
Then when somebody buys a subscription, Order #1, with a recurring payment for $1/day for a month, you will receive IPN data at "http://www.mydomain.com/paypal_ipn/1" for the initial 'txn_type=subscr_signup' and a 'txn_type=subscr_payment' every day until one of the following things occurs:
the user cancels the subscription, at which time you will get a 'txn_type=subscr_canceled'
their credit card expires 'txn_type=subscr_failed'
a month later when the subscription expires 'txn_type=subscr_eot'
On the next order, Order #2, all the IPN calls for that subscription will go to "http://www.mydomain.com/payapl_ipn/2"
Paypal won't store the notify_URL, you need to pass it everytime you send a transaction to paypal for processing. Notify_URL is one of the attributes of the hash; so when paypal receives your transaction hash, it will pick up whatever values you set for each of the attribute and act accordingly. Your understanding is correct!
Just noting that i am also seeing a possibly related problem for echecks where the later clearing ipn is not using the dynamic url that was specified in the originating transaction. First ipn advising pending payment goes to dynamic url
Second ipn advising cleared echeck goes to stored notification url not the dynamic url.
all other instant ipn's are fine and the 2nd ipn is received - but at the wrongurl - can see it in the logs.
any ideas appreciated - pending response from paypal.
Can we assume that the payment is completed for a transaction when the customer is auto returned to our site?
Paypal advices us to use their IPN system for other types of payment, like an e-check, but also tells us to tell the customer something along the lines of "Thank you for your payment. Your transaction has been completed, and a receipt for your purchase has been emailed to you. You may log into your account at www.paypal.com/ca to view details of this transaction."
What are the downfalls of not using IPN, and just assuming the payment is completed when paypal auto-returns users to our site?
Thanks!
Relying solely on the return url is a pretty bad idea. It would be easy for a bad guy to skip payment and just visit your return url to complete the order.
There is a pretty comprehensive article about this here
No.
However, using the Auto Return option in your Paypal account in conjunction with Payment Data Transfer (Profile/My Selling Tools/Website preferences/Website Payment Preferences) will give you payment confirmation data in the URL you use for Auto Return, for example:
www.yourReturnURL.com?tx=9XV61416UY0043254&st=Completed&amt=9%2e00&cc=USD&cm= 9601&item_number=2
You need to verify this data (anyone could send a fake request) by sending the payment reference ("tx" parameter above) back to Paypal and waiting for a VERIFIED response.
This last step is identical as the one you take for the IPN (Instant Payment Notification) implementation.
With PDT you get the notification instantly. PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT.
More info here: https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNPDTAnAlternativetoIPN/