Authorize.net Duplicate Transaction Settlement Error

Authorize.Net experienced an issue during a system update on October 17th that caused a subset of previously settled transactions from September to be sent for settlement again between October 17th and 18th. This issue is no longer occurring.

Authorize.Net is currently working to address any duplicate transactions in order to resolve the duplicate funding to merchants and potential duplicate transactions to their customers. We have already contacted your affected merchants and will continue to do so as we have updates.

If your merchants contact you about this issue, please advise them to NOT take any action on these transactions while we work to address them.

We will follow up with you with any further information, including information on potential reimbursements, as it becomes available.

To locate these transactions, please have your merchants follow these steps:
Log into the Merchant Interface at https://account.authorize.net/.
Click Search from the main toolbar.
Click Search by Batch from the menu on the left.
Select October 18 and October 17 in the From and To drop-down boxes in the Settlement Date section.
Click Search.
Any impacted transactions will have a Submit Date from September 20-25.

We apologize for this error and any inconvenience it may have caused. If you have any questions regarding this email, please contact support.

Sincerely,
Authorize.Net

###

Blogger Note: While uncommon, duplicate transaction and duplicate settlement issues do happen. They can emanate from anywhere in the transaction chain, though the payment gateway, or payment processor are likely more common causes. Because of that, merchants are advised to do nothing and the party that caused the problem usually reverses all the errors on behalf of merchants, typically within a day or two.

Stopping Online Credit Card Testers

Online credit card testing by fraudsters can dramatically drive up payment gateway fees.  Historically, card not present financial fraud grows exponentially in countries after implementing EMV chip card processing, as thieves seek the weakest link for fake credit card purchases. Thieves use software to rapidly send cardholder data to payment web sites to verify if stolen cards are good, card testing, and since merchants pay a per transaction fee, regardless of approval, the financial impact can be devastating.

Companies with online pay pages are at increased risk. Since October 2015, online fraud attacks were up 11% 2015 Q4 Vs Q3, and up 215 percent from 2015 Q1. 83% of attacks involved botnets. Source: The Global Fraud Attack Index™, a PYMNTS/Forter collaboration. The preferred web pay pages have no login required, and provide detailed decline response reasons. I’m often asked by others in the industry to provide the latter, and for the same reason as for retail, it’s better than no one knows the reason for the decline. If you inform a criminal the expiration date is no good, they just need to figure out the right one.

PREVENTING ONLINE CARD TESTING

A layered approach is required to stop card testers since no single solution will stop fraudsters. Generally, the harder you make it, the more likely they will seek a path of less resistance.

  • Block known fraudulent incoming IP addresses. The bad guys also use hostile proxy servers, with dynamically changing IP addresses every authorization attempt, but this is still a first step everyone should employ.

For additional assistance, please contact us. I won’t make it easier for criminals by identifying all the tools here in the blog!

Replacing ICVerify with authorize.net for caging service providers

ICVERIFY Software, a PC based payment software solution, is end of life and must be replaced with an internet, or cloud-based, payment gateway. Authorize.net is one replacement option for caging service providers, including donation processing, that doesn’t require changing credit card processing companies, also known as merchant services provider or acquirer. For business to business, I don’t recommend authorize.net, read about another ICVerify alternative here.

What’s the difference between ICVerify and Authorize.net Payment Gateway for Credit Card Processing for fundraising service providers?

  1. There’s no software to install. Users process payments via a virtual terminal by logging in to a secure web page and processing single transactions, or via batch upload.
  2. The merchant, or fundraising non-profit, completes a payment gateway application for each merchant account, just like any other financial account, with an authorized reseller, such as 3D Merchant Services.
  3. Transaction fees are standard. Fees can be paid via credit card or ACH debit. Merchants may have individual merchant accounts that include free gateway services, though unlikely, and there’s two limitations. First, if the merchant (non-profit or other entity) changes their acquirer, any tokens saved for recurring billing will be invalid. Second, it may increase lockbox service provider development and maintenance time for multiple gateway file specifications.
  4. Merchants are billed directly by Authorize.net for gateway fees, including when opened through authorized reseller 3D Merchant Services (Christine Speedy).
  5. Merchants control user access to payment gateway account

Christine Speedy alleviates the pain of switching merchants from ICVerify to authorize.net, including providing a single point of contact for all accounts, managing the application process, providing personal customer service, and offering volume transaction rates for entire client portfolio. Her payment expertise helps minimize fundraising expenses, reduce donor management friction, and reduce PCI Compliance burden. Merchants can call Christine or authorize.net for customer support after an account is opened.

REPLACING ICVERIFY – IMPACT FOR LOCKBOX SERVICE PROVIDER BATCH UPLOAD

  • Create a CSV file for upload to authorize.net, per file set up specifications
  • Login to merchant authorize.net account
  • Upload file
  • Download results the next day

REPLACING ICVERIFY – IMPACT FOR FUNDRAISERS / MERCHANTS

  • Open Authorize.net account; contact us for special volume rates
  • Add users and assign permissions, including users for your service provider
  • Download transaction reports on demand by logging into online portal via web page. Note, these reports are limited and do not replace, but rather supplement, reports from your lockbox service provider. 24 month record retention and search.
  • Authorize.net will automatically debit account monthly

Working with a single payment specialist for all fundraising channels maximizes net dollar educes PCI Compliance burden, misinformation, and

This article makes no reference to the value of authorize.net as a vendor selection, only the implementation and maintenance of using it as ICVerify alternative. Contact Christine Speedy at 954-942-0483 for all integrated, standalone and batch upload payment gateway needs from authorize.net and other solutions.

ERP and Payments: PCI Compliance Nightmare

A PCI Compliant ERP solution doesn’t make a merchant PCI Compliant. The features of the payment integration drive customer decisions to use or not use the an ERP payment module. When payment vendor choices are restricted artificially by using technology to control merchant services options, merchants often enter ERP relationships with a level of dissatisfaction right from the start.

Severely restricted payment gateway options, especially for business to business, results in either the merchant using an alternative non-integrated payment solution, thus sacrificing efficiency, or using the integrated solution, and failing to meet PCI 3.0 requirements or other payment needs. How can I make this statement? B2B companies that accept credit cards  typically have a portion of their sales via the telephone. To mitigate risk of fraud, they use paper credit card authorization forms. However, the forms are inherently risky in many ways.

  • Sensitive authentication data, which includes the security code (CVV/CID), can never be stored.
  • Forms offer option to send via email. Unprotected data cannot be sent via messaging technologies such as e-mail, instant messaging, chat, etc. (PCI section 4.2). Even if the form doesn’t offer it, customers sometimes ignore instructions and send via email.

In the absence of a best practice, employees will revert to whatever is necessary to get their job done and reduce the risk of looking bad (fraud losses). If the ERP payment module doesn’t help merchants eliminate credit card authorization forms, the entire operation may be at risk of a potential data breach.

For retail, data breaches have become commonplace. Few ERP Point of Sale (POS) solutions are using Point to Point (P2P) encryption and other best practices to reduce data breach risk. They raced to bring mobile to market, and many now have neither EMV chip terminals nor P2P, both increasing financial risk to merchants.

Why does an ERP restrict options for merchant services? Because it’s part of their revenue stream. When competition is eliminated, there’s almost no chance of having the best solution in the marketplace. The proof is a long string of failures to meet business needs. Failure to offer electronic bill presentment and payment, which would increase cash flow and efficiency. Failure to offer US EMV chip card acceptance solution prior to liability shift. Failure to offer level 3 processing for all sales channels. Failures reduce cash flow, profits, and security as companies attempt to work with the ERP limitations, or find ways to work around them.

The argument that it’s to protect merchants from data breaches is only partially true. For any modern payment gateway integration, the payment activity is usually outside the ERP to reduce PCI scope. That won’t change from one gateway to another, so the risk doesn’t change, provided the third party gateway is level 1 PCI Compliant.

Examples of ERP’s that restrict payment gateway and merchant services choices are Netsuite and Sage. Additionally, consultants are often compensated for payment gateway recommendations. Consulting with an independent payment specialist, like blog author Christine Speedy, can expose pros and cons of different options.

ERP’s holding onto merchant services and gateway revenue streams are short sighted, as these business practices that anger customers. Can you imagine if an ERP wouldn’t communicate with any other software, for example, Magento? ERP’s focused on delivering the best business software for all facets of a business, and enabling the merchant to follow best practices for PCI Compliance must give users the flexibility needed to run their business with their own financial partners.

If an ERP relies so much on their revenue stream from merchant services revenue share that they won’t let you choose your own financial partners, I’d think seriously about whether it’s the best ERP for your business.