Implementing Authorize.net Direct Post Method

[sweeperq]

So I looked at the AbleCommerce implementation of Authorize.net CIM and found it to closely mimic the standard AIM method. Unless I'm missing something, I'm not seeing why the effort was even made to implement it this way. Unless I'm mistaken it doesn't appear to be utilizing the tokenization, and the credit card details pass through the server leaving it in-scope for PCI compliance.

We are looking for a solution that keeps the credit card data from even touching our server in order to limit PCI scope. So now I'm back to figuring out how to implement the Direct Post Method (http://developer.authorize.net/api/dpm/). The basic idea is that your payment form submits directly to Authorize.net so credit card information never touches your server, Authorize.net passes the transaction and auth code to the store in the background, the store logs the payment and notifies Authorize.net where to redirect the customer, and Authorize.net redirects the customer to the receipt.

I was able to create a form that submits all the appropriate information (except the order number) and it properly registers the transaction in Authorize.net. I haven't started working on the handshake part yet because I'm developing on localhost, but you need a public IP/domain for Authorize.net to communicate with.

Before I get that far, I'm wondering how I am supposed to generate the order number to submit with the payment? I'd imagine it would have to work similar to PayPal Express, but I can't follow exactly how those orders are initially placed without payment details.

[ForumsAdmin]

The purpose of CIM is different. It allows you to store customer credit cards for future transactions. You are relieved from the storage related requirements as Authorize.NET servers take care of the secure storage and provide you a reference token that you can use for subsequent payments.

You have rightly identified DPM as the API which is used when you don't even want to have the payment data touch your servers. However keep in mind that integrating such payment APIs is slightly different from standard payment gateways. Depending on how the gateway communicates back with your server, you may have to implement callback handlers that will take care of the callbacks from the gateway.

The next order number is generated by StoreDataSource.GetNextOrderNumber method. This happens automatically when you do the Checkout. You should probably let this happen in the Checkout process and not do it manually. Once you let the CheckoutService.ExecuteCheckout complete, you can then process the payments for the order that is created.

[sweeperq]

Thanks for responding.

So how would you personally handle it? I was thinking we might have to submit all orders that make it to the payment page, stick them in a special status, then when we get the callback from Authorize.net move them to the correct status. The other option would be to submit the order id instead of the order number and not complete the order until we get the callback.

How is Paypal Express handled? Do you submit the order before handing it off to PayPal?

[ForumsAdmin]

Orders are created before payments can be processed. This is because of the way payment gateways work. They require an OrderId / OrderNumber that can be used to uniquely identify and order. The standard reference in AC Gold is order number.