I have been doing a lot of research to better understand the relationships between site-store-gateways-merchant accounts. Here is what I think I know:
A: If you want to process credit cards on your site you need a PCI compliant server. For most small companies and certainly anyone using shared hosting that is not a viable option, so:
B: You could install a shopping cart on your site, but it would need to talk to a gateway to handle the secure part of the transaction - collecting and processing the credit card to the gateway who then passes it on to the merchant services provider. In this scenario you have to still be concerned somewhat with the security of the site and the shopping cart portion of it and you are going to pay both a gateways fees and your merchant services fees?
C: If you use Miva Merchant as your storefront then you really don't need to worry about the security on your site's server as you are going to hand off the store portion of your site to Miva and then Miva passes the purchase over to - and here is the part where I am a little confused -
Let's say I have Chase Paymentech - In this case Miva can talk directly to Paymentech (I guess they have their own built in gateway?) and I don't need a separate gateway provider?
Let's say I have another company for merchant services - will call it "Great Banking" for example. I am guessing great banking while providing merchant services doesn't have a gateway? Is this the point when you would need a company such as Authorize.net? I've been on their (Authorize.net) web site and I guess I don't entirely understand what they (or companies like them) do. They don't seem to be a store front like Miva nor do they appear to be a Merchant Services company. They also add a layer of cost. I think Authorize.net says they support Chase Paymentech but why would you need them? For stores that don't support Paymentech directly?
I think part of what is confusing is that all merchant services company seem to have some facility for communicating with online systems (an API) that allows gateways to interface but don't actually always have gateways themselves?
This seems like a puzzle in my understanding and I want to make sure I am properly grasping how it all works. So to summarize:
Store needs to talk to a gateway - some merchant services have a gateway built in but the store must be coded to work with it. If a store wants to just talk to popular gateways it's easier for them because they don't have to worry about communicating with all the individual merchant services providers, just the popular gateways. The gateways then do all the work of communicating with the various merchant services companies?
I hope I have been clear in my confusion - hoping someone can shed some light on all of this and let me know if my understanding is correct. Thanks for any provided enlightenment!
Scott
A: If you want to process credit cards on your site you need a PCI compliant server. For most small companies and certainly anyone using shared hosting that is not a viable option, so:
B: You could install a shopping cart on your site, but it would need to talk to a gateway to handle the secure part of the transaction - collecting and processing the credit card to the gateway who then passes it on to the merchant services provider. In this scenario you have to still be concerned somewhat with the security of the site and the shopping cart portion of it and you are going to pay both a gateways fees and your merchant services fees?
C: If you use Miva Merchant as your storefront then you really don't need to worry about the security on your site's server as you are going to hand off the store portion of your site to Miva and then Miva passes the purchase over to - and here is the part where I am a little confused -
Let's say I have Chase Paymentech - In this case Miva can talk directly to Paymentech (I guess they have their own built in gateway?) and I don't need a separate gateway provider?
Let's say I have another company for merchant services - will call it "Great Banking" for example. I am guessing great banking while providing merchant services doesn't have a gateway? Is this the point when you would need a company such as Authorize.net? I've been on their (Authorize.net) web site and I guess I don't entirely understand what they (or companies like them) do. They don't seem to be a store front like Miva nor do they appear to be a Merchant Services company. They also add a layer of cost. I think Authorize.net says they support Chase Paymentech but why would you need them? For stores that don't support Paymentech directly?
I think part of what is confusing is that all merchant services company seem to have some facility for communicating with online systems (an API) that allows gateways to interface but don't actually always have gateways themselves?
This seems like a puzzle in my understanding and I want to make sure I am properly grasping how it all works. So to summarize:
Store needs to talk to a gateway - some merchant services have a gateway built in but the store must be coded to work with it. If a store wants to just talk to popular gateways it's easier for them because they don't have to worry about communicating with all the individual merchant services providers, just the popular gateways. The gateways then do all the work of communicating with the various merchant services companies?
I hope I have been clear in my confusion - hoping someone can shed some light on all of this and let me know if my understanding is correct. Thanks for any provided enlightenment!
Scott
Comment