I am trying to set up a simple payment option to paypal, but am having some trouble/confusion with the return and notify URLS. I am fairly new to php and have accomplished this previously in asp, but I have now become lost.
SO my basic paypal form:
<form action="https://www.paypal.com/cgi-bin/webscr" method="post" id="PayPalForm" name="PayPalForm" target="_top">
<input type="hidden" name="cmd" value="_xclick">
<input type="hidden" name="business" value="email@hotmail.com">
<input type="hidden" name="amount" value="0.01">
<input type="hidden" name="item_name" value="Composite Door">
<input type="hidden" name="item_number" value="<?php echo $orderID ?>">
<input type="hidden" name="currency_code" value="GBP">
<input type="hidden" name="cancel_return" value="http://www.mydomain.co.uk/paypal-notcompleted.php">
<input type="hidden" name="return" value="http://www.mydomain.co.uk/paypal-completed.php">
<input type="hidden" name="notify_url" value="http://www.mydomain.co.uk/paypal-completed.php">
</form>
<script>
document.PayPalForm.submit();
</script>
As you can see the form posts to paypal, and then returns depending on the outcome, if failed/cancelled it goes to paypal-notcompleted.php.
If its successful it goes to paypal-completed.php. And this is where I am unable to understand, I haven't set up an IPN, all I want to do is grab some of the variables paypal posts back to me, to run a simple insert query and display some details in a confirmation message to the customer.
Am I allowed to have the notify_url and return_url as the same page?
Why does paypal not post the full expected (as seen here: Notify url of Paypal ) back to the page?
I understand there is something to do with XML and such, but I just figured that I would be able to $_GET the variables that paypal sent back. Has anyone done it this way, can they tell me where I am going wrong?
To return details back to the your return URL you'll need to use PDT. It's very similar to IPN except it's intended for use with your return URL, while IPN is intended for use with a 3rd party IPN listener script on your server.
PDT is fine for simply displaying transaction to the user on the return URL page, but it's not recommended to do any any post-payment processing with PDT (ie. database updates, sending out email receipts, etc.) because there is no guarantee the user will make it back to this page, even with Auto-Return enabled in your PayPal account.
IPN will be triggered every time a transaction occurs regardless of whether or not the user makes it back to your site after completing payment.
The notify URL is used for IPN only, and it would override any setting you have in your PayPal profile for IPN. PDT needs to be configured in your PayPal account profile in order to get data returned to your return URL.
You're going to want to use different URL's for return and notify, otherwise that same code would run twice: once when the user returns to your site, and again from the PayPal IPN POST.
Payment Data Transfer (PDT)
The return
and cancel_return
urls are one-off Payment Data Transfer (PDT) calls primarily so the user completes the transaction on your site. It is only passing information to reasonably help your site fulfil that task. There is no guarantee that a buyer will not quit before returning, so you cannot rely upon being able to do any post-transaction processing using these.
Instant Payment Notification (IPN)
notify_url
is used by the Instant Payment Notification (IPN) process, and called with each change in the transaction status. It is meant to be a complete record of all actions taken during the transaction lifecycle, upon which you can rely to drive backend process, like accounting, order fulfilment or cancellation. The IPN process takes measures to ensure the integrity of the process.
Their purposes are different and thus the information and security involved is different. For pros and cons.
IPN messages can be severely delayed, so use all three variables
Note that while most IPN messages are sent within a few seconds of the PayPal transaction being completed, I have experienced delays of up to several hours, so they are reliable, but not necessarily timely.
I would suggest using all of return
, return_cancel
and notify_url
, as the former two will return immediately, so that you can provide immediate feedback to the user, and update backend data/instigate fulfilment processes, but use the latter as a backup if the user quits PayPal before the being returned. Indicate to your buyers to return to your site to ensure timely processing of their order.
Just have to manage order status so that the IPN doesn't trigger fulfilment if the PDT has already done so, which is basically what you have to do to ensure that repeated Completed
IPN messages don't retrigger fulfilment after the first.
Notify_url
continues to be used for subsequent messages for the same transaction
IPN messages for the same transaction continue to go to the same notify_url
address. I viewed our IPN history, and a Refund
IPN message went to the original notify_url
.
That continues, even if you change IPN preferences, as per https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNSetup/:
The IPN message is always sent to your notification URL unless you have disabled the preference to receive IPN messages. Even though you have not enabled receiving IPN messages in your Profile or you have reset your preference by turning off IPN messages, PayPal still sends IPN messages to the notification URL you specify for a specific payment. IPN messages not sent because you disabled the preference in your Profile will appear in the IPN history when you enable receiving IPNs. After they appear in the history, you can choose whether to resend them.
I am unsure of whether related transactions, like disputes, or subsequent subscription payments, will still use the original notify_url
. Perhaps someone who actually knows can provide an answer.
your notify-url and return url both are different . your return url direct your customer after the successful payment with some return information. by the way notify url is to get the complete transaction details of your customers purchase and which can't be accessed by your customer and this is for your database or storage purpose.