AbleCommerce Shopping Cart Software

Has there been any interest in adding support for Authorize.Net DPM to AbleCommerce?

It would seem to greatly alleviate the PCI compliance requirements for Able Gold.

We are also interested in knowing this. Based on all of the information I've looked at:

• Standard Payment Gateway = SAQ D
• PayPal Checkout = SAQ A
• Direct Post Method = SAQ A-EP

SAQ D compliance is nearly impossible for most small to mid-sized businesses to achieve. Only 11% of all merchants who qualify for SAQ D are actually compliant. PCI 3.0 requirements have made this even more difficult due to the documentation and logging requirements.

Using PayPal (or any other fully outsourced payment provider) requires the website to give up full control of the checkout process and takes the customer away from the website.

Direct Post Method uses a payment form that is created and styled by the merchant and posts it directly to the gateway so that the credit card never hits the server. However, all of the processing occurs in the background, and as far as the customer can tell, they feel like they never left the retailer's website.

The one thing that always seems to throw a wrench into these clear-cut divisions is when the retailer accepts mail/phone orders. By accepting credit cards via mail/phone, you no longer qualify for SAQ A or SAQ A-EP. Based on the requirements of both environments, you now fall into SAQ D again.

However, I have heard that if you get the permission of your acquiring bank you can submit two SAQs instead of filling out the cumbersome SAQ D. For instance, with the banks approval a merchant may submit SAQ A-EP for their ecommerce operations and SAQ C-VT for their mail/phone order operations.

Joe, as an aside... I found an old post of yours when looking for Direct Post Method for AbleCommerce (https://www.ablemods.com/blog/post/2012 ... rce-7.aspx). Were you ever able to get this working for AC7? Do you mind sharing the process for submitting an order?

I'm not sure how you'd handle this. I'm assuming you'd want to pass Authorize.net an Order# for reference which would require submitting the order before the payment. But, until the user has clicked the "Pay Now"/"Complete Order" button they haven't really signaled their intent to complete the order.

The only way I could think of handling this was fire off an AJAX request to complete the order (put it in "Awaiting Payment" status) when the user clicks the button. The request would return the Order # and OrderId which you could then stuff into hidden fields before using JavaScript to submit the payment form to Authorize.net. If the Authorize.net transaction fails, you would put it into "Declined Payment" status. Otherwise it would record the payment and move it to "Payment Pending" if you are using AUTH Only, or "Shipment Pending" if you are using AUTH+CAPTURE.

I completed the project but was unhappy with the result. The first challenge was building an extra checkout page that has no other controls on it that could trigger a postback. The extra page only has the form fields for card payment data. Anything else and you risk sending card data back to your server code behind and compromising the entire process of isolation.

The secret to making it work with Able's checkout design was to pass the UserID value to ANet during the post.

That way, the callback page (sim.aspx) could validate the payment was successful, load up the User that requested checkout, obtain the user basket and proceed with checkout. Once checkout was complete, a manual payment record was generated and added to the order. Then a simple redirect to the receipt.aspx page.

However the nightmare starts when you try to troubleshoot it. The entire process is dependent on a live URL. So there is no way to debug it in a local environment. Once you've beaten your head against the wall for a week using trial-and-error with a live site, now you have to deploy it. At that point you open the (really) bad door of how to troubleshoot an issue after you go live. The callback must be a live URL.

So the first time it stops working, you're stuck manually editing live site files using trial-and-error to resolve the issue. That makes it near impossible to troubleshoot in shared hosting environments. Extensive logging would be required and even then it would be awkward and cumbersome to debug.

In my opinion, DPM is only useful in extremely basic straight-html checkout implementations. Anything beyond that, it simply isn't worth the stress the first time it doesn't work. Breaking checkout is a bad thing.

Joe, very interesting reading about your experiences.

"The first challenge was building an extra checkout page that has no other controls on it that could trigger a postback. ... Anything else and you risk sending card data back to your server code behind and compromising the entire process of isolation."

I think the primary challenge here is that by default ASP.net WebForms wraps everything in a server-side <asp:Form runat="server"> tag. Most of the ASP.net controls require this in order for databinding to work properly. The problem is, with Direct Post Method, we do not want to postback to our site; we want to post directly to Authorize.net. In order to do this you need to remove the asp:Form tag and use a standard HTML form with the fields required by the DPM. I'm not positive, but I'm guessing this completely screws up how AC7 utilizes scriptlets. So you probably ended up creating a "static" .aspx with some dynamic elements that did not utilize the normal AC7 layouts/scriptlets.

"The entire process is dependent on a live URL."

I agree, this is a total P.i.t.A., but I'm not sure there is a better way to do it. You are getting a response from an outside server. Passing it something like "localhost:55234" doesn't do it any good because it cannot respond to that. It would be sending the response to itself on port 55234.

"So the first time it stops working, you're stuck manually editing live site files using trial-and-error to resolve the issue."

Did you have an issue where you had everything working properly and it just stopped working? This one concerns me.

sweeperq wrote: In order to do this you need to remove the asp:Form tag and use a standard HTML form with the fields required by the DPM. I'm not positive, but I'm guessing this completely screws up how AC7 utilizes scriptlets.

You can avoid eliminating the form tag by simply forcing the postbackUrl of the submit button to point to the ANet url.

sweeperq wrote:Did you have an issue where you had everything working properly and it just stopped working? This one concerns me.

No the customization was never deployed. But there were several mentions of it online. Given the lack troubleshooting options, any issue that presented itself posed a significant risk. The risk to lost revenue was simply too great when other more reliable (albeit less PCI compliant) methods were available.

So, I was able to get a dummy Direct Post Method form to work, but now the question is how to tie it in to the AbleCommerce order process?

The problem is that I need to pass an Invoice/Order Number along with the DPM values so that I can tie it back to an order in the system. I thought about getting fancy with JavaScript and submitting the order in the background without payment and sending the actual generated order number along with the payment info to Authorize.net. While I can probably get it to work, it is a fragile hack, and I'm not 100% positive a PCI auditor wouldn't balk at looking at manipulating form inputs with JavaScript before posting to Authorize.net.

The other thing I considered was not completing the order until I received a valid response from Authorize.net. I would send the BasketId as the Invoice # in the DPM form. When I received the response from Authorize.net I would copy the BasketId, convert the basket to an order, add the BasketId as a custom field on the order, and add the payment details.

Do you see any potential issues with the second method?

I couldn't find a way to effectively use the Able order number given the life cycle of the DPM process. It's like PayPal. There's no guarantee the payment process will be completed. Thus as in PayPal, the order is committed first which generates an order number you can then send to DPM. The obvious downside is you consume order numbers for orders that may not necessarily be completed. And you will sometimes be left with orders that have no payment at all.

My solution was to implement a second order number using a different range. It's a hack, but it prevented regular order numbers from having gaps due to incomplete DPM payments.

Your second route is nearly identical to how I did it. I just sent UserId instead of BasketId so the SIM page could link back up to the shopper that triggered the DPM process in the first place. Otherwise your process is how I accomplished it using my second order number range.

BasketId isn't ideal for your DPM order numbers since the number gap will be substantial due to anonymous user traffic.

Thanks for your feedback. One question:

BasketId isn't ideal for your DPM order numbers since the number gap will be substantial due to anonymous user traffic.

Doesn't the same hold true if you are passing the UserId? As far as I know, anonymous users are created the same as baskets.

You're confusing the value you use to identify the shopper, versus the value you use for the order number to reference in the call to DPM.

I didn't use UserId to act as the order number. I created and maintained a custom order number to use for sending to DPM prior to the SIM callback.

I used UserId to identify what shopper triggered the DPM call.

Thank you for the clarification.