Recommendations for best method for my needs?

[r3jjs]

Hopefully I will be brief, but not so brief to be useless.

I am switching our webstore over to to use authorize.net rather than handle our own credit card processing.

While I doubt I am going to get all of the flexibility I would like, not having to track my own PCI compliance will be well worth it, but I'm overwhelmed by the sheer number of choices and I cannot find out certain information about the "backend" of the credit card processing.

If I may, let me start with my details and then move onto my questions:

• We will be running on a shared hosting service (GoDaddy)
• My web store and shopping cart and home grown solutions and I don't mind doing the custom coding required to route things to authorize.net.
• Half my customers LOVE the computer, and half my customers would prefer to do everything over the phone. I'd love to be able to take a phone order, key it into my web store 'on the fly,' including any CC information.
• I'm lazy and I don't mind of the interface isn't "seamless,' as long as it works smoothly.

My questions are:

• Is it possible to 'split' an order once submitted? (As in, ship part of the order now, part of the order later? Total order amount may need changed to charge shipping on both batches?)
• Is it possible to add items to an order and increase the amount charged on the credit card? (Many times a customer will place an order for an item, then call up to ask if they need additional parts to go with it. If so, they request that I add it to their current order.)
• Is it possible to decrease an order amount or remove a line item. Decreasing or refunding an amount does seem possible.
• Do I still get the same "back-end" options in the account management screen regardless of which method I use to submit order information to authorize.net?

[Trevor · Accepted solution]

In order to minimize PCI compliance issues and have card numbers go directly to authorize.net, there are really 3 options.  The first two are Server Integration Method (SIM) and Direct Post Method (DPM).  Both SIM and DPM have very similar capabilities and are both designed for one time payments.  When running a transaction using either of these methods, the Authorization is run immediately and cannot be modified later.  It is only possible to capture that authorization for the same amount or less than was originally requested.

The other option that is availabie is to use the Customer Information Manager (CIM) with the newly available hosted forms.  CIM allows you to tokenize the customer's payment information and then use that token to generate additional transactions at a later time.  This would not allow you to modify the initial order, but it would allow you to create a second order if you needed to add more items.

The backend options are essentially the same regardless of what method you use.  You will have access to the virtual terminal for keying in transactions and the same information will be available in the transaction history.  The one difference is that if you use CIM, you will be able to lookup customer payment profiles and manually initiate charges against those profiles.

[r3jjs]

Thank you very much for the detailed and helpful reply!

Your answer confirms what I had figured to be true, but it is nice to hear confirmed.

At this point, I'll keep things simple and use CIM, though no doubt I will be adding that fairly soon.

I could not find any particular technical advantage over SIM vs DPM, so I've been looking at using DPM.  (Other reading suggests that SIM isn't a good option for shared hosting plan since data passes 'through' servers that may not be fully DCI compliant.  DPM seems to be a 'sure' thing since the post goes directly to authorize.net.)

Thanks for confirming that the back-end is the same regardless of SIM vs DPM so I won't be locking myself out of some needed feature by front-end choice.