Causing havoc on the site. Full dump of all post vars during the notify callback doesn't show the item_number variable at all. But it was sent.
Has something happened with IPN that I missed?
I just had this problem. The issue is that earlier today, without notice, Paypal have started sending this as item_number1 (note the suffix '1'). This surely must be a bug, because a Google search suggests this behaviour is only supposed to trigger for shopping cart checkouts, and in that case it would be item_number_1 (note the suffix '_1').
If this situation continues, the solution is to update your scripts to read from item_number1, as well as item_number. Paypal may revert this behaviour, if it is a bug (which presumably it is). It might be wise to make them also check for item_number_1, in case they make a change to treat the checkout as a shopping cart in future.
Looks like item_number is now item_number1, which is creating some issues.
Related
So I'm working with a system that uses the legacy NVP/IPN thing from PayPal. The IPN listener URL wasn't set up properly and so they ran a couple weeks worth of transactions with no IPN data coming back. I've set it up properly now, but I'm wondering if there is a way to regenerate that last couple weeks that never had any. Whenever I go to the IPN history page, I just get a this feature is not available message. I know it's now working because I can see three transactions in our database (that come through the IPN listener)
On another note, if I go to the download history page and try to click download, the page refreshes but nothing happens. I don't get a report or anything, any idea why?
It sounds as though you're looking for the IPN history page, where you can resend IPNs: https://www.paypal.com/us/cgi-bin/webscr?cmd=_display-ipns-history
Late edit: changed title to better reflect the true question (it's not about regenerating IPNs). And the answer is it's not possible. Instead, for past IPN-less activity one must manually import a CSV obtained from www.paypal.com account home -> Reports -> Activity Download
This is the URL: https://business.paypal.com/merchantdata/reportHome
If once in the Activity Download, "Create Report" does not work properly (e.g. "nothing happens"), contact PayPal's support for assistance as that is not normal.
Beginning sometime around 03/08/2017 we have noticed some unusual behavior with some (not all) of our PayPal IPNs. PayPal seems to be rolling out some kind of changes, there are a few others reporting other things, like: QueryString values removed from the IPN endpoint by PayPal
It looks like there are multiple versions of PayPal's system sending the IPNs, some of them contain notify_version=3.8 and some contain notify_version=UNVERSIONED.
The main problem is IPNs from "3.8" have receiver_email, but ones from "UNVERSIONED" do not.
In some cases we receive duplicate IPNs at the same time, one is the "3.8" version and one is the "UNVERSIONED" version. It seems like both versions of PayPal are handling the same thing at the same time. The "3.8" version seems to always successfully confirm the IPN and the "UNVERSIONED" version seems to always respond with "INVALID".
Some users are reporting that PayPal is unencoding the value we send for return (the URL that comes after the checkout). For example, a URL like http://example.com/some%3Dvalue sometimes gets decoded to http://example.com/some=value which is not correct and leads to a 404.
I am aware PayPal is set to roll out new changes on 03/29, relating to stricter compliance with their data formats, but we have already verified we are in compliance with this and this is still a few weeks away.
After a few days, IPNs returned to normal without any changes. PayPal never responded to our support emails or acknowledged any issue.
I'm using ASP.Net Membership Provider for logging into the premium content of this web site. The content isn't downloads, it's web pages of information and discounts, etc. That part is done. We want them to also have a PayPal Subscription annual payment to see the premium content. I would like ASP Membership and PayPal Subscription to work together as much as possible, but for the minimum I am thinking they will have to create a MemberId before they pay. Then I will send that MemberId to PayPal to associate the two.
I think I can do that like this:
Set "Auto Return" on in the interface so that it will redirect to return URL when payment is made.
Set "return URL" query string to MemberId. This requires not using the precompiled "Saved" buttons. I'll have to set it in Code Behind with Name Value Pairs, "NVP" to PayPal. I was hoping to just paste the stupid button.
But then, there were those "Advanced Variables" in the Button maker. Problem was they are compiled into the Saved button, so I can't change them for each person. But maybe that one parameter could be separate from the compiled parameters? Is this better than hacking the return URL? Are "Advanced Variables" good for anything?
All the details about the transaction will be POSTed to the return URL if I put in the right code, which might be rm=2. (Right?) Then I can record it.
This process is said to be unreliable, though, and PayPal recommends using a secondary system that they have, "IPN". PayPal sends the transaction details to me. I send them back http 200 code. Then I send it back to them in the same order I got it. Then they send me http 200. Then we all know it's good. This sounds like a few hours research to me, but if you've already done it once, it sounds like copy and paste. I hate reinventing the wheel. Is there a .Net sample of this IPN handshake/dance?
Also, if I do the IPN thing, maybe I don't need Auto Return. Maybe I add MemberId to "notify" URL instead of "return" URL. Then PayPal can handle the confirmation page, email, etc. Is that better?
Assuming we get the Subscription paid for and recorded with the MemberId, at least once per user session, after they log in, I have to check if they have paid their PayPal subscription and if it's up to date. "GetRecurringPaymentsProfileDetails" does this, but it is an API operation. That makes sense, but I was hoping to avoid learning their REST API. (Is there a "NVP" version?)
REST API OAUTH tokens expire every few minutes, but the only way it tells to get one is by using "Bash" to "cURL" some Linux commands. Again, this seems like the kind of thing that would only ever have to be written once. Does this already exist as a sample code somewhere?
(I don't want to use the API to do the Subscribe, because I don't want the Credit Card numbers to ever go to our site. Too much liability. That's why I wanted PayPal.)
Will this even work? I know PayPal has 18 ways to do everything and they all exclude each other, and I'm just getting the feeling that I'm creating a patchwork of unrelated ideas to fool myself into believing there's a light at the end of the tunnel. I've already been researching and experimenting for 10 hours or so. I really thought, going in, I'd just be pasting a stupid button.
If you want to just "copy the stupid button" then you'll have to stick to Payments Standard, and then you'll be limited with what you can do. For example, you won't be able to use GetRecurringPaymentsProfileDetails for a standard subscription.
Instead, you'll need to use Express Checkout and / or Payments Pro. There is indeed an NVP API available for these, and there is also a SOAP/XML version. Details on those can be found here: https://developer.paypal.com/docs/classic/api/
Specifically, for Express Checkout, you'll want SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment, and CreateRecurringPaymentsProfile. Some of those calls are optional depending on how exactly you're configuring things with the checkout flow.
For Payments Pro you'll use either DoDirectPayment / CreateRecurringPaymentsProfile or PayFlow depending on what version they put you on.
In any case, IPN is definitely the way to go for post-transaction processing.
.NET IPN Sample - https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.asp
Alright, I got my Paypal shopping cart set up and working, now I'd like to be able to add discount coupons.
I know I can simply implement the 'discount_amount_cart' variable in my form, but I'm still a little lost when it comes to handling the deactivation of a coupon code.
Let's say A activates the code. Now in my database it will be marked as 'reserved', meaning no one else can use it. Once A completes his transaction, the IPN will mark the code as 'used' and it becomes useless.
But what if A decides to activate the code, but never actually buys anything on my website?
I'm using the $_SESSION variable to save my shopping cart, so once the user returns to my website, the code might still be shown as activated for him. When exactly would I mark it back as 'not reserved & not used' in my database?
I could do this based on time, but this doesn't really feel safe either. Let's say the user puts everything into his basket, goes to Paypal, waits for an hour and then decides to finish his checkout. The discount would still be activated, but in the meantime, it could've already been 'unreserved' in the database and used by another person!?
How would I go about this?
Thanks in advance!
IMHO, this has little to do with PayPal and more about your business rules. If your coupon is single use (globally), then you will be faced with the same issue regardless of any payment flow.
Simply putting it in "cart" and/or any event where a user "activates" said coupon, then just navigating elsewhere in your site, doesn't do anything, [whatever], creates that lag
it could be Paypal, Amazon, your own gateway - it really doesn't matter...but there will be a lag between activation and payment (beyond your control)
I think it's just best to be explicit with your customers and handle it appropriately technically (based on what that explicit messaging is).
You'll see some implementation of "timed purchase" at ticketing sites (e.g. buying a ticket to a game, movie, etc.) - they will have a "timer" for the user to do something (otherwise, the "reservation" is lost).
Hth...
Put an expiry date on coupon use - such as must be used within 10 days of activation. It gives the user urgency to use the coupon and gives you a timeframe to invalidate it.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!