I've been curious about this for awhile and could never find any good information. I used to work at a pizza place that did online ordering. The user would submit their card information and we would run it at the store. I was wondering if someone could give me an idea as to how this transaction took place. If it was PCI compliant, and how it would be sent to the printer. I could think of a couple ways but none of them really seem to be the correct way. I'm looking to do this in PHP. Thanks.
If I where to design this system it would be like this:
The customer posts the order and CC information using a webform over a secure link to the server (using php to generate the page and take the info back in).
The server would use a payment gateway and bill the card on the server (server side PHP script).
On a successful billing it would contact a application running on a box at the restaurant with what to print on the order ticket (only the last 4 digits of the CC info is sent to the restaurant)
Updated with Chris's suggestion
Another option is to use PGP to encode the credit card on the server with the public key. When the CC is sent to the store, it can the be decoded with the Private Key and viewed in order to charge it. But when you are passing credit card information around like that, you always run the risk of something going terribly wrong. It's always better to use a gateway and charge the card immediately or authorize the transaction and then go back and collect the funds by running the authorization number.
Related
I am integrating PayPal Express Checkout API into a digital goods/services website. I worked out all the technical stuff, but now I have a theoretical question - when the transaction is done and I get a confirmation from PayPal, what is the best way to store that acknowledgement from paypal, and credit my user's account?
The ConfirmPayment() function in the paypal library returns from paypal with an associative array, including a transaction ID, and acknowledgement that I have the user's money in my business account.
So my plan is, store that transaction ID as a unique value in a SQL table, so if the user for example reloads the confirmation page, which would then re-call ConfirmPayment($token), my PHP script won't just credit their account a second time, because the SQL table will return a unique ID error.
How are smart programmers integrating this last payment confirmation into the rest of their application?
THANKS.
I would do it like so:
Keep a full log of all the messages your receive from Paypal. Just the RAW data should be fine. Then beyond that point don't need that much traceability. If anything ever happens you can check the log. This should really never happen, if you need to look at this log a lot to resolve any issues you have a different kind of problem. This is why my suggestion is: don't put too much time into it, but make sure you have traceability (albeit a very crude one).
If the user reloads the confirmation page, Paypal will not send you another message. Keep in mind that you should only accept transactions that Paypal has verified. The user should not be able to validate his own transactions by bypassing Paypal.
I have a maintenance project which uses Authorize.Net for payment. Currently, the system provides an email receipt provided by the gateway. Is there any way to grab the receipt and display on the thank you page as a printable receipt ?
Help would be appreciated.
Not realistically. It's hard to say exactly how you would do this since which API you are using will affect your programming, but technically you can pipe the copy of the receipt sent to you into a PHP program which would then place it into a database or flat file. Meanwhile you can have your PHP script waiting for the file or database record to exist and, when it does, output it to the screen.
This would be a bad plan for several reasons:
If the email never arrives your user could be left waiting for a receipt that never comes. That could result in unhappy users and potentially chargebacks.
Even if this works it will be slow which will also result in lower customer satisfaction.
This is a hack.
There are much better ways to provide a printable receipt to your users. If you're using the AIM, ARB, or CIM APIs you have instant access to the response from Authorize.Net. You can easily generate your own printable receipt for them with this information. If you're using SIM you can use relay response to get the transaction information from Authorize.Net to accomplish the same thing.
These are better solutions because:
They're fast. You will get a response from Authorize.Net within seconds and can print out the information in less then a second.
You have total control of the receipts content and appearance.
It's reliable. You can count on getting a fast response every time.
If working with APIs seems daunting to you, you may find using their Silent Post feature appealing. It's just like Paypal's IPN where after a transaction is processed, regardless of which API you use, all of the transaction information is sent to a PHP script you specify. It is POSTed just like a form submission so it's easy to work with. You can then email your users a receipt with that information.
Disclaimer: I wrote the Sitepoint chargeback article and the Silent Post article
I am looking at integrating credit card processing into a form. Basically what happens is :
The customer will enter the website which is secured with ssl
They enter their info into a form, and select different drop down options, jquery then updates the price of their quote on the fly as they select different options.
Once the customer is happy with the price of their quote they press submit,this then posts the info to the payment page.
The customer enters their credit card number, this is then posted to the credit card processor presumably using the credit card processors script ?, along with the price to be debited from the account. (not sure on this part).
The credit card processor then returns a true or false value.
If false is returned echo "transaction failed" , else enter the customers details into the database and display a success message.
What I am wondering is if this is the correct procedure to follow ?, as the person I am doing this for was talking about saving the credit card details to the DB or sending them in an email in a csv which sent alarm bells ringing, so I told them neither are a safe option and the processing should be done by the card processing company.
I just want to clarify that the above process is correct before I suggest an alternate plan to their highly insecure one.
The easiest way to handle this is to sign up with a payment gateway. They’ll have instructions on how to communicate securely with their server. The money is then sent to an internet merchant account.
You’ll likely then need a Secure Sockets Layer certificate for your site, in order to have a secure connection with the payment gateway’s server.
An example of a payment gateway in the United Kingdom and Ireland is SagePay.
Firstly, it's not "insecure" to hold such data in a DB. If you have returning customers and you want to offer them the service of not having to re-enter information ALL THE TIME, using a DB is an idea. To make the idea secure, you'll need policies in place for the DB administration, server access and proper data security (i.e. hashing, encryption, etc)
As for your script, if you are submitting the data via POST to the PHP script, the PHP script will certainly have to talk to a DB (whether is be your local one or the connection made to the Credit Card script).
To answer your question, you'll need to know EXACTLY what the script requires before making any judgement on what you need to do locally. If the script simply takes inputs and returns a value, then you'll have to integrate it into your WebApp.
More details if any?
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.
I'm a web developer looking to move a lot of clients to use authorize.net for their CC processing. I have used authorize.net once in PHP doing SIM integration for a simple site.
Now the problem is, some of our clients have established processes that takes the CC info from our site, and it goes through a fulfillment process outside the control of our site. In at least one case, the client uses the CC info to bill for shipping after it's packaged, long after it leaves our website, because of international rates.
The main reason of using authorize.net is security. We want to be PCI compliant so the idea is that the CC never even goes through our web server. It is entered on authorize.net and never leaves there. So I need to figure out the API to conduct this process.
So my question is, without ever handling the CC info, how do I create a "pending" transaction that takes the user's cc info at one point, and then has the cost updated at another point? I am picturing I will have to tell the client to log back into our site (or authorize.net) to update the cost of the order.
All I have found is this FAQ, my question is the same as the top, but it isn't clear if I have to keep the CC info to do this process, which I simply cannot do.
http://www.inventiveweb.com/RoboCharge/faq.htm
Can it be done?
OK they have great support at authorize.net and an excellent knowledge base. I bet their support guys just paste out of the database.
As outlined in the link above, if you know the high-end of the costs, you can pad, and do an AUTH_ONLY followed by a PRIOR_AUTH_CAPTURE.
As of now there is no API for this, but you can log into your authorize.net account and perform a re-bill. Transactions are stored for up to 90 days, so you can then issue a new transaction with a re-bill and you don't need the CC info.
The downside? A re-bill only works on a successfully settled transaction, and that takes 1-3 days.