If your application handles credit card information, it must be audited for 
compliance. So it may or may not be compliant, an audit will determine 
that. 
What most companies do is avoid the audit by not handling credit card 
information. If you use authorize.net (as an example) you can use the 
"Server Integration Method" where all credit card information is collected 
by authorize.net and your application gets a postback from authorize.net 
confirming that a payment was made.

http://developer.authorize.net/api/howitworks/sim/

You'd want to read the PCI SAQ (Self Assessment Questionnaire) to determine 
if an audit is needed.

https://www.pcisecuritystandards.org/security_standards/documents.php?category=saqs


On Sunday, January 13, 2013 12:16:28 PM UTC-7, Massimo Di Pierro wrote:
>
> I do not know if it is PCI compliant. The provided code requires that your 
> application handles (although not stores) credit card info. 
>
> Massimo
>
> On Sunday, 13 January 2013 12:16:44 UTC-6, Ragtime AllTime wrote:
>>
>> Hello all, I'm looking into using stripe.com as a payment processor for 
>> web2py. It looks like web2py provides a nice and easy way for this, but I 
>> am a bit worried about pci compliance. 
>>
>> On this site shows an example: 
>> http://web2py.com/books/default/chapter/29/14#Stripe.com
>>
>> But no where on the site does it say whether it is pci compliant or not. 
>> I would rather not have my server handle any of the customer credit card 
>> data. Stripe does provide a nifty stripe.js which enables us to not touch 
>> any of that data, but then the form creation and submission will be handled 
>> entirely by javascript and not by web2py's nice library.
>>
>> I guess in particular, if I do it just using stripe.js, I don't have to 
>> give the form input tags any name. That way, web2py can never grab the data 
>> from the dictionary(since I don't know the name of the input tag) that is 
>> returned and so the server will never actually touch the data. However, the 
>> example link on web2py seems to indicate that this naming is necessary in 
>> order to pass the data to the stripe.charge() (since we have to grab the 
>> data somehow from the form and feed it to the stripe.charge()). This 
>> suggests that the server has the ability to access that data.
>>
>> Could someone clarify this issue? Many thanks!
>>
>

-- 



Reply via email to