Some notes on how itemshop was created:
Reasons for using stripe:
Reasons not to use stripe:
One of the major reasons to use stripe.js is because you never need to handle sensitive credit card info on your server.
To guarantee that you never receive actual credit card info, you should leave the “name” attribute off of the sensitive form fields, so even if somehow the form gets submitted without javascript, you won’t get the raw credit card data.
Even though you do not need to host your site with HTTPS, it’s probably best if your site is hosted with HTTPS anyway, to reaffirm with users that the payment process is secure.
Just like flask, this package has no idea of persistence, database, ORM, etc. It is agnostic of whichever database you want to use.
The stripe service keeps a record of purchases that you can view through their admin interface or retrieve through the API, so this could be thought of as a persistence layer. See the 03-secure-download demo for an example of using the stripe API to retrieve an existing payment.
To save purchases to a real database of your choosing, just inherit from ItemBP and override the post_purchase method.
This package also does not do any form generation or validation. By default, ItemBP only requires one form field to be POSTed to process the request: stripe_token.
The demos include some Javascript validation. In my opinion, you should validate using javascript (or AJAX) because A.) the stripe.js API validates the credit card information for you, and returns a decent error message B.) you should not be sending users’ credit card information to your server for validation, and C.) you want to avoid doing a page refresh, which will clear the credit card fields and annoy users who will then have to reenter their information.