Shopping carts to accept credit cards over the Internet without leaving the site
June 29, 2012 4:50 PM
Please help me understand how to accept credit card payments online for a fussy merchant, who wants to set up a shopping cart to sell luxury items, but fears using PayPal will make him look like he is "selling toys on eBay."
Trying to build a low-cost shopping cart for a small businessman, using open-source software. He wants to be able to accept credit card numbers online, but I can't figure out the best way to do this.
I assumed, without thinking about it, that it would be cool to just set this up with a PayPal merchant account. But he thinks this will make him look amateurish if the purchaser has to jump over to PayPal and back. He wants to accept credit cards.
Is this something I could do with Authorize.net or a higher-end PayPal plan: to let the seller accept credit cards but make it look like we haven't left his website, instead of something where you jump to another service?
He seems so set on this that he would rather have credit card numbers sent through an HTML form rather than have buyers go to PayPal. I guess I understand where he is coming from, but I seem to have memories of websites with slick enough E-commerce third parties that you don't really notice. Maybe it's still an option, if there's some way to convince him.
If it helps, he normally enters credit card payments by hand, at his business, into something called BestMerchantRates.com.
Trying to avoid high-cost hosted E-commerce.
Trying to build a low-cost shopping cart for a small businessman, using open-source software. He wants to be able to accept credit card numbers online, but I can't figure out the best way to do this.
I assumed, without thinking about it, that it would be cool to just set this up with a PayPal merchant account. But he thinks this will make him look amateurish if the purchaser has to jump over to PayPal and back. He wants to accept credit cards.
Is this something I could do with Authorize.net or a higher-end PayPal plan: to let the seller accept credit cards but make it look like we haven't left his website, instead of something where you jump to another service?
He seems so set on this that he would rather have credit card numbers sent through an HTML form rather than have buyers go to PayPal. I guess I understand where he is coming from, but I seem to have memories of websites with slick enough E-commerce third parties that you don't really notice. Maybe it's still an option, if there's some way to convince him.
If it helps, he normally enters credit card payments by hand, at his business, into something called BestMerchantRates.com.
Trying to avoid high-cost hosted E-commerce.
Uh and one other factor: I guess he hates PayPal's 2.9% rate, too.
posted by steinsaltz at 4:58 PM on June 29, 2012
posted by steinsaltz at 4:58 PM on June 29, 2012
Amazon Payments offers an 'inline' payments option that keeps you on the same page:
posted by pupdog at 5:00 PM on June 29, 2012
posted by pupdog at 5:00 PM on June 29, 2012
FYI, you might as well tell the client that 2.9% isn't likely going away, regardless who you use. It's fairly close to standard. Someone processors will have a sliding scale, but you'll have to evaluate that based on what you expect their sales volume to be.
And yeah the Payments Pro option can be made completely transparent to users. Also, many applications will have options/addons to plug directly into it and save you a bunch of coding and hunting around for keys and whatnot.
posted by Su at 5:10 PM on June 29, 2012
And yeah the Payments Pro option can be made completely transparent to users. Also, many applications will have options/addons to plug directly into it and save you a bunch of coding and hunting around for keys and whatnot.
posted by Su at 5:10 PM on June 29, 2012
This may not solve his amateur perception of PayPal, but I know a lot of people who won't buy on small websites unless it's through PayPal. I know that for myself if it's not a nationally recognized brand and they don't offer PayPal or amazon payments I don't buy there, because it seems so easy for credit card fraud. True there's credit card fraud with PayPal and amazon no doubt, but you're in a stack of millions of possible victims, not fifteen or twenty.
That might be an angle to use- leveraging paypal's brand awareness to improve customer security perceptions.
posted by winna at 5:11 PM on June 29, 2012
That might be an angle to use- leveraging paypal's brand awareness to improve customer security perceptions.
posted by winna at 5:11 PM on June 29, 2012
Yeah, maybe I will play up security. That's a good idea. He seems to want to present an image of security.
But maybe only an image. He keeps talking about "smoke and mirrors" to make the checkout experience seem cool. I am trying to explain to him that I can't make it look cool if I can't install a payment-gateway-requiring shopping cart package.
posted by steinsaltz at 5:14 PM on June 29, 2012
But maybe only an image. He keeps talking about "smoke and mirrors" to make the checkout experience seem cool. I am trying to explain to him that I can't make it look cool if I can't install a payment-gateway-requiring shopping cart package.
posted by steinsaltz at 5:14 PM on June 29, 2012
"Smoke and mirrors" in the checkout experience would make me stay way the hell away, frankly. Victims of online fraud typically have to review recent purchases on their statement, which also gets them thinking about where security was compromised. Anything that obfuscates the checkout process can raise mental warning bells for a customer, both at the time (even if that business isn't the source of the compromise) and in the future.
posted by gnomeloaf at 5:29 PM on June 29, 2012
posted by gnomeloaf at 5:29 PM on June 29, 2012
Authorize.net can give you a pretty simple CGI method to run a card transaction; he needs a merchant bank account for the money to go into and that is technically all there is to it. I am no longer up to date on what their rates are.
posted by ook at 6:07 PM on June 29, 2012
posted by ook at 6:07 PM on June 29, 2012
Does he have a merchant account with a bank? He probably should, and the bank will have some information about gateways with whom their system integrates.
If he's actually using the phrase "smoke and mirrors", someone should probably have a conversation about philosophy and tone with him; it might be you, if you have enough finesse.
posted by amtho at 6:24 PM on June 29, 2012
If he's actually using the phrase "smoke and mirrors", someone should probably have a conversation about philosophy and tone with him; it might be you, if you have enough finesse.
posted by amtho at 6:24 PM on June 29, 2012
Chiming in to agree that PayPal as a payment option makes me *more* likely to buy from an unknown business, because my financial info stays with PayPal, I don't have to give it to random strangers.
posted by spinturtle at 7:02 PM on June 29, 2012
posted by spinturtle at 7:02 PM on June 29, 2012
When a company website has a custom credit card interface (i.e. not paypal, amazon, or google), and they are not large enough to have national TV ads (and therefore clearly be concerned with their reputation) then I do not buy from that website. period. full stop. the end. game over man, game over.
posted by yeolcoatl at 7:29 PM on June 29, 2012
posted by yeolcoatl at 7:29 PM on June 29, 2012
I do e-comm for a living in a small business environment. First thing you need to do is read up on PCI compliance. https://www.pcisecuritystandards.org/.
I don't know how you get PCI compliance without a dedicated server these days. If that's not a deal breaker for him, it's actually achievable using an authorize.net gateway and open source software, if you configure your cart software to never store the card (only pass it to the gateway), but this is not a walk in the park, and if you don't have experience setting it up there are some non-obvious things you can do to screw up big-time.
His hangup with using PayPal doesn't make a lot of sense. PayPal has some checkout solutions that are pretty good, give the shopper a straightforward checkout experience, and allow the shopper to use a major credit card with or without a PayPal account of their own. I know I'm preaching to the choir, but I actually added PP as an option to some of my sites where it made sense AFTER setting up internal CC solutions, and it was good for sales to have it as an option. Many security-savvy shoppers, as has already been noted, trust PP where they won't entrust the site itself with their CC info. It's not because they think the site owner is a crook (if they did, they wouldn't do business period), it's because they are concerned that the site might store their card info and then get compromised.
I actually think the 3rd party solutions where the site doesn't actually even touch the card data is the wave of the future, and that eventually all sites that aren't mega-corp sites like Amazon, WalMart, Starbucks, or other national companies will use something like how PP handles it now - design the site however you like and flip the customer over to the payment site for payment then back to complete the transaction. Yes, the rate is a little higher, but all e-comm is on the high side rate-wise anyway and if it saves compliance costs, so be it.>
What you said about using "smoke and mirrors" or simple HTML methods of collecting CC info - I hope you're just relating the client's attitude, not yours. Sweet Jesus don't collect card data in a non-encrypted environment, or using a mail-to form or the like!
Feel free to DM me. It's important that you not participate in setting up an insecure means of collecting card data on the internet, regardless of what your client prefers.
posted by randomkeystrike at 8:36 PM on June 29, 2012
I don't know how you get PCI compliance without a dedicated server these days. If that's not a deal breaker for him, it's actually achievable using an authorize.net gateway and open source software, if you configure your cart software to never store the card (only pass it to the gateway), but this is not a walk in the park, and if you don't have experience setting it up there are some non-obvious things you can do to screw up big-time.
His hangup with using PayPal doesn't make a lot of sense. PayPal has some checkout solutions that are pretty good, give the shopper a straightforward checkout experience, and allow the shopper to use a major credit card with or without a PayPal account of their own. I know I'm preaching to the choir, but I actually added PP as an option to some of my sites where it made sense AFTER setting up internal CC solutions, and it was good for sales to have it as an option. Many security-savvy shoppers, as has already been noted, trust PP where they won't entrust the site itself with their CC info. It's not because they think the site owner is a crook (if they did, they wouldn't do business period), it's because they are concerned that the site might store their card info and then get compromised.
I actually think the 3rd party solutions where the site doesn't actually even touch the card data is the wave of the future, and that eventually all sites that aren't mega-corp sites like Amazon, WalMart, Starbucks, or other national companies will use something like how PP handles it now - design the site however you like and flip the customer over to the payment site for payment then back to complete the transaction. Yes, the rate is a little higher, but all e-comm is on the high side rate-wise anyway and if it saves compliance costs, so be it.>
What you said about using "smoke and mirrors" or simple HTML methods of collecting CC info - I hope you're just relating the client's attitude, not yours. Sweet Jesus don't collect card data in a non-encrypted environment, or using a mail-to form or the like!
Feel free to DM me. It's important that you not participate in setting up an insecure means of collecting card data on the internet, regardless of what your client prefers.
posted by randomkeystrike at 8:36 PM on June 29, 2012
Authorize.net has Direct Post Method, which keeps the card data away from your site, but still lets you customize the checkout process. It's not really clear whether it pulls your web server into PCI scope. My personal opinion is that it doesn't since the relevant data is sent directly to a.net, by the customer's browser, but there is disagreement on that point.
I've had customers who insist on this sort of thing. I prefer to just use Amazon, Google Checkout, and/or Paypal's hosted page solutions. It's just easier and most people are already willing to divulge their data to one of them, where they may or may not be willing to enter their card data on a form that comes from my site, even if it's made clear (and can be easily verified by technically adept users) that my site never sees the card data.
I remember seeing one PayPal-like service a couple of months ago that would (supposedly) automagically make their hosted payment form look like your website, but I can't for the life of me remember who it is right now.
posted by wierdo at 9:48 PM on June 29, 2012
I've had customers who insist on this sort of thing. I prefer to just use Amazon, Google Checkout, and/or Paypal's hosted page solutions. It's just easier and most people are already willing to divulge their data to one of them, where they may or may not be willing to enter their card data on a form that comes from my site, even if it's made clear (and can be easily verified by technically adept users) that my site never sees the card data.
I remember seeing one PayPal-like service a couple of months ago that would (supposedly) automagically make their hosted payment form look like your website, but I can't for the life of me remember who it is right now.
posted by wierdo at 9:48 PM on June 29, 2012
I would listen to randomkeystrike. The thing you really want to avoid is a scenario like this: You let him talk you into doing it his way with smoke and mirrors that make him happy; the system isn't secure; hackers steal money or credit card numbers; he faces a big loss of business and/or money; he gets mad and sues you because you're the one who built the system. Protect yourself.
posted by exphysicist345 at 10:06 PM on June 29, 2012
posted by exphysicist345 at 10:06 PM on June 29, 2012
PCI compliance is non-trivial. Screwing up credit card security could result is massive problems.
But you may have trouble convincing him. So show him. Find sites with amazon, authorize, google, and paypal payments, and then find a couple that are more home-grown. Ask client to shop at all of them and see the result.
posted by theora55 at 10:02 AM on June 30, 2012
But you may have trouble convincing him. So show him. Find sites with amazon, authorize, google, and paypal payments, and then find a couple that are more home-grown. Ask client to shop at all of them and see the result.
posted by theora55 at 10:02 AM on June 30, 2012
wierdo, I haven't personally used authorize.net Direct Post, but the test is whether your site ever collects the data, even momentarily. If the point in the process where the customer enters his or her card data happens on an authorize.net domain, not yours, it would indeed keep your own server out of the scope of the PCI questionnaire.
To be clear, ALL entities that accept credit cards must be PCI compliant, in theory. But if you use one of these indirect methods like it sounds like Authorize.net direct post is, the PCI questionnaire becomes dirt simple - literally an exercise in square checking. Essentially, you'll be confirming that you're using a payment method which is itself PCI certified, which authorize.net's method is.
In case anyone's wondering, one's merchant banker (the entity that accepts your credit card transactions) is the authority you should ask about getting started with PCI compliance. Not that they'll be all that helpful, but essentially, your merchant banker is where you turn your forms into, and since practically no one understands the process, they usually refer you to a company which, for a small fee, will walk you through the process. If your sites do direct card processing, i.e. send the data to a gateway after collecting it themselves, that process will include quarterly IP scanning to look for vulnerabilities.
posted by randomkeystrike at 6:26 AM on July 1, 2012
To be clear, ALL entities that accept credit cards must be PCI compliant, in theory. But if you use one of these indirect methods like it sounds like Authorize.net direct post is, the PCI questionnaire becomes dirt simple - literally an exercise in square checking. Essentially, you'll be confirming that you're using a payment method which is itself PCI certified, which authorize.net's method is.
In case anyone's wondering, one's merchant banker (the entity that accepts your credit card transactions) is the authority you should ask about getting started with PCI compliance. Not that they'll be all that helpful, but essentially, your merchant banker is where you turn your forms into, and since practically no one understands the process, they usually refer you to a company which, for a small fee, will walk you through the process. If your sites do direct card processing, i.e. send the data to a gateway after collecting it themselves, that process will include quarterly IP scanning to look for vulnerabilities.
posted by randomkeystrike at 6:26 AM on July 1, 2012
the test is whether your site ever collects the data, even momentarily
It doesn't. The form submit containing the credit card number posts to an authorize.net server, which handles the transaction and redirects back to your server with a pass/fail code; your site never sees the card number at all.
posted by ook at 11:00 AM on July 1, 2012
It doesn't. The form submit containing the credit card number posts to an authorize.net server, which handles the transaction and redirects back to your server with a pass/fail code; your site never sees the card number at all.
posted by ook at 11:00 AM on July 1, 2012
This thread is closed to new comments.
posted by steinsaltz at 4:53 PM on June 29, 2012