A pluggable Django application for integrating PayPal Payments Standard or Payments Pro

Avoid the b'' decoration under Python 3 when mixing binary (encrypted button contents) and normal strings. Fix the examples in the documentation for encrypted buttons to use the encrypted form.

I've followed the tutorial almost exactly and I got this response:

Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /webapps/developer/applications/ipn_simulator. Reason: Error reading from remote server

Any reason why a 502 Proxy Error is raised when using the IPN simulator: https://developer.paypal.com/webapps/developer/applications/ipn_simulator

I tried the code in the page http://django-paypal.readthedocs.org/en/latest/standard/ipn.html

I certainly added the valid_ipn_received.connect(show_me_the_money) in my views.py But, show_me_the_money has never called. Is it bug?

Hi folks, i am having this issue all day and i cant figure out what should be.

I am running in the localhost the paypal pro, when i submit the payment form i get this error:

requests.exceptions.SSLError
SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:590)

Thanks in advance for any clues and sorry if this is not directly related with the django-paypal.

o/

Hi all,

First of all thanks to spookylukey (and also dcramer) for this super library. I have recently discovered that sometimes Paypal is returning some unreadable characters in the 'flag_info' field and an UnicodeDecodeException exception is raised in the following line: self.flag_info += info of file: django_paypal-0.1.3-py2.7.egg/paypal/standard/models.py

I guess that a try/catch surrounding the line and managing the unicode variable properly should be enough to fix it.

Best regards from Barcelona, Álvaro Vélez.

Hi,

We run django-paypal on a website with a fr_FR locale. When django-paypal receive the callback from paypal, that confirms that the payment has been made, it tries to parse the date from paypal using PAYPAL_DATE_FORMAT (defined in standard/forms.py).

However, as my locale is fr_FR, it is expecting the names in the date in french, and it fails. It returns that an invalid ipn is received… If I turn my locale to en_US, everything works fine.

Could you fix that problem ? (probably by setting the locale to "C" before parsing the dates, and setting it back to its original value after ?).

Thanks, palkeo.

The recurring_payment signal is never sent because a recurring payment is also a transaction

        if self.is_transaction():
            if self.flag:
                payment_was_flagged.send(sender=self)
            elif self.is_refund():
                payment_was_refunded.send(sender=self)
            elif self.is_reversed():
                payment_was_reversed.send(sender=self)
            else:
                payment_was_successful.send(sender=self)
        # Recurring payment signals:
        # XXX: Should these be merged with subscriptions?
        elif self.is_recurring():
            if self.is_recurring_create():
                recurring_create.send(sender=self)
            elif self.is_recurring_payment():
                recurring_payment.send(sender=self)

I wanted to change elif self.is_recurring(): into if self.is_recurring(): but this comment stopped me:

    def test_recurring_payment_ipn(self):
        """
        The wat the code is written in
        PayPalIPN.send_signals the recurring_payment
        will never be sent because the paypal ipn
        contains a txn_id, if this test failes you
        might break some compatibility
        """

Is there any reason for not sending both signals?

I confused PayPal doc that describes paypal_dict variables that are sent to PayPal with doc describing variables that are returned by PayPal via IPN. As a result, my function that checks if the payment was correct, triggered by the valid_ipn_received signal, used ipn_obj.amount variable instead of ipn_obj.mc_gross.

The function didn't work as I expected but there were no errors reported on the console. After doing some digging I ended up adding this code in my_app.__int__.py

from django.conf import settings

class ExceptionLoggingMiddleware(object):
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        return response

    def process_exception(self, request, exception):
        if settings.DEBUG:
            print(exception.__class__.__name__)
            return None

and also add to project's settings.py:

MIDDLEWARE = [
    ...
    'my_project.my_app.ExceptionLoggingMiddleware',
]

With this ExceptionLoggingMiddleware class on now I can see errors that makes my function fail.

/paypal/standard/models.py the method named def initialize(self, request): has the following line:

self.ipaddress = request.META.get('REMOTE_ADDR', '')

If you ever reverse proxy a connection to django the REMOTE_ADDR does not contain the end-users actual IP, it'll contain nothing or the proxy servers ip or in my case it actually contained literally "b''" (thats B and 2 single quotes in a string).

There are also cases when someone is using a service such as cloudflare, I changed the self.ipaddress line to the following code so that it'll find an IP somewhere.

for val in ['HTTP_CF_CONNECTING_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_REAL_IP', 'REMOTE_ADDR']:
    self.ipaddress = request.META.get(val, '').split(',')[0]  # proxys may forwarded multiple ips, first one is clients
    if self.ipaddress:
        break

I am using the chrome plugin Postman to try and test the IPN callback on my localhost. When posting to the callback URL I am getting a RawPostDataException error "You cannot access body after reading from request's data stream"

Am I doing something wrong here or is there a better why to test the IPN callback locally? Thanks

While I was testing using the Paypal sandbox I found I was getting POST request instead for GET for its notifications. I modified the code in a way that existing code won't break, but it will also handle the POST method. Hope it gets merged. Thanks.

updates:

• github.com/mgedmin/check-manifest: 0.48 → 0.49
• github.com/pre-commit/mirrors-autopep8: v2.0.0 → v2.0.1
• github.com/psf/black: 22.10.0 → 22.12.0
• github.com/asottile/pyupgrade: v3.2.2 → v3.3.1

Hi, I'm getting an untested warning for PayPalStandardBase.is_subcription()

paypal.standard.models:286: This method (or branch) is not covered by automated tests. It is therefore very vulnerable to being accidentally broken by future versions of django-paypal. Please contribute tests to ensure future functionality!

The method itself is just one line:

    def is_subscription(self):
        warn_untested()
        return len(self.subscr_id) > 0

So I wonder what kind of test would be needed for this. Or if it's pointing to the more generic subscription logic?

Recently I have got 4 payments where the IPN returned with truncated custom field. I did create the (unencrypted) form with data like:

 'custom': '{"user_plan_id": 310606, "plan_id": 1, "pricing_id": 1, "first_order_id": 43102, "user_email": "[email protected]"}

But i am receiving IPN with only ...&custom={&... in URL, so I can't pair the payment with the data in DB.

This would probably be error on side of PayPal, but also can be caused by some interaction with the form in browser on user's side (but it happened for 4 different users). I am creating this issue mainly because I want to ask if somebody has similar experience.

If I switch to encrypted form, the PayPal shows me interface with much worse UX:

In contrast with the interface with unencrypted form:

I don't think, this is fault of django-paypal, but I would like to know the reason for this anyway. Also this might be something that should get into documentation.

Fixes issue #239.

Rather than use the same form for both the PDT callback and the postback, split these apart. We'll take a minimal set of parameters from the callback, and fill in rest using the postback endpoint.

I've included a test which includes the full set of query parameters I'm seeing on most (but not all) PDT callback requests. Note payment_date is in ISO format in these requests, and notify_version is a string. With this PR both these parameters will be ignored.

Hi! I received 3 IPNs for the same transaction with the same data, but only one was flagged as duplicate. They have all the same transaction id and all the same payment status, and are all separated by one minute (3:00 am 3:01 am 3:02 am).

Only one got marked as duplicate so my system ended up processing the same payment twice.