Using same merchant account on multiple shops?

[onlinesource]

I know that technically I could use the same Authorize.net login settings on multiple shopping carts but will that lead to future problems?

The thing is, I have competitors that are using the same merchant account on three or four different carts and have been doing so for years. I know that they are because I've placed test orders on each and I have gotten confirmations from the same email addresses via Authorize.net and my bank statement showed the same bill descriptor.

Thing is, I am having a really hard time landing a second account because of recent changes in our industry. The problem is, the products that I sell are deemed as "counterfeit" by the bank and they refuse to authorize us (even offshore has been difficult).

IMO their being totally unfair considering we are the only company that clearly marks our items are being "novelty". Still, I understand that rules are rules.

I can't find any bank that wants to touch us though. Processors are making it more and more difficult to accept sites such as mine, yet my competitors seem to be grandfathered in.

I didn't know if processors block incoming requests from domains and their ip addresses that were not previously approved? Meaning if I fill out an application for sitex.net, will incoming payments to siteb.net, get flagged? I think the answer is "NO" or my competitors wouldn't have gotten away with it for years.

Can anybody tell me the pros and cons of this? I know I am gambling the loss of my account but I could loose it regardless because of the business. Might as well make what I can as fast as I can.

[oliondor]

Depends on processors, paypal does not care...

[GoNC]

I have 46 sites that all use the same Auth.net and merchant account. They're all on the same server, though, and I use a shared security certificate for all of them. Even if the processor had a problem with it (I've never thought to ask), as far as they know it all comes from the same domain.

By shared security cert, I mean like:

[server.example.com...]
[server.example.com...]

[oliondor]

A good idea would be to use a website only to process payment and to which all other shops would be redirected ?

[topr8]

>>A good idea would be to use a website only to process payment and to which all other shops would be redirected ?
we used this for a while, it worked fine although it added a layer of complexity.


>>Depends on processors, paypal does not care...
yes i agree, it does. i don't know anything about Authorize.net
in my case my processor doesn't care how many websites that i sell from, however the gateway i used would only accept one!
i've recently changed gateways to solve this.
on the customer statement though the processor will only write the one company name, so you'd need to get a website especially for this in case of queries.

[tangor]

If you own them all, and report income from all same for tax purposes... I see no problem. Put another way, how many banks do you have for your personal business? (Not asking!) Most people have one. And most people with one business (webmastering) have more than one website(s).

So, why not? A single source...

[Mohan92]

If you are one merchant but with several websites, using the very same company and sell the same type of products, then it is allowed to process several websites through one MID.
However most banks and processors insists on one website, one MID.

[onlinesource]

OK, so this one merchant service provider who I've been emailing back and forth... just said to me:

"Anytime you have different URL’s you have to have account numbers with that processor."

I don't know if they are saying THIS because they are trying to protect themselves by saying that underwriting approved sitea and therefore we authorize all sales from site sitea but if anything comes in from siteb that they don't like, they can wash their hand clean of it by saying they never authorized siteb in the first place.

I don't know if this is more about the merchant service provider looking out for themselves or actual steps that will prevent siteb from accepting sales?

Like I said, I know people that have used the same merchant service provider for taking payments on multiple eCommerce shops and I'm just assuming the merchant service provider turns a blind eye? At the end of the day, all they really want is money! It's like PayPal who has rules against selling productA or productB but they will gladly take money from those sites until somebody says something and then PayPal is like, "well, we never knew they were..." How convenient... :)

Doing so, would be easy by using a gateway module with the same settings (login id, etc) that is synced up with the merchant service provider. Also, the payment gateway that I use even allows me to add a domain and/or it's ip address to a safe list for incoming sale requests.

As far as going ahead with this, like I said I don't know if the merchant service provider would actually care or how they would even know for that matter? Right now, I am using a domain name server service and all of my sites share the same ip address when I check it over ip lookup services.

Being desperate, I'm willing to gamble. I also know that I'm not alone in doing this.

[GoNC]

Does your hosting provider not give you the ability to use a shared security certificate? Eg:

[server.example.com...]

If not, ask. If they won't, maybe consider switching providers.

[particleman]

I have done this on paypal web payments pro for many years.

[onlinesource]

@GoNC - with a shared SSL, would all the sites needed to be hosted on the same server? I've heard of like GoDaddy multi SSL where GoDaddy hosts it, is that not the same?

[GoNC]

Yes, AFAIK they'd all have to be on the same server, so they have the same top-level domain name.

I don't know anything about GoDaddy's option (used them once and regretted it almost immediately), but I looked it up, and no, I don't think it's the same. It looks like GoDaddy is just reselling a UCC cert and giving it a different name.

A shared cert is one that's assigned to the entire server, then designated to be shared on all accounts. So in this example's case, the server name would be:

server.example.com

Then, any account on the server would be able to use
[server.example.com...]

These are usually provided to accounts at no charge. If you own the server, you can buy one for around $15 /year.

[onlinesource]

Thanks. I'll check with my current host.

[onlinesource]

I'm a bit confused. Who do you use?

My current host wrote me back:

-----------------------------------------------------------

Hello,

I kindly informed you that we don't offer this shared SSL plan,but normally if you like to setup SSL please provide me the CA and CRT key for the corresponding domain.

I will help you out to install and regarding your second query we won't allow "https://server.example.com/~account " for security purpose but still if you want, i will give you the steps to enable it, but after enabling that perhaps your server getting hacked so we are not responsible for that.

[GoNC]

You're just running the shopping cart under the security certificate, right? Assuming so, it doesn't matter how it looks; every impression comes from a link from the catalog.

So they start at myshop.com/catalog/widget/, and click on "Add to Cart". This takes them to:

[server.example.com...]

The cost they're giving you is BS, though. If anything, they pay $12-15 a year for this certificate, there's no way they're reselling it for $400 to each client.

I'm sending you a private message with some alternatives.

[onlinesource]

I'm using Woocommerce, a shopping cart plugin through Wordpress. I don't even know if this possible with that.

[inmotionhosting.com...]

I also get the impression from the hosting company that this is a security risk. BUT I assume that this is really my only alternative, if I plan to go forward with this?

[GoNC]

Reading the link you gave, you'll have to do a search-and-replace to put in the new link, but that's all. Our servers support Wordpress, but I don't use it, so I can't swear to how easy this is; the link you gave made it seem pretty simple, though.

I can't imagine why it would be a security risk, though. Maybe they were referring to a self-signed cert?

[onlinesource]

Does anybody know if there is any other way to do this, besides the shared SSL approach? @GoNc ha been a huge help in trying to assist me, but for some reason my current setup will not support that.

I do know one competitor of mine who has multiple carts on multiple servers but uses the same Authorize.net gateway login for each site to push sales to the same account. I figured my way of sending everything through the same server was safter and would cause less issues, but obviously my competitor has just been using the same gateway on multiple sites for years. Is that really all I need to do? An account rep told me that the bank looks at the ip/domain of the incoming sale and flags it if something looks off. That makes sense to me, but how is my competitor getting away with doing it the easy way?

I'm baffled...

[onlinesource]

Thanks everybody for your feedback. I am working with a third party processor now who uses a SID or side identification number. I notice when I try to process payments on other sites, the sales are blocked probably because that domain wasn't authorized. Is this common?

[onlinesource]

Thanks everybody for your feedback. I am working with a third party processor now who uses a SID or side identification number. I notice when I try to process payments on other sites, the sales are blocked probably because that domain wasn't authorized. Is this common?

[oliondor]

Finally what did you decide ?

[onlinesource]

Update. I got a full fledged merchant account setup and I'm trying to use it on two shopping carts.

My question is in regards to Response/Receipt URLs. Do I need to enter the Response/Receipt URLs of the new site, since the default is the main site listed? Does it really matter?

I noticed that WooCommerce, my cart, has a plugin which sends Response/Receipt URLs to the processor via the default url of the shopping cart. I assume that this means, that the process is given the Response/Receipt URLs by way of the cart?

[lgn1]

It depends on the processor, and the risk category.

Our company has six different eCommerce sites (soon to be 8) and we all use the same merchant id/account number. We went with Chase Paymentech as they allow this, provided that your sites are all in the same risk category.

Moneris said we couldn't because they said is was a Visa/MC rule. When we found out they were lying, we dumped them for Chase Paymentech.

The processors make more money if you have multiple accounts, so I can understand why they don't like doing this.

[onlinesource]

Hi lgn1, thanks for replying. I guess my question is, did you do anything special but just install a payment module and enter the same id, transaction keys, etc on the same sites? I just keep thinking that the processor will see multiple charges coming from different sites to the same account and flag it? I didn't know if you did something with your response/receipt urls or just ignore that, add your account details and roll with it? :)

[lgn1]

Hi Onlinesource

The information in the payment module is identical across the various websites (ie merchant ids, transaction keys etc). Just make sure your order numbers between sites, don't overlap, as chase paymentech will decline unique order numbers (or did 5 years ago when we first set this up)

We had Chase Paymentech setup our identification (as shown on customer statement) as our company name, as we had multiple websites. We send our own electronic copy of the receipt, and we state in bold at the top of the receipt the company name, and for what website the charge is from.

No charge backs in 5 years, and only two inquires which the customer withdrew, after we reminded them what the charge was for.

The only caveat is that we did this 5 years ago, and we may be grandfathered, and policies may have changed with Chase Paymentech since then.

Also, the chase paymentech payment module must be be tested and verified, and this often takes a few weeks.