Closed bkeating closed 13 years ago
The code you refer to builds a list of recurring payment objects with the assumption that for every p_resultN key value in the response data (where N is 1 or greater) there will be always be five other corresponding keys: p_pnrefN, p_tenderN, p_transtimeN, p_amtN and p_transtateN.
At least the last of these keys (p_transtateN) is missing in the response, and maybe others are too.
It's years since I've worked with PayflowPro (happily) but my best guess is that they've either changed the key names returned for recurring payments, or the code should not assume that all the other keys are present in all cases.
To fix this, first make sure that the p_WHATEVER values the code is looking for are correct for the latest version of the PayflowPro API. The problem might be as simple as a renamed key, since the code isn't necessarily up-to-date.
If the key name is right but it isn't always present in responses, you will need to check for the key name in the unconsumed_data dictionary rather than always pop-ing it. Something like this should do:
while ("p_result%d" % recurpaycount) in unconsumed_data: my_transtate = None if ("p_transtate%d" % recurpaycount) in unconsumed_data: my_transate = unconsumed_data.pop("p_transtate%d" % recurpaycount) payments.append(RecurringPayment( p_result = unconsumed_data.pop("p_result%d" % recurpaycount), p_pnref = unconsumed_data.pop("p_pnref%d" % recurpaycount), p_transtate = my_transtate, p_tender = unconsumed_data.pop("p_tender%d" % recurpaycount), p_transtime = unconsumed_data.pop("p_transtime%d" % recurpaycount), p_amt = unconsumed_data.pop("p_amt%d" % recurpaycount)))
Hey James,
Thank you for your reply. It was exactly what I needed. The live RecurringProfile I was testing against did not have the p_transtate
and p_amt
values on record on some of it's first charges while the test profile i was using did. PayPal_ToddS's reply in this thread (https://www.x.com/message/180630#180630) makes me think these fields may not have existed when the first few charges went through on the profile. The test profile, created around the same time however, worked before this fix. So im not sure this was my case.
I found that .pop()
allows a default value. Here is the change: https://github.com/bkeating/python-payflowpro/commit/1fe580653d843b2f5dadfa647b0aa7a0154708d1
Thanks again!
FIXED: look at replies below. This issue is not related to live vs test servers.
It seems
payment_history_only=True
will work when pointing to https://pilot-payflowpro.paypal.com but when using the live server (https://payflowpro.paypal.com) I get a much different response. Look at my interactive Python session below to see what I mean.The (directly) related code in python-payflowpro as far as I can tell is: https://github.com/bkeating/python-payflowpro/blob/master/payflowpro/classes.py#L329
Ideas as to whats going on here? Is there some testing that can happen before doing a history_only inquiry?