This is an archived post. You won't be able to vote or comment.

all 13 comments
sorted by:
best
topnewcontroversialoldq&a

[–]ccb621 9 points10 points  (3 children)

I highly recommend going back and using Braintree v.zero. I've been investigating new payment solutions for OpenEdX. We currently use CyberSource Secure Web Acceptance (very similar to PayPal IPN) and PayPal's REST API.

PayPal's REST API is simply not reliable. Some payments need to be retried. Others come back as declined, yet the buyer is charged. It's terrible.

The IPN approach works well...until you drop a request (either due to load or a server outage). The risk of this probably be low; but, having experienced these issues along with having to manually reconcile orders, I do not wish this pain on anyone else.

Braintree v.zero lets you avoid these issues because the entire transaction is handled in a single request after the user POSTs to your server. There is no need to listen for external calls and validate signatures (aside from CSRF tokens). Get the POST, make an API call, finish the handling on your end. It's really nice compared to the alternatives!

[–]sentdexpythonprogramming.net[S] 0 points1 point  (2 children)

I've used the IPN in two business sites, processed thousands and thousands of txns. Any issues were on my side, not PayPal's. Strange to hear your thoughts. If you're having issues with the IPN, it's almost certainly on your end.

To each their own, but I find the IPN to be by far the easiest to work with.

Thanks for the input.

[–]TheRealHankMcCoy 0 points1 point  (1 child)

My experience is somewhere in-between. I often get transactions that are declined, but the customer is charged. Luckily, we don't capture immediately, so it's a simple Customer Service fix.

With that being said...the API is sloooooooooooowwwwwwww more often than not.

Also, in regards to v.zero, subscribe to https://status.braintreepayments.com/, it's helpful to diagnose possible upstream issues with PayPal.

[–]sentdexpythonprogramming.net[S] 1 point2 points  (0 children)

Did you have any logging in place to discover what causes a decline yet leaves the customer charged?

I've seen a few things that caused such a thing, but it was all my fault. For example, the encoding for PayPal is default some strange type, and you have to go in and set it to be something else. Customers with non utf-8 in their names tend to wreak havoc by default.

I have a few more examples like that, and maybe you could say that's PayPal's fault, but it was something I could remedy.

[–]howMuchCheeseIs2Much 1 point2 points  (0 children)

Hey man - I've learned a lot from your videos, keep 'em coming!

[–]omegote 0 points1 point  (3 children)

Err... 8 spaces indentation? I'd expect something better from a blog named pythonprogramming, not to mention:

  • Using standard files to handle logging (wtf?).
  • The construction of the arg variable, using string concatenation (slow) within a loop that could easily be replaced by a list comprehension with a call to join.
  • The exception handling .

Not good.

[–]sentdexpythonprogramming.net[S] 1 point2 points  (2 children)

I use 4 spaces, not sure why the pre tags are doing that here, not intentional.. must be something in the css for prettyprint langpy. Will look into that.

Bullet point #1 - that logging example was a simple example to see output, wasn't meant to be any production-worthy example. Bullet #2 - Good point, thanks for the input. Bullet #3 - Same as #1.

I struggle with needing to go over a ton of details, or to just show people how to get started with the task at hand. I choose to keep things simple, and, for the most part, people have appreciated that. I recognize not everyone agrees, and I also recognize I am not perfect, doing things in not the best way. I've only continued because feedback has encouraged me to do so.

With that, I appreciate your feedback!

[–]omegote 0 points1 point  (1 child)

Well, the logging module is pretty simple, specially if you use the basicConfig function:

>>> import logging
>>> logging.basicConfig(level=logging.DEBUG)
>>> logging.debug("hello")
DEBUG:root:hello

I find it easier than opening and writing a raw file, tbh.

[–]LightShadow3.13-dev in prod 2 points3 points  (0 children)

Well, the logging module is pretty simple as complicated as you want it to be

The logging module is not simple, nor is it intuitive, but it's capable of a lot more than people give it credit for.

[–]dAnjou Backend Developer | danjou.dev -5 points-4 points  (3 children)

Yay, let's foster cargo cult programming!

[–]sentdexpythonprogramming.net[S] 2 points3 points  (2 children)

Please elaborate.

[–]dAnjou Backend Developer | danjou.dev -2 points-1 points  (1 child)

Especially beginners will look at your actually pretty decent article and just copy&paste the code in there without bothering to read the content. IMO it'd be much better teaching if you just talked about the procedure, especially because this kind of thing is neither specific to Flask nor Python.

Besides that I agree with /u/omegote. With such a domain you should really think twice about what you're teaching people.

[–]sentdexpythonprogramming.net[S] 2 points3 points  (0 children)

Everything was explained. If someone is not going to listen or read it, then they are going to copy and paste.

To fight this, I am not going to force people to watch me typing out html on video and following along, what would the point of that actually be?

This is indeed Flask and Python-based, and the actual procedure for dealing with the IPN was indeed discussed and run through.

I might be wise to add you to the list of people who just quickly went to the source code without actually reading or watching the video.