Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Check Charging non-web apps via web
Message
De
05/03/2003 13:24:36
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Applications Internet
Divers
Thread ID:
00761551
Message ID:
00761658
Vues:
43
>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.

Hello Rod,

Authorize.Net does have a HTTPs or secure server interface, that on itself
(and please correct me if I am wrong here) can give you and your customers some sense of security over charges (creditcards or checks) done on HTTP POST over the internet.

If you are to offer your customers an interface to put their "sensible" information such as credit card, check routing numbers, etc., then buying a certificate for your own web site is the norm that way the information supplied by your customer will be encrypted on your side, then when you POST that same info to Authorize.net you will do it using SSL by means of a HTTPs url, that way the info has been entered once instead of all of this steps that you are taking at this poing, but the phone orders.

my two cents

mark oliva
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform