4 ms·

This is a great illustration of the power that APIs like Stripe's give a developer. That said, there are a few things that would make this integration more bull

by zrail 13y ago

This is a great illustration of the power that APIs like Stripe's give a developer. That said, there are a few things that would make this integration more bulletproof. In particular, interactions with external services like Stripe and email should be handled in a background thread. That way you don't have to worry about transient API or SMTP server failures giving your customers a bad experience. The best bet for Python is Celery, iirc. <shameless plug> I wrote a book about combining Stripe and Rails. https://www.petekeen.net/mastering-modern-payments https://www.petekeen.net/mastering-modern-payments </plug>

git-pull 13y ago
First, zrail's book is definitely related. :) It's great luck and opportunity stripe got mentioned here. I have a question on HN etiquette re: plugging decorum. I seen a few instances of this in passing, I thought it was cool. If it was in this instance, for example: What they did was drop the bait. "I wrote a book about combining Stripe and Rails". Then a reply comment, 99% of the time, will ask for them to dish out the link. If zrail simply mentioned his book on rails and stripe, my curiosity would have compelled me reply to ask for information on his book (and presumably a link). Also I would see his profile and notice he's also an engineer at a large rails site - which makes me want to hear more from him. Has anyone else here ever seen this and can show examples of it on HN comments? Is there another reason some HN posters don't do links in comments, even if they are their own projects but on topic?
- lifeisstillgood 13y ago
  For me, the amount of shameless plugging you can get away with is directly related (with weighting) to ones karma score multiplied by thread relevance. I think such a comment in a thread on NSA snooping would have earned many downvotes, here it's just a yes we know :-) at best. We are all here because we want profit from what we learn here (either improving our minds, or more rarely our bank balances) - and indeed most of us secretly or less secretly want to follow the freelancer / ebook / SaaS product route. To be reminded of the existence of the route and that it is not an impassable journey is, infrequently, a good thing IMO
hcarvalhoalves 13y ago
Celery has too many moving parts though. For the simple use case of just off-loading Stripe processing to a queue the RQ module can be better. http://python-rq.org http://python-rq.org
- zrail 13y ago
  Ah, didn't know about RQ. Thanks!
- shavenwarthog2 13y ago
  Agreed. I got my first job running correctly with Rq in fifteen minutes, and was able to go on to other things. Recommended!
- deleted 13y ago
  [deleted]
jknupp 13y ago
I disagree. I would still have to wait for the API to return before I can proceed with the transaction and display the download page, so doing it synchronously makes more sense. And the overhead introducing Celery or python-rq would add versus the response time difference doing asynchronous email (which I'm using GMail for anyway, so I'm not too worried about it going down) makes the synchronous approach even more attractive.
- zrail 13y ago
  Sure. But what happens if Stripe's charge API takes 30 seconds and then Gmail takes a few seconds? The users browser times out and they're left looking at a 500 error. With asynchronous processing you get a lot of flexibility with regards to the failure modes. (This is not idle talk. We experienced this at my day job which is specifically what drove me to write my book.) For email you should probably not use Gmail. They have weird limits and you can easily run afoul of them. A better route is something like Mailgun or Mandrill. They're both free for a large number of outgoing sends and have nice logging and tracking options.
  - abritishguy 13y ago
    I agree for email but transactions are very different, I want to know whether my transaction has been successful there and then and get access to what I have paid for. I don't want to be moved to a page saying that my transaction will be processed shortly. Also there would have to be much more than 30 seconds of lag before the connection would timeout.
  - elithrar 13y ago
    > For email you should probably not use Gmail. I totally agree here. You're also forced to store a password (even if it's app-specific) in plain text, and the tracking/delivery features are non-existent. The Mandrill API is pretty rad (I'm using it in my Go app) and the tracking, ability to re-send an email from the last 24 hours (on the free plan) and the server-side templates are all very useful. try: mandrill_client = mandrill.Mandrill('YOUR_API_KEY') message = { 'subject': "Hello there.", 'to': [{'email': 'recipient.email@example.com', 'name': 'Recipient Name', 'type': 'to'}], 'from_name': "Matt", 'from_email': "matt@example.com", } result = mandrill_client.messages.send(message=message, async=True) // It'll fire it off without waiting, and you can either set up a web-hook *or* manually re-send if it fails via the dashboard if you don't do massive volumes except mandrill.Error, e: # Mandrill errors are thrown as exceptions print 'A mandrill error occurred: %s - %s' % (e.__class__, e) # A mandrill error occurred: <class 'mandrill.UnknownSubaccountError'> - No subaccount exists with the id 'customer-123' raise Pretty simple stuff. Add in some MergeVars (|NAME|, |PURCHASE_ID|) and server-side templates and you can pass whatever is needed to the API without having to keep "content" in your code or pull in an external template (i.e. Jinja).

by zrail 13y ago

git-pull 13y ago

First, zrail's book is definitely related. :) It's great luck and opportunity stripe got mentioned here. I have a question on HN etiquette re: plugging decorum. I seen a few instances of this in passing, I thought it was cool. If it was in this instance, for example: What they did was drop the bait. "I wrote a book about combining Stripe and Rails". Then a reply comment, 99% of the time, will ask for them to dish out the link. If zrail simply mentioned his book on rails and stripe, my curiosity would have compelled me reply to ask for information on his book (and presumably a link). Also I would see his profile and notice he's also an engineer at a large rails site - which makes me want to hear more from him. Has anyone else here ever seen this and can show examples of it on HN comments? Is there another reason some HN posters don't do links in comments, even if they are their own projects but on topic?

lifeisstillgood 13y ago
For me, the amount of shameless plugging you can get away with is directly related (with weighting) to ones karma score multiplied by thread relevance. I think such a comment in a thread on NSA snooping would have earned many downvotes, here it's just a yes we know :-) at best. We are all here because we want profit from what we learn here (either improving our minds, or more rarely our bank balances) - and indeed most of us secretly or less secretly want to follow the freelancer / ebook / SaaS product route. To be reminded of the existence of the route and that it is not an impassable journey is, infrequently, a good thing IMO

hcarvalhoalves 13y ago

Celery has too many moving parts though. For the simple use case of just off-loading Stripe processing to a queue the RQ module can be better. http://python-rq.org http://python-rq.org

zrail 13y ago
Ah, didn't know about RQ. Thanks!
shavenwarthog2 13y ago
Agreed. I got my first job running correctly with Rq in fifteen minutes, and was able to go on to other things. Recommended!
deleted 13y ago
[deleted]

jknupp 13y ago

I disagree. I would still have to wait for the API to return before I can proceed with the transaction and display the download page, so doing it synchronously makes more sense. And the overhead introducing Celery or python-rq would add versus the response time difference doing asynchronous email (which I'm using GMail for anyway, so I'm not too worried about it going down) makes the synchronous approach even more attractive.

zrail 13y ago
Sure. But what happens if Stripe's charge API takes 30 seconds and then Gmail takes a few seconds? The users browser times out and they're left looking at a 500 error. With asynchronous processing you get a lot of flexibility with regards to the failure modes. (This is not idle talk. We experienced this at my day job which is specifically what drove me to write my book.) For email you should probably not use Gmail. They have weird limits and you can easily run afoul of them. A better route is something like Mailgun or Mandrill. They're both free for a large number of outgoing sends and have nice logging and tracking options.
- abritishguy 13y ago
  I agree for email but transactions are very different, I want to know whether my transaction has been successful there and then and get access to what I have paid for. I don't want to be moved to a page saying that my transaction will be processed shortly. Also there would have to be much more than 30 seconds of lag before the connection would timeout.
- elithrar 13y ago
  > For email you should probably not use Gmail. I totally agree here. You're also forced to store a password (even if it's app-specific) in plain text, and the tracking/delivery features are non-existent. The Mandrill API is pretty rad (I'm using it in my Go app) and the tracking, ability to re-send an email from the last 24 hours (on the free plan) and the server-side templates are all very useful. try: mandrill_client = mandrill.Mandrill('YOUR_API_KEY') message = { 'subject': "Hello there.", 'to': [{'email': 'recipient.email@example.com', 'name': 'Recipient Name', 'type': 'to'}], 'from_name': "Matt", 'from_email': "matt@example.com", } result = mandrill_client.messages.send(message=message, async=True) // It'll fire it off without waiting, and you can either set up a web-hook *or* manually re-send if it fails via the dashboard if you don't do massive volumes except mandrill.Error, e: # Mandrill errors are thrown as exceptions print 'A mandrill error occurred: %s - %s' % (e.__class__, e) # A mandrill error occurred: <class 'mandrill.UnknownSubaccountError'> - No subaccount exists with the id 'customer-123' raise Pretty simple stuff. Add in some MergeVars (|NAME|, |PURCHASE_ID|) and server-side templates and you can pass whatever is needed to the API without having to keep "content" in your code or pull in an external template (i.e. Jinja).