Multiple carts with one authorize.net account

I've searched but haven't found a solid answer.

I have a client that currently has one cart setup using authorize.net for the gateway. My client wants to create 2 more stores totally independent from each other and the current one. Problem is, he wants to know if these 3 seperate stores can us the one same authorize.net account.

I think I can and here is my reason. I ran a Miva store once that used StoneEdge order manager. The Miva store did the cc processing through authorize.net and the orders were downloaded to the order manager.

From within the order manager I could then create and process manual orders that processed the cc through auth.net as well.

So considering Miva as one store, and order manager as a second seperate store, I believe I was doing the same thing my client wants to do now.

Any thoughts? Has anyone tried this? I've seen the thread about multiple store fronts using one checkout, but I'm not sure that is the route I want to go. Setting up seperate carts would be much easier I think.

I'm not familiar with authorize.net, but I don't see any reason why multiple stores can't use the same authorize.net account just as you described. authorize.net shouldn't be all that concerned with the source (store A or store B) as long as the account information is correct.

You need to contact AuthorizeNet to ask them for sure. Most Merchant accounts do not allow charges from multiple sites.

Kim:

You need to contact AuthorizeNet to ask them for sure. Most Merchant accounts do not allow charges from multiple sites.

Kim's correct. Most TOS will prohibit that.

However, there are some technical issues around it that warrant explanation:

1. Your Authorize.net account is a "gateway" account, used to interface from websites to have money sent through a merchant account.
   One "gateway" account can only ever be tied to one merchant account.
   Each merchant account can only ever be tied to one bank account.

So, if you were to use your single Authorize.net (or other) gateway account on multiple stores, all your collected monies would be processed by the one merchant account, and deposited to the one bank account.

Thus, if you needed to separate the monies, you'd need separate bank, merchant, and gateway accounts (and pay the associated fees).

2. Each gateway account is configured to put a certain name on customers' receipts and credit card statements.
   If you're running two stores, perhaps Roberts Shoes and Marys Jewellery, and your gateway account is for Roberts Shoes, your Jewellery customers may not like the look of "Roberts Shoes" showing on their credit card statements.

While the visual look is one thing, the big problem with this is chargebacks.
If Corina comes along to Mary's Jewellery shop and buys a $800 necklace, but then at the end of the month her husband reviews their credit card statement and sees an $800 purchase from Roberts Shoes, he's likely to start asking questions. And, if he's like most, will likely call the credit card company and say "my wife never bought any shoes this month ... this $800 charge must be wrong". And then you have to dispute the chargeback. And chargebacks do not reflect well on your credit history.

So ... the safest way is to have separate accounts for each separate business.

Almost all payment processors work the way DrByte describes, and the chargeback thing is the biggest problem.

However, many beginners don't think they can afford 20-30 dollars a month for each website they sell from, and many processors' TOS don't prohibit multiple sites, as long as all the money goes into the same account, and all the customers will see the same seller account name.

There is one processor, fastcharge.com, which allows unlimited sub-accounts, but a search of the Zencart forum suggests that there isn't a working module that supports it.

Might be a project there for someone who knows a lot more about this stuff than I do.

For their part, Fastcharge says this:> To determine if your shopping cart is compatible find out if you can change the Gateway URL it accesses. If you can change this to "https://trans.secure-fastcharge.com/cgi-bin/authorize.cgi" your cart will work with our gateway. NOTE: We haven't found any stand alone shopping carts that won't allow this.
Steve

DrByte:

Kim's correct. Most TOS will prohibit that.

However, there are some technical issues around it that warrant explanation:

1. Your Authorize.net account is a "gateway" account, used to interface from websites to have money sent through a merchant account.
   One "gateway" account can only ever be tied to one merchant account.
   Each merchant account can only ever be tied to one bank account.

So, if you were to use your single Authorize.net (or other) gateway account on multiple stores, all your collected monies would be processed by the one merchant account, and deposited to the one bank account.

Thus, if you needed to separate the monies, you'd need separate bank, merchant, and gateway accounts (and pay the associated fees).

2. Each gateway account is configured to put a certain name on customers' receipts and credit card statements.
   If you're running two stores, perhaps Roberts Shoes and Marys Jewellery, and your gateway account is for Roberts Shoes, your Jewellery customers may not like the look of "Roberts Shoes" showing on their credit card statements.

While the visual look is one thing, the big problem with this is chargebacks.
If Corina comes along to Mary's Jewellery shop and buys a $800 necklace, but then at the end of the month her husband reviews their credit card statement and sees an $800 purchase from Roberts Shoes, he's likely to start asking questions. And, if he's like most, will likely call the credit card company and say "my wife never bought any shoes this month ... this $800 charge must be wrong". And then you have to dispute the chargeback. And chargebacks do not reflect well on your credit history.

So ... the safest way is to have separate accounts for each separate business.

Yes, I understand both issues and that is not a problem. It is one company that wants to setup a seperate site for some of the products they sell. They have products for dieters and some of the products are marketed towards body builders. So they wanted a second site that targeted body builders with only the products that are meant for them.

So having all the monies going to one account is not a problem. Nor is the business name a problem as it would still be the same.

I've contacted auth.net and I'm waiting on a reply. I'll update here with their answer for all to see.

It'll be interesting to hear what they have to say. I've been on several sites that have some sort of disclaimer that the charge will appear as (to use DrByte's example) "Robert's Shoes" even though you're buying from "Mary's Jewellery".

Well, I got my answer from auth.net today. They say yes,
They will all just need to have the same API Login ID and transaction Key.

I am attempting to do this same thing too with auth.net. My website has been purchased by another company doing the same thing we do and we don't want to shut down any sites. However, since everything is going to the same account, it doesn't matter if we use the same merchant account.

The only potential problem I see is the default receipt URL - if the receipt URL is, for some odd reason, not passed properly, you may end up on the wrong site for your receipt.

Also, make sure you add both response URLs to your list too - otherwise, you'll have a site with rejected transactions.

safewatch:

The only potential problem I see is the default receipt URL - if the receipt URL is, for some odd reason, not passed properly, you may end up on the wrong site for your receipt.

Also, make sure you add both response URLs to your list too - otherwise, you'll have a site with rejected transactions.

If you're using the more reliable AIM module, instead of SIM, you don't have to worry about "receipt URL" or "response URL" settings ... because they're not used.

DrByte
If that is the case with AIM then how is success/failure info passed back to the site? If multiple sites are using one authnet account, then isnt it possible that success / failure info could potentially passed to the wrong site?

makenoiz

The AIM method does a direct private communication to the authnet site in the background while your customer waits. Basically it takes all the info entered by the customer, creates a transaction to send, sends it, and waits for the direct response that comes back to the same connection that opened the request. It's all private and happens behind-the-scenes. It's more secure because there's no way to intercept being returned to the wrong URLs etc because it doesn't need or use those settings, and there are no browser redirections to be intercepted either. Multiple sites can use it fine because the connection is kept open from beginning to end, not handed off to happen in multiple stages like SIM does.

I have a client who sells pet food, runs a co-op, sells coffee and quilts (I think that is all of her carts :-) She processes the card manually through a virtual terminal, but I have been talking to her about a gateway and automatic processing.

The answer of course, is to have a global name and bill everything through that account. I suggest that if you are starting up a business and may want to change the name or function, choose a billing name like "New York Enterprises" or "The Best Stuff" which is generic enough that you could sell coffee, quilts, dog food or whatever.

Think of "Google". The name could cover any kind of product or service. (You DO know that their home office is called GooglePlex?) :-)