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.
Related
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 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'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.
I am developing a website in PHP that accepts PayPal payments. It uses the IPN from PayPal and has a custom payment template etc etc. It all works great through the Sandbox server but when it comes to showing my client, I don't want to have to tell them to login to/create a Sandbox account, create a buyer account and make a payment - he hasn't got time for that and probably won't be able to do it.
Therefore, my question is - is there any simple way that I can show my client the PayPal integration in "test mode" without him using the sandbox? I realise that I can set the transaction value to 0.01 and just test on the live PayPal server but that isn't an ideal solution.
Cheers!
Edit: Just to better explain what I mean, this is what my client sees when he first goes to checkout;
alt text http://img3.imageshack.us/img3/2545/67913734.png
As you can see, he has to login to his Sandbox account before then purchasing the item using the buyer email that he sets up. It's just confusing and totally non user-friendly.
Unfortunately there isn't a way around this problem via paypal. Their sandbox will always require you to be logged in to actually demo.
Here are the solutions I have taken especially with remote clients.
Use Skype or similar service so I can share my screen as I demo how it works. This solution seems to work fairly well, and eliminates the need for them to take the extra steps required.
When working on something I want to quick demo for a client and get their take, I have started using http://www.jingproject.com/ It allows me to make a quick video of the process. It uploads it to their server and provides a url I can send the client to watch what I did.
Wish I could provide a more elegant solution.
What I'd do is integrate with the actual PayPal live site and use real money. The great thing is you can refund the transaction (including the fees) so nobody pays anything. I believe the refund timeframe is 30 days, but there's no reason to wait too long and risk it. The added advantage is that you get to prove to your client that the PayPal integration really works.
If there's a concern with littering the seller account with test transactions and refunds then go ahead and set up a separate seller account. It's quick to set up as long as you don't expect your test account to be receiving thousands of dollars.
got a question and I hope this is right place to ask :).. don’t quite understand how payment works in magento.
client goes to checkout and lets say wants to pay as a guest, so provides address etc. and finally gets to payment methods. Then I want clients to pay thru credit card. Already have module installed for gateway (bank?) of my choice. At that point I would expect users to be redirected to 3rd party page (bank hosted) where they giving all the details, only after being returned to my magento site with appropriate message.
In magento however it seems like they need to provide cc numbers and details on magento checkout page. I don’t understand if I (or the payment module I installed) need to transfer then all the credit card details to bank? I would have to have checkout page on ssl connection and static ip right?
The thing is I want to avoid touching CC numbers at any point and would love to have it done by a bank page. I like the idea of magento interface all the way without redirecting to another page though, the only problem is not sure if would be able to set it all up properly.
If anyone could explain to me possible options, what is the common way to do it and how the whole process works that would be very much appreciated.
I did my research and looked all over google and various forums still need someones help though. Please let me know if some parts of my question are not quite clear, will try to better explain if necessary.
Had to develop a payment module for DPS in NZ some time back. How this works is, you go to pay on the site and the payment module php code runs that sends off the details to an acquiring institutions payment website who process the transaction for you with the bank. In my case as I recall it was DPS NZ via some soap calls. The Soap calls contained details such as the total cost, the currency, the merchant number to identify who you are paying. The acquiring institution (DPS in this case) then takes your credit card number and expiry date and do the processing. Then, again via some soap calls back to your own magento website you get redirected back with the error code - success, etc.
DPS use soap I think, but other payment websites may use other protocols to work. The other possibility is that your credit card acquiring page could be hosted on your website and you accept the credit card numbers and do all the processing within magento to the acquirer.
In short, the process is controlled by the payment module itself. If you want to see more detail, have a look at the payment module tutorials that are available and also the comments in the magento forums. You can also look at the paypal module code.
The default architecture that Magento payment modules use involves the customer interfacing with the module and the module talking to your payment gateway behind the scenes.
Basically the customer inputs all his data (CC and all) and hits the payment button at which point certain functions are run in the chosen payment module. What these functions do is entirely up to how the payment gateway works. if the gateway talks via XML they send/receive XML, if it needs SOAP then they use SOAP and so on and so forth. This in fact is the gist of building a new payment module. Open an existing one, check out which functions are called, get rid of the code in there and substitute with your own that will talk to your particular bank/gateway.
Of course some gateways have an alternate way of operating where you send the customer to their pages, he gives them his CC data and he is promptly returned to your site. This way you don't need to worry about handling credit card data, but unfortunately the process of implementing this in Magento is somewhat more involved.
If you need to use a certain gateway then you should first check whether a payment module for it already exists. if not you can download a similar payment module, dissect it and modify it to run your code where appropriate.