I’ve integrated a few payment gateways over the years including Authorize.net, WePay, Spreedly, and Stripe but recently had the opportunity to integrate Authorize.net into our system. It’s actually not the first time I’ve integrated Authorize.net as I did a server-side implementation years ago when server-side implementations were still cool. I mention this to show I’ve seen a couple of ways this can be implemented. Maybe I’m missing something but the new Accept.js model seems to fall short in what seems like the most basic ways.

For example, our checkout experience has the customer filling out a bunch of details for the purchase, clicking a purchase button which validates the form, and provided it passes validation shows the payment form. With Spreedly I can get this behaviour by calling an openView() method after the form has been validated but Accept.js doesn’t appear to have a way to do this. Their implementation has you create an element with a specific class that they then bind an event to which has to be available when the DOM is loaded. There doesn’t appear to be any way to add the class after validation. It seems like an odd omission since I have to believe I’m not the first to want that.

Another example is when the buyer gets to the payment form modal and sees they have entered their personal address instead of their work address so they click the X on the payment modal. Is there an easy way to respond to that behavior? Again, I couldn’t find it. I had to listen for a message with the type of CLOSE_IFRAME which isn’t exactly hard except it’s not documented so I had to source dive to figure out what event to listen for. It seems strange there isn’t an onAuthWindowClose() method that takes a callback to deal with the modal being closed.

The final example I’ve got regards documentation and support. It wasn’t clear to me which “product” I needed when I started this process and one of our goals was to have as little PCI liability as possible so I started the integration with Accept Hosted thinking this was the best choice for us. It was only after I’d gotten to charging the card that I realized they don’t offer a way to get a tokenized card so I could validate on the server side. I’m unclear how other people are dealing with confirming the order but suspect I could have gotten what I wanted by looking at webhooks. I ended up switching to Accept.js which does offer the tokenized card that gets confirmed server side. Perhaps it’s on me for not reading the documentation more thoroughly but it was one of those points of confusion that would have been great to avoid. For some reason the documentation felt like a maze where every click resulted in a new tab. When I reached out for help I posted on their developer forum and it’s been 11 days with no response. Only later did I learn there appears to also be a StackOverflow sub-site for Authorize.net which possibly is the new way to get “support”. I know it’s very hard to make things clear to everyone and possibly no solution accommodates everyone but two things I’d personally do are:

  • Find a way to make the “blessed” path clearer and ideally with less clicks.
  • Don’t combine integration methods. Normally I’d prefer content all on one page because it makes searching easier. Having all the integration “types” (e.g. “Integrating Accept.js into Your Payment Form” & “Integrating the Hosted Payment Information Form”) on the same page made it easy to scroll up too far and be looking at a different integration type than you were working on.

None of these are big issues or even that hard to work around but it got me thinking about software paper cuts and how that extra level of polish is hard to quantify but it can be felt. I know there are differing views on how to deal with these and even how big a deal they are but I lean towards them being a bigger deal than people realize precisely because it’s hard to quantify them. It feels similar in concept to popups asking for your email. There are absolutely tasteful and non-intrusive ways of asking for a patron’s email. Unfortunately, they don’t seem to be the norm and instead, we get popups as soon as the page is loaded with no interaction and sometimes without enough time to read the article. Some segment of the population just fills these out because it’s being asked for. For me and I know other people it just associates a bad vibe with your organization. Maybe it’s not enough to get me to not come back tomorrow but given enough of those types of interactions you will lose me more permanently.

The other thought I had and at this point I’m certainly talking out of turn and am speaking above my pay grade but the pricing is now 2.9% and $0.30 + a $29/month merchant account fee. In some sense, it makes total sense that they would do this. The old modal was opaque and harder to figure out because it depended on the volume and type of the cards you were accepting. With that said, my understanding was most of our clients chose Authorize.net because if you had good credit and after going through the “pain” of being vetted you could get a much better rate than that. This is likely still true if you negotiate with their sales reps but on getting reacquainted with their offering it felt like they lost one of the key selling points or points of differentiation. So if I’m reviewing choices I’ve got Stripe on one hand which is 2.9% + $0.30 or I’ve got Authorize.net which is 2.9% + $0.30 + $29/month which also subjectively has a worse onboarding experience overall.