Yes, unless you're directing the web user to another site which has SSL for the Credit Card data entry screen(an example is Verisign PayFlow Link), you would need it on your end. If you're doing everything on your end (like Verisign PayFlow Pro), then you'd need to shell out the extr $ for an SSL certificate. You just need to be sure the customer browser-to your-server is encrypted when the credit card number is sent..
>We have an in house sales system ... order entry, inventory ,etc. We currently process 3 types of orders ... walk-ins, phone orders and web orders. Our web store is outsourced. They take the orders and email us the customer information but they do NOT charge the customer's card.
>
>Regardless of the order type, the information gets entered into our order entry system by our sales personnel. The user then has to use a POS terminal to enter the card information and charge the card. They have to re-key the card number, the expiration date and order amount. We find that there is a LOT of room for error.
>
>What we would like to do is enable our app to charge via the internet even though the app and order entry are not web based. Using routines from Rick Strahl's IPStuff we can Post information to a web-based payment gateway such as Authorize.Net.
>
>My lack of understanding will show up here, but I'm a bit confused as to whether or not WE need to have an SSL Certificate. My understanding is that we would need an SSL Cert if we wanted customers to enter their credit card information online on our website but that Authorize.Net would need SSL to encrypt the stuff being sent to and from them.
>
>I'm guess I'm a little confused about SSL and where encryption takes place, etc. Could someone help clear up my confusion on this?
>
>Thanks in advance.