Forum Moderators: buckworks
I have spent many hours researching the ways to approach this problem, but I still don't know what's best. Initially I thought I would use Web Payments Pro (PayPal). A customer could enter their CC info once, and a script can be run each month to charge the appropriate amount. However, since the CC numbers would be stored in this site's database, this technique poses PCI Compliance issues. From what I have read, achieving PCI Compliance is both very time consuming and very costly (for example, a shared hosting account is not considered compliant - is it?)
In a nutshell, I need the flexibility of charging each card variable amounts each month, without the liability of storing the CC numbers. Does PayPal offer such a service? If so, such a solution could be acceptable, but would pose another issue- I have heard horror stories about PayPal terminating merchant accounts with little explanation or recourse. Should that happen, and the site is forced to switch to another merchant (ie, Authorize.net), all CC data would be lost and users would have to resubmit it (right?) - which would certainly be a burden on this site's members.
Any insight would be greatly appreciated. What is the best way to approach this task?
Authorize.net is the other one I was considering. Anyone have advice on either? They are looking to implement ASAP, so speed is another big factor.
If you don't store the CC data how can you transmit the data each month to PayPal?
In most subscription systems, a unique ID is provided for the original transaction/purchase and this is what's stored on your server. You can a) allow the gateway (payPal) completely manage the sub (in which case the unique ID is just for reference) or b) by cron job/silent post, push out the auto debit using the unique identifier as the "handle" on the account. The merchant gateway stores the CC info and processes the transaction.
With many merchant gateways, the second method allows you to post an amount that varies. Example, "your subscription fee never changes" so you store the initial fee in the client's data, and use that to renew the subscription, regardless of rate changes that come later.
I know that payPal supports subscriptions, but don't know if it supports method B or variable renewals, you'd have to dig through their documentation.
if I didn't actually store the CC data, just transmitted it, would the site have to be "as compliant" as if I were going to store the CC data, say, in a local database?
Perl your other thread, there are various levels of compliance. A site storing CC info now has the added checks of how the data is encrypted, and also requires a review of the physical hardware access as well as the security of the entire network on which the server resides. Definitely a different level.
They do have a subscription system but it's based around PayPal Standard and pretty quirky in my experience.
If you're in the US I'd follow the authorize.net path and if you want to avoid the PCI compliance burden then check out their CIM system where they store the sensitive data and you just post an identifier to initiate a charge.
