I recently converted from basic Paypal payments to Chained Payments...and I have a few questions if you guys would be so kind to help out.
First, when I setup a PayRequest, I also create an order record in the database. Previously with my basic Paypal implementation, I passed that OrderId in the custom field as part of the form post to Paypal. I would then get that OrderId back in the IPN handler and use it to mark the order as paid or whatever based on the response from Paypal IPN.
Now I am wondering what is a good unique value for my locally created order? Should I use the paykey to look up the order on the IPN callback? Or should I just set the trackingId property of the PayRequest to be the order id and pick up in the IPN callback Request object?
Secondly, there is a returnUrl and ipnNotificationUrl for the PayRequest. Should the returnUrl process the IPN callback or does the ipnNotificationUrl only should do that?
The reason why I ask is because the return url must be able to show the buyer the status of their payment and the transaction info, the same data that I get in the IPN callback.
Thanks for the input guys, once I get these two minor details ironed out, I'll be good to go!
I would add your record ID into the tracking ID parameter of the Pay request like you mentioned. That way you'll get it back in your IPN similar to what you're doing with the custom parameter now.
The IPN notification URL is what you want to set in order to trigger IPNs for the Pay request. You do not want to use the same URL for return because then the script would actually run twice.
Related
Our customers sends their requests for our products via email. Their requests are saved in our database and after we check their requests, we want to send them an email which contains the paypal payment link. To execute this, I am using BMCreateButton method of ButtonManager API of Paypal.
https://developer.paypal.com/docs/classic/api/button-manager/BMCreateButton_API_Operation_NVP/
This method returns EMAILLINK parameter and I am using this parameter in the email to redirect to user to paypal payment page. This method also returns HOSTEDBUTTONID and I am saving this parameter and EMAILLINK parameter to the database to make a relation between the email link(hostedbuttonid) and the user request.
For the payment notifications, I think my only choice is IPN of Paypal. I developed a page to handle the IPN messages from paypal and it works fine but the problem arises when I want to relate between the payment information with the email link that was sent to the customer. I mean I want to know for which request this payment was made. IPN message does not return any information about the HOSTEDBUTTONID. It returns btn_id(different than the HOSTEDBUTTONID), txn_id and ipn_track_id but none of them is useful to relate the customer request( or email sent) with the payment.
Do you have any suggestion about my issue? Or do you think I should use another way for sending the payment email to the user instead of BMCreateButton method of ButtonManager API.
In the BMCreateButton call, where you're setting up the standard PayPal variables for the button, add the CUSTOM parameter. Within that you can pass any value you want (up to 256 char.) and then that same value will come back in the IPN so you can relate it accordingly.
If you have a specific Order ID you could use the INVOICE field instead, and that would come back in IPN as well.
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.
As recommended by PayPal I am using a combination of the PayPal API and the IPN to create a 'Adaptive Payments' flow.
When my IPN listener receives a new notification from PayPal I have two options (after security checks):
1) Use the received data to make direct actions in my website (for example set a preapproval as approved)
or instead a more secure and clean way (I think):
2) Detect the transaction type variable (or other identifier) and request more details from PayPal accordingly.
For example if the 'transaction_type' is 'Adaptive Payment Preapproval' then I will use the received 'preapproval_key' to request the preapproval details using the PreapprovalDetails API call and then use the received data of that call to set the preapproval as approved.
Is this (option 2) the better way to go?
Thanks.
In general there is probably enough information in the IPN for you to act on, but IPNs are pretty confusing what with all the optional fields and the way that there is no payment_status or txn_id on subscribe events, and no subscription information on payment events, so marrying them up can be interesting. You may well find it easier to understand if you go ahead and get the relevant information from them for each IPN via their API as you suggest.
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.
I wanted to use Paypal's IPN service to verify payments for a recurring subscription charge for my website. How do you tie the IPN confirmations to a user in your site?
The IPN confirmation message has a name, email, paypal ID, recurring payment ID, but it seems to not give a unique identifier since I don't know where the paypal ID or recurring payment id comes from and it may not be trivial to uniquely match up the name/email that a user has on their paypal account (or entered there) with the name/email I have for them on my site (there may be many John Smith's and the person may choose to use a different email.)
1) When I send the initial payment request to Paypal, I can attach a unique UUID in the URL I ask them to send back to me, so if I save that unique ID for that user I can match that payment confirmation to the user who initiated it. Am I making that harder than it is? Is there an easier way?
2) Also, for a recurring/subscription charge, does paypal always use the URL I specified with the initial payment initiation? Does anyone have practical experience using the recurring Paypal payments with IPN's, does it reuse that unique URL? Or do I have to associate the Paypal ID's with the user after the first recurring payment is received?
Attaching unique data to the payment request is pretty much the accepted way to do it.
I don't have any experience with recurring charges.
I recently also set up some reoccurring payments with Paypal.
I actually wanted people to register as members after paying for the subscription, if they wanted to. As having to sign up as a member could add some friction to the sale process. So I don't send any user info along with the Subscribe button.
What my IPN script does is generate a unique activation code tied to the Paypal subscriptionID in the Activations table, then it sends this code to whoever paid for the subscription, with instructions on how to activate.
At the point of activation, you need to register or login. At this point the userID is added to the relevant row in the Activations table.
When the EndOfTerm IPN notification comes in the IPN script looks up the userID from the Activations table based on the SubscriberID given in the IPN. Then I can do whatever I need to do to that user to disable their subscription.
At all time the URL of the IPN script remains the same.
1) You can send an 'item_number' parameter with the initial subscription setup, which will get passed back to you. I'd suggest embedding an identification token in it.
2) If you mean the 'return' parameter, no, that's for sending the user to at the conclusion of the subscription setup. The renewal is automatic and doesn't 'ping' that page.
1) You want to be using the item_number parameter. Set this in your HTML form shown to the customer, and it will be returned to you by the paypal IPN, so you can put a database row ID in here, and use it to match up to the right person later.