3 ms·

Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never

by d_r 15y ago

Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number. http://developer.authorize.net/api/sim/ http://developer.authorize.net/api/sim/

poutine 15y ago
As does E-xact: http://www.e-xact.com/hosted-checkout/ http://www.e-xact.com/hosted-checkout/
sandGorgon 15y ago
Authorize.net's AIM gateway also allows the flexibility to authorize now and capture later - without the webapp needing to store the credit card info. Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.
- wiredfool 15y ago
  Everyone _should_ do that, as CCs generally take a dim view on charging before something actually ships.
  - sandGorgon 15y ago
    Yes - which is why what webapps do is only authorize AND charge when something actually ships. Most payment gateways (including Authorize.net's other products like SIM) support this workflow. The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance. I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.
drndown2007 15y ago
They also have CIM, Customer Information Manager, where you send the credit card info (thus never storing it yourself) and you get back a token. Anytime you need to charge that card, you charge the token instead. PCI compliance is then on Authorize.net
- seanharper 15y ago
  Pretty much every gateway has some kind of tokenization solution (or reference transaction solution) that accomplishes the same thing. They all call it something different and try to make it seem like it is unique, which can be confusing.
- guac 15y ago
  Even if you aren't storing card information you still are subject to PCI compliance if the card information passes through your application/server. In the case where you are processing but not storing you would need to complete the SAQ-C questionnaire and still probably be subject to quarterly scans (the self-assessment where are you storing data is SAQ-D) https://www.pcisecuritystandards.org/merchants/self_assessment_form.php https://www.pcisecuritystandards.org/merchants/self_assessme...
- dangrossman 15y ago
  Unless you're also using one of those subscription-as-a-service startups to host the payment forms, no, PCI compliance is on you with CIM. The payment information passes through your server, so you're 100% required to meet all 200+ of the requirements of the standard, quarterly scans of your servers, etc. Secure storage is only one small subset of the requirements.

by d_r 15y ago

poutine 15y ago

As does E-xact: http://www.e-xact.com/hosted-checkout/ http://www.e-xact.com/hosted-checkout/

sandGorgon 15y ago

Authorize.net's AIM gateway also allows the flexibility to authorize now and capture later - without the webapp needing to store the credit card info. Pretty nice if you want to do things like "we'll bill your credit card only when item ships", etc.

wiredfool 15y ago
Everyone _should_ do that, as CCs generally take a dim view on charging before something actually ships.
- sandGorgon 15y ago
  Yes - which is why what webapps do is only authorize AND charge when something actually ships. Most payment gateways (including Authorize.net's other products like SIM) support this workflow. The reason is because, to do something like AIM or CIM, payment gateways need to store CVV numbers as well, resulting in a very expensive level of PCI compliance. I'm not extremely well versed with fraud semantics, but IMHO placing an authorize on a card reduces the risk of fraud, refusing to pay, etc.

drndown2007 15y ago

They also have CIM, Customer Information Manager, where you send the credit card info (thus never storing it yourself) and you get back a token. Anytime you need to charge that card, you charge the token instead. PCI compliance is then on Authorize.net

seanharper 15y ago
Pretty much every gateway has some kind of tokenization solution (or reference transaction solution) that accomplishes the same thing. They all call it something different and try to make it seem like it is unique, which can be confusing.
guac 15y ago
Even if you aren't storing card information you still are subject to PCI compliance if the card information passes through your application/server. In the case where you are processing but not storing you would need to complete the SAQ-C questionnaire and still probably be subject to quarterly scans (the self-assessment where are you storing data is SAQ-D) https://www.pcisecuritystandards.org/merchants/self_assessment_form.php https://www.pcisecuritystandards.org/merchants/self_assessme...
dangrossman 15y ago
Unless you're also using one of those subscription-as-a-service startups to host the payment forms, no, PCI compliance is on you with CIM. The payment information passes through your server, so you're 100% required to meet all 200+ of the requirements of the standard, quarterly scans of your servers, etc. Secure storage is only one small subset of the requirements.