Your Payment Engine ISN’T Your Processor!

By John Robinson

It seems like everyone’s using the internet these days to run transactions. Even brick-n-mortar businesses are using web-based software with USB magnetic strip readers, making their laptops into swipe terminals.

As fantastic as that is, it can confuse even the most sophisticated internet geek when something goes awry. Who should you call?

I just jumped through a bunch of hoops to fix a problem caused when a merchant didn’t realize their gateway wasn’t their processor. (If you are wondering what the difference is, I’m getting there! ) A batch failed (something that happens on occasion), probably because of a single, corrupted transaction. The merchant called the gateway, who offered to resubmit the batch, and then promptly resubmitted an already successful batch from a different day.

The result? A bunch of annoyed customers who’d been double-charged, chargebacks for the merchant (that we’ve since refunded and stricken from the record), and the merchant didn’t get paid for the failed batch. Sadly, the gateway probably wouldn’t have been able to identify the faulty transaction, as that’s a processing thing, much less fix the problem, and didn’t refer my merchant back to me.

This has all been fixed now, but as you can imagine, it was a bit painful. This was the worst issue I’ve dealt with regarding this misunderstanding. But I’ve talked with plenty of people who should know better who didn’t know who the processor was versus who their payment engine was. Even after multiple explanations.

It became clear this article needed writing.

Authorize.net , PC Charge , PayFlow Pro , CyberSource , etc., are not credit card processors; they are payment gateways.

The payment gateway is responsible for taking the card information and the transaction information and sending that over a network to the acquiring bank. When the acquiring bank gets its okay to authorize the transaction, they send that information back to your gateway, which then tells you it’s authorized.

The simplified analogy: Whatever you’re using to take payments, it functions as a terminal. Yes, some software has all sorts of things that are far more functional (recurring billing, detailed reporting, exporting to other software, etc.) than a terminal. However, ‘processing-wise’, it’s just a terminal.

To call them rather than your processor for authorization and settlement issues is a little like calling your terminal’s manufacturer. (Yes, I’m being blunt here, but it’s important to remember.)

I’ll save the differences between gateways and PC-based engines, etc., for another post. Or maybe Robb will beat me to the punch. My point here is: Once a transaction has asked for an authorization, problems with that transaction are now a processing problem, and the processor is usually not the creator of the payment gateway.

Like this post? Then subscribe by RSS | Email