Does PayPal store recurring payments notify_url? - paypal-ipn

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.

Related

Paypal IPN getting delayed by hours

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.

How to explicitly reject an IPN request

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

Paypal Recurring api for find next recurring payment occure

i has been implemented paypal recurring subscription plan in php and paypal recurring also charge via paypal as per recurring periods. but my system didnt find out next recurring was charged or not so how could i know next recurring payment has been charged using paypal api.
i want to help for to upgrade next expire date after next recurring payment changed.
As I understood, you want to see if the user paid or not and change expiration date according to that.
The solution is Webhooks. In your PayPal Application section click on add webhook and choose PAYMENT.SALE.COMPLETED and enter the URL that you want to listen to this event where PayPal will send a post request to this URL when you get a new payment completed.
In the page that corresponds to the URL you entered, you have to do the followings:
Verify that the call is from PayPal, not from another source (in case you are using PHP you can check this: PHP verify Paypal webhook signature)
Parse the data sent from PayPal by reading the body content, not the POST data
Verify that the event is what you need, in this case PAYMENT.SALE.COMPLETED
Verify the amount you received and the currency
Make sure that you have not processed this transaction before and this is too important
If everything is valid, you can save the transaction and do whatever you want, in your case extending the expiry date.
If I understand you correctly, you need to configure Instant Payment Notification (IPN). PayPal's server will POST transaction data to a listener script you have on your server so you can process things accordingly. It happens in real-time.
When working with recurring payments you'll get an IPN when a profile is created, canceled, or suspended, and you'll also get notifications when payments for profiles are completed, failed, etc. You can update your system or send out email notifications accordingly based on the IPN data you get.

Execute tasks after PayPal chained payment is successful

Current Status
I'm quite new to PayPal and I'm currently integrating chained adaptive payments on our website. Already successfully called the PAY API call via the .NET SDK. Money (sandbox enviroment) will be correctly transferred to each participants of this payment (sender, primary and secondary receiver).
Requirement
My goal is to execute vital tasks after the payment is successful (update DB, send mail, ...) or has been cancelled (clean up stuff, ...).
Possible solutions
1)
First approach was to create the payment with actionType set to CREATE, redirect the user to paypal.com (wait for approval), redirect user back to website and execute the payment and then perform the vital tasks. But it seems not to work, the payment will be paid and is COMPLETED before the second redirect.
2)
Another possible solution would be to get the preapproval from the user, redirect back to the website and execute the payment. Haven't tried this solution yet, don't think that this is best practice.
3)
Call PAY with actionType set to "PAY" and wait for IPN. Haven't tried that either, because it is quite difficult to test it locally (even though I've already found this question: Paypal Sandbox Test Tool IPN Simulator in Localhost).
Question(s)
Which solution is best practice? I guess the recommended solution would be to wait for an IPN?
If I'am using IPN how long is the average response time after a payment has been completed? Seconds, minutes, hours? I know it depends on the load of the PayPal webservers and that there are 15 retries over 4 days, but what are some real world numbers?
Can I store additional information (e.g. UserId) about the sender in a payment (besides the memo field) which I then get back in an IPN?
Here is how I do it.
When I'm going to initiate PayPal payment (before I send a request to obtain TOKEN), I create new transaction in my database and set it's status to PENDING. In transaction table I also have userID column, which is foreign key to user table. This way I connect transaction with user.
When transaction is created in my table, I use transactionId value, and save it to PHP $_SESSION variable.
Please note that if you want to support recurring payments, you can provide transactionId to PayPal. This you can do by setting:
"PAYMENTREQUEST_0_INVNUM"=>$transaction->id.
This value will be sent when PayPal sends you IPN request after recurring payment happens.
Go back now to the story
User is redirected to PayPal, and when user fills PayPal username and password, and when user confirms payment details, user will be redirected back to your website and you have to call DoExpressCheckoutPayment to make payment itself.
If the result of DoExpressCheckoutPayment API call is success, that means that transaction was successful and you have money. At this point, you can send email, notifications, or any other important action.
$transactionResponse=$paypal->request("DoExpressCheckoutPayment",$requestParams);//Execute transaction
if(is_array($transactionResponse) && $transactionResponse["ACK"]=="Success")//Payment was successfull
{
//Send email
//Notify user
//Do other important changes in database, for example mark this transaction as successful
Transactions()::model()->updateByPk($_SESSION['transactionId'],array('status'=>'SUCCESS');
}
IMPORTANT NOTE FOR RECURRING PAYMENTS: PayPal can/will send you several IPN requests for the same recurring transaction which means that you have to add logic which will chekc weather specific IPN request is already processed or not. Usually I do it in a way to check weather status of my transaction with transactionId is 'PENDING' or 'SUCCESSFUL'.

Paypal PDT & IPN Question - Can we assume payment is completed when returned to site?

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/