I'm looking for information and my searching is coming up short, since this is unfamiliar territory. I need to create a portal site that will allow logged in users make purchases at multiple unrelated merchants with whom I have a relationship with. However, I need to make the purchases look like they are being accomplished by the portal, as well as "store" the users credit card information to make future purchases easy. (I'm aware of the PCI issues and really want to license all the bits)

The concept is loosely similar to Amazon merchants, but I don't want to get involved in the transaction. In one sense, the site would be a reseller site for products from the merchant, but I can't do a redirect to the merchant. In another sense, it is just the portal being a middle man, wanting to get out of the way of the financial transaction but provide all the other information.

The only way I have thought to accomplish this is to (a) become a third party processor (not really an option) or (b) force the merchants to have a PayPal account, let PayPal be my "wallet", and make my site have a shopping cart that purchases via PayPal using third party authentication.

I know that legally you can't collect the credit card info unless your the merchant, but if the merchant is using the portal as a third-party cart, that seems like it might work.

Is there another approach?

I've read this three times, but I still don't really understand what you want to do.

Can you explain a bit more? :)

I've read this three times, but I still don't really understand what you want to do.

Can you explain a bit more? :)

Sure, but I now believe what I want to do cannot be done within the confines of a normal merchant account.

Here's a fictional scenario.

I want to create a portal website called MartianSpeakers.mars that caters to those that speak and read the Martian language. I have three existing merchant partners with existing ecommerce sites that sell items that are willing to work with me.

The MartianSpeakers.mars portal site will display items from the partners in a format that appeals to Martians. I'll get an xml feed with products to display. When purchase time comes, I want to let the site visitor buy the product. Since the merchant doesn't speak Martian, or have Martian shopping carts on their existing system, I have to create those and run the whole process for the merchant. I then want the customer to buy from the merchant, using the merchant's credit processor, but my customized shopping cart. MartianSpeakers.mars won't be involved in the actual financial transaction.

The second part is that MartianSpeakers.mars will hold the credit card information for the Martian customer so they don't have to enter it every time. I want the Martian customer to only have to enter a PIN to use their credit information to buy something from partner B, even though the only bought from partner A a previous time.

The first part is a specialized ecommerce hosting type thing. I can customize existing cart software to fit. The second part is a wallet-type application, but I think that the wallet can't be done for legal/contractual reasons according to Visa/MC rules regarding who can see/store credit card information. But I may be wrong on this, or they may be some other way to do it.

Ah.. that makes sense now.

- I don't believe you are allowed to hold the credit card details of a "customer" that is not really your customer. (Since they are purchasing from the merchant and not from you..) You might want to check with Visa/MC/Amex about that, as I'm pretty sure this is not allowed.

For the first part, what you are describing is sounds like an "advanced affiliate program". So you would basically be an affiliate for the individual merchants, hosting your own "sales website", but the actual purchase is directly between the customer and the merchant and you get some kind of reward.

In that case, the only way to do this would be if your merchant partners have some kind of "payment/order API". So you would take the cc info provided by the customer along with the order details, and then "send" it to your merchant partner who processes everything. As far as the customer sees, they are dealing with you directly.

I see a lot of problems with this.

1 - I'm pretty sure Visa/MC/Amex would not allow this.
2 - It's a big risk for the merchant to have such an API, since they would not know anything about the actual customer whose card they are charging. At the very least, this most likely would violate their merchant account agreement, and at most would result in possibly a lot of fraud liability since they certainly can't go after YOU for providing a fraud customer, right?

In theory, this is a great idea. Sort of a "consolidator" website/portal for many merchants. Like an online mall.

But in reality, I don't think this can work unless there is some way around the credit card processing and liability issues.

I think step one in your plan should be to have a chat with MC/Visa/Amex and see what they think.

- I don't believe you are allowed to hold the credit card details of a "customer" that is not really your customer. (Since they are purchasing from the merchant and not from you..) You might want to check with Visa/MC/Amex about that, as I'm pretty sure this is not allowed.


I think this is not correct. I currently have a merchant account with company X. Company Y keeps the credit card information as I need to charge my customers each month (recurring billing). Customers do not know about company Y who charges them, only about me.

According to my experience, your project is totally ok.

I think this is not correct. I currently have a merchant account with company X. Company Y keeps the credit card information as I need to charge my customers each month (recurring billing). Customers do not know about company Y who charges them, only about me.

According to my experience, your project is totally ok.

Check out this explanation here from 2checkout (sorry, can't post URL yet, but 2checkout is the domain without the dot-com):
2checkout/community/blog/newest/collecting-credit-card-information/#more-339

I'm pretty sure what you are doing isn't wrong if you are using company Y purely as your service provider. That is, you have outsourced your shopping cart/credit authorization, and company Y is really holding credit card information for you, not for them, and they are PCI compliant.

If there was a company Z involved that you had no knowledge of, then company Y couldn't use the credit card information gathered for your merchant account for any new purchases made to company Z, even though they have a record of it in a database and they know the user is the same one.

That is effectively what I am trying to do (well half of it anyway) and I now believe it isn't allowed. If company Y is doing such a thing, I'd love to know who company Y is, so I can study their business model.

I'm pretty sure what you are doing isn't wrong if you are using company Y purely as your service provider. That is, you have outsourced your shopping cart/credit authorization, and company Y is really holding credit card information for you, not for them, and they are PCI compliant.


If you make a portal for merchants to sell items where you collect cc info and send it to payment processor then you would be a service provider. You only need to check what rules apply to service providers.

Your 2checkout example does not fit into this since it is a 3rd party processor. They collect the cc info and send you money. A service provider keeps and passes the cc info. They don't send you money.

I've just come across mshopper.net. It seems really similar to what I described. They allow price comparison on lots of stores, and let you purchase with a pre-stored credit card from many stores. They claim:


Once you've found your product, select the "But It Now" button. If you have registered on this site, you will be prompted to enter your security PIN. Enter your PIN, and you can buy this product in seconds.

I checked my merchant account info and it seems that the cc info collected for a merchant account is linked to that merchant account. It cannot be used to make a purchase with another merchant account.

You could store the cc info per merchant account. Users would need to enter the cc info only if it is the first time they buy from this merchant.

A lot of major sites do not store the cc info, only the billing address. Storing cc info is mainly used for recurring billing.