johnboxall / django-paypal

The button as generated for the IPN payments is not valid strict XHTML.

To fix this, a <p> needs to be added around the <input> elements, and the border attribute must be removed.

I could be wrong, but in step 3 it says to use the PayPalPaymentsForm, when I believe it should be using the PayPalPDTForm.

Since txn_id is the primary way of performing (useful) lookups on the IPN table, maybe you'd consider creating an index at the model level?

I've just wasted an hour or so trying to figure out why my PDT notifications weren't being processed properly. It's because I was testing with DEBUG=False (so I'd get tracebacks via email for failed IPNs).

I propose that any place that tests for settings.DEBUG be changed to look for settings.PAYPAL_DEBUG. I don't plan to switch my overall Django DEBUG setting exclusively when I want to toggle between Paypal Sandbox/Production environments.

It would be useful to have a "processed" boolean flag in the IPN table so we can mark payments as processed. As I understand the workflow, when the user returns with a form, I check their IPN in the table and process their payment, but they can just refresh and get another item for free if I don't mark it as processed.

Could this be included in django-paypal so I don't have to create another table just for this field?

It is sometimes useful to include various data in the GET parameters of the notify URL for PayPal IPN, e.g. to be notified of which user this transaction is for. Can these parameters be passed back to the signal for handling?

I have added a custom image for each paypal item. The code is below:

def get_image(self):
    if self.initial.get("image", None):
        return self.initial["image"]
    else:
        return {
            (True, True): SUBSCRIPTION_SANDBOX_IMAGE,
            (True, False): SANDBOX_IMAGE,
            (False, True): SUBSCRIPTION_IMAGE,
            (False, False): IMAGE
        }[TEST, self.is_subscription()]

In topic "Using PayPal Payments Standard IPN", item 5, the signal is named "payment_was_succesful", should be "payment_was_successful" (missing "s")

Kind of a minor quibble that can't be easily changed, but django.contrib.auth.models.User uses first_name and last_name so it would probably make sense to use that instead of firstname and lastname.

Granted, not an easy change at this point without backwards-compatability code.

I am running an e-commerce website for client, which is Polish and uses django-paypal. System locale for Django process is thus pl_PL.UTF-8. In production environment, IPNs weren't processed correctly (p is PayPalIPN instance left in database after callback):

In [7]: p.flag
Out[7]: True

In [8]: p.flag_code
Out[8]: u''

In [9]: p.flag_info
Out[9]: u'Invalid form. (<ul class="errorlist"><li>payment_date<ul class="errorlist"><li>Wpisz poprawn\u0105 dat\u0119/godzin\u0119.</li></ul></li></ul>)'

The error message in Out[9] is Polish for "Enter correct date/time". I managed to track it down to Django's DateTimeField, which uses time.strptime() to parse time, which is locale-aware for some formats - and PAYPAL_DATE_FORMATS uses %b format, which is locale-sensitive abbreviated month name. I could not find in library a locale-insensitive version for this, neither way to temporarily switch the locale.

I was not able to reliably and cleanly fix this issue, but I managed to work around it by patching standard/forms.py to use third-party dateutil module if available, which is locale-blind. My quick-and-dirty patch is available at http://gist.github.com/232165 .

Can we use logging instead of prints here ?

    if settings.DEBUG:
            print 'PayPal Request:'
            pprint.pprint(defaults)
            print '\nPayPal Response:'
            pprint.pprint(response_params)