groupon.com is a great example when you register they take your credit card information. once a limited amount of people have purchased a coupon a mass amount of credit cards get charged. what is the best method of doing something like this and at the most safest possible way? one thing that i will be doing is encrypting the credit cards in the db with an encryption method that salts the encryption and that i can unencrypted it to use it when needed. would they possibly have a cron that goes through at a period of time to check and see if the coupon time limit has expired then do a mass charge? i cannot wrap around my head to how something can be written that queues transaction charges to a merchant. i am thinking of either using authorize.net or paypal pro.. what do you think from what ive said?
Don't store the credit card information on your server. It would need to follow PCI DSS security standards:
http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
There's just no reason for it these days. A large percentage of payment processing vendors provide these services for you. You submit the information and receive back a token that can be used to charge the card at a later time.
Furthermore, you are not allowed to store the CVV code.
I personally work with Paypal as the processor, you need to request reference transactions (this will require a background check, probably credit worthiness related and is not guaranteed to be approved). In this way I can authorize a card ($1 authorization only is common and accepted practice) and later charge the card any amount that is appropriate (in our case we have a payment model similar to pay-as-you-go mobile phones). Upon the first charge or authorization I receive a token that I can late use to charge against the "referenced transaction" (essentially just copying the details from the original txn).
Another really interesting option that we looked into was www.paysimple.com, they now have a new API, an attractive pricing structure, and if memory serves, all of the above features.
Many others exist as well that you can and should research. Do watch out though, some card processing providers don't charge anything for the functionality described above (paypal doesn't), but some charge gobs of money for the service. Look, it's generally readily available info on the sites.
Start reading PCI Compliance and periodical payments parts of the source code of an open source cart like Magento. There is a lot to it, if you want to do it all properly.
Related
This might be quite a long read, because there is a bit if relevant back story. Of you just wanted to see the question summarized I have it written at the end.
Edit: I realize hiding the type of business isn't useful, it's a maid/cleaning business.
I'm working with a client where the service they provide is ordered through the website, but the client doesn't have to pay until the service is finished. Because of this the payment is handled through a third party and no payment information is even processed on the website.
The problem is now with the city. While we were in talks with them to obtain a license for the product they said that we could still collect payment the way we want, but we have to store(or have access to) a credit card for each user so we can identify or track them if they break a law (like assault one of our employees on the job or decide not to pay or whatever)
Originally we thought a fully varied phone number would be enough but they are insistent that we need to be able to link a user on the website to a credit card. Even if they choose to pay by cash we need a credit card on record just in the off chance we need to track them later.
Is there a way to do this without holding credit card information on our personal database? When a user makes an account can I ask for a credit card at that point and then just feed it to a service like stripe and just hold it there sort of acting like a second database? If we go through this route is there anything we need to do on our side in regard to PCI Compliance.
Our owner has had a bad experience in the past with bad developers holding credit card data on a server that was not protected and it ended badly so he refuses to hold any card information on our side Also the insurance we have already lined up refuses to back us any further if we hold it in site without professional security measures. Even if we did start to hold credit card information, what exactly do I have to do to make sure it's all secure and up to standard, I've never had to handle this before.
Any suggestions or help would be awesome I'm really stuck here.
TL;DR: City wants us to be able to link a user to a credit card before service is even started, so basically upon sign-up. Owner of business and isurance company doesn't want to save credit card information on our database. I'm not sure how to handle this and make both happy. Do I learn some basic encryption? Can I use stripe or something as a second database?
Edit: To clarify further, I don't want to use any of the information we save, we plan to charge customers differently. The city just wants it on record.
Yes of course there is a solution.
There are companies (Payment processing companies) that are doing exactly this, they charge a fee and offload all of the responsibility from you.
They invest a lot of money to be able to validate all of the security measures required by the law, including PCI compliance.
Those companies are not only offering different payment formats (such as single payment, recurring payments, etc..) but also takes care of storing some data on their side for future payments from the customer.
stripe, 2checkout and authorize.net are only a few of many options to look into.
Don't you ever think about storing any sensitive information (credit card information is only one example) on your own servers, unless you can comply with all security measures required by the law - which is a tiresome and expensive thing to do.
Good luck !
I'm developing an e-commerce website using PHP and integrating paypal for processing the credit card payments.
I found APIs in PHP that are used to make payments and capture transaction id but none of these discussed about adding adjustments to the amount that is captured.
My use cases include:
Adding tip later
Adding time extension adjustments
Returning only portion of the amount if order gets cancelled
and few more of similar kind
May anyone tell me how this kind of a task is handled with paypal and also is there any API that will provide this functionality as well?
References Transactions would work fine to charge a separate transaction for the tip, but then the customers would see two separate charges on their credit card and you'll probably get lots of questions and confused people wondering why their card was hit twice. As obvious as it seems, I've been there.
The best way to handle it would be to run an Authorization when you first run the card. Authorize it for something like 50% above the ticket total, or whatever you think it would take to cover the final total including a tip for that order.
If the order is canceled for any reason you simply Void the authorization. If you're ready to actually process the funds with a final total including tip, then you can Capture the amount that you need up to the amount that you originally authorized. I believe you may even be able to capture up to 10% more than the original authorization, but I'm not 100% sure on that.
The thing you would need to be careful about is authorizing a card for some large amount and then not voiding or capturing shortly after. The authorization is only guaranteed for 3 days. You can run a re-authorization and get an additional 3 days if you need to.
If the order gets canceled and you don't void it then you'll get complaints that a large amount is "charged" on their account. It looks like a charge until it clears back or is voided. If you don't void it then it can take up to 29 days for them to get access to those funds on their account again, so you want to avoid those types of complaints too.
You would need Payments Pro to handle credit cards directly for that sort of a system. Depending on which version of Pro they put you on you'll use either the PayFlow API, or you'll use variations of DoDirectPayment, DoVoid, DoCapture, DoReauthorization.
Reference transactions would work for what you are trying to do. Reference transactions allows you to reference a previous transaction to run another transaction on that information at a later date. Here is a link to more information on reference transactions. https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/integration-guide/ECReferenceTxns/
Let's say, for the sake of discussion, my client does not want to use the Paypal api for transactions. I have already made a shopping cart. The user submits the items on the shopping cart and their credit card number.
Assuming I'm not using any api, how would I then charge the user's credit card for the items on the shopping cart? I understand that it is complex, just wondering what the general process is like and how to get started.
You're going to need to trigger a bank transaction, so obviously you're going to need to use an API at some level. I think the way to go would be to first learn in some detail how at least one of the popular commercial (by definition?) payment card processing services works, e.g.:
https://paymentvision.com/Payment-Gateway/Payment-Gateway-API.aspx
http://aws.amazon.com/fps/
https://www.firstdata.com/en_us/customer-center/merchants/support/first-data-global-gateway-api-software-landing.html
http://www.authorize.net/
The next step would be to design the "payment processing" subsystem of your PHP application/library around the "backend workflow" (perhaps using a 3rd party PHP library, if one is available), and do some testing.
Then I would plan for a security audit of your code & systems before you actually use it to handle payment card information on behalf of a customer/3rd party.
You can also capture all the card information and use an external payment processor. The problem is that you will be hit with major fees since it will be considered a keyed in and not swiped transaction.
If you don't want/like paypal, don want to use a payment processor like authorize.net, you could look at other options like stripe.com.
Find an payment gateway, such as authorize.net. With payment gateways such as this, your client will need to sign up for a merchant account with a credit card processing agency. You payment gateway can help you with this.
Then, you'll usually get a token or api key that you will use to connect to the payment gateways services. From php, you'll use cURL or fsockopen to connect to them. Securely send your api key, get a response, then send some other required message, get another response, and then send in credit card information and credit card holder information.
There are lots of PHP Libraries to choose from out there for different payment gateways. I'm not suggesting authorize.net, it was just an example. But when you find one you are happy with, and happy with the fees that are associated with processing credit cards, you can either use a prewritten library, or they payment gateway will provide you with and API that will tell you how to integrate with their system.
Payum efficiency proved by 1k+ stars on a GitHub, great comments and a million of downloads. Supports 50+ different payment gateways so you surely find what you need.
I am capturing the credit card details from the uses in a form and then sending these form data to payment gateways like PayPal or Braintree.
The credit card capturing form is hosted in SSL (HTTPS) and using cURL to post credit card data to payment gateways. As we are not saving credit card data to our server so do we need to be PCI complaint if we are following this scenario.
You shouldn`t do that!
The form that handles the credit card information should always point to the payment gateway as target so your server doesn´t handle any sensitive data.
A good payment gateway will send you back a shortened version of the credit card number combined with the verification status to store in your database and possibly show the user in emails or user admin areas.
You could also use a javascript to get a shortened credit card number (and the number only!) from the form and send this via ajax to your server before sending the form to the gateway.
If you're handling and transmitting credit card information then you have to be PCI compliant. Period.
I agree with the two other answers that are posted ...
As you have access to the sensitive data, functioning as a man-in-the-middle, regardless if you decide to store the data or not ... you could ... and you need to be compliant.
If you pass them on to another form which isn't yours like Paypal / etc. and you never actually receive any client credit data ... that is the right way.
The Smart Approach to PCI DSS Compliance
http://www.braintreepayments.com/services/pci-compliance
By using our Transparent Redirect (TR) and Vault, merchants can achieve PCI Compliance in days. TR and the Vault will eliminate the handling, processing or storing credit card data so you can qualify for the Self Assessment Questionnaire A, the shortest of the four SAQs.
Probably, you are still handling the sensitive data. If someone hacks your server they could easily intercept your communication and get hold of this data, i.e. it still needs to be properly secured.
You will probably find the correct answer on the PCI Website
The short answer is yes. There's several levels of PCI compliance, all of which are determined by your annual sales volume.
Most merchants do less than 20K transactions annually and that affords some liberty to do a self-assessment to confirm that you are compliant with the regulations. This article, although Magento specific, is a really good summary of the landscape.
The key takeaway here is that you should have this as part of your core business workflow.
The answer is NO, you DO NOT have to be PCI compliant if you aren't storing credit card details and using a secure gateway. But, you DO need https which you already have.
I have started working on a e-commerce website. This website will run PHP and MySQL and requires to have a credit system for the users; they will be able to pay with the credit, top it up by vouchers or regular payment, as well as withdraw.
Now I do have experience with credit cards processing APIs, so paying money in and out shouldn't be a problem; what however is a problem is how to securely store the credit information. Storing it as a single numeric field is not exactly ideal and potentially could be exposed fairly easily. What I was thinking is keep all the transactions and credit history of each user in a separate table, and every time they log in recalculate what should their credit be. Same would then apply before any transaction that they attempt to do.
I would like to hear what are your thoughts how this should be implemented.
EDIT: Just to clarify; my question is not on how to process credit cards and won't be storing credit card information. I will use a well known and secure API to process the payments (e.g. via paypal). However based on the credit card payments, I need to attribute the appropriate user points in a form of credit. These points would be a representation of funds on the website (whilst the money would be retained on the company account, until the user tried to make a payment/withdrawl) and would be used to make payments and withdraw funds. Again for the actual payment processing I would use secure API, however I am not sure how to implement the credit points properly from structural point of view in the application itself. I don't want to use a simple one field point system, as that I would consider very dangerous.
I hope that clears it up a bit.
Cheers
This might not be the answer you are looking for but here are my 2 cents.
In my personal opinion unless you have someone monitoring your dedicated servers 24/7 you should never in any format store credit card numbers in your database, it is just too risky.
A very nice solution I came across last year was BrainTree http://www.braintreepayments.com/. You can set up a very nice credit card payment system without taking on any liability yourself. Their API allows server to server and transparent redirect (form posts to their site and they redirect back to your site) transactions. At the same time their Vault service allows you to store credit cards on their end and you just use a token in the server to server API to process a payment. You can store the last 4 digits (which they provide in the transaction detail) in your DB along with the CC type and the token, with this you can display a drop down for the user to select which card they want to use and you just use the token when talking to their API.
The API is very nicely documented with full examples. I think you should look into them.
Edit:
I believe you should have a table as you have suggested to store all the history and 'totals' field in the users table, which can be used to display in various places. Each time a transaction a made calculate the total and cache it in this field for ready usage. However it is a good idea to re-calculate this in certain crucial places to make sure everything is in order. Even though this field is exposed but you have a full log which can help you re-calculate everything if needed.