Avalanche News - 2004

The Avalanche Center leaves iTransact and iPayment

iTransact Proves unable to block frequent unsuccessful attempts at fraud
Charges from iPayment total over $1500

October 12, 2004

While we were forced to make rapid changes due to this costly incident there was no breach of security. Valid transactions were successfully processed and invalid ones were declined. The rapid repeated attempts at getting cards through successfully most likely came from some person or group with a set of card numbers obtained elsewhere, which they keep retrying with different verification information hoping to hit the right combination.

This incident was possibly the most significant and costly problem we've encountered since we began operating ten years ago. The nutshell version is that some credit card criminals began using our iTransact interface to rapidly resubmit transaction attempts. iTransact has no ability to filter or block these attempts, which resulted in iPayment deactivating our account after charging us in excess of $1500 in transaction attempt fees. (They charge .30 - .35 per transaction attempt, whether it is rejected or valid. Apparently there were somewhere on the order of 5000 such attempts.) iTransact seems unable to resolve the technical issue, and iPayment has no interest in refunding any of what they took. Visa is entirely unresponsive. All three pass the blame around with nobody taking responsibility.

Details

For many years we have accepted credit cards using iTransact for the internet based bank processing. After much frustration with Cardservice International we moved our merchant account to iPayment at the suggestion of iTransact since the two are supposed to work together well. Until recently we had no problems.

In early September of 2004 we were notified by iPayment that a large number of transaction attempts were being made with our account. We were able to verify this on our interface but had no idea of the magnitude of the problem.We immediately discussed the problem with iTransact but they had no solutions, so we made a few small adjustments and told iPayment that we had worked with iTransact to impliment currently available filters but that they couldn't do anything more about this at the moment. (Current filters allow a particular computer to be blocked by its IP number from repeated tries, but the criminals are now "spoofing" or falsifying this on each transaction attempt.)

Nobody was in the office during (and prior to) the ISSW in Jackson in September but the problem continued and iPayment shut down our account, with no notification. Over time we received a couple e-mails about problems ordering and we immediately spoke to iPayment and iTransact. For two companies which are supposed to work together well it took a lot of effort to get anything resolved at all. In the end they agreed to reopen the account for manual entry by us only. iTransact seems to have no idea what to do about this. They claim to be working on it and to be concerned but over a month later they seem to have no resolution. Meanwhile we are subject to the extremely high fees assessed by iPayment with no apparent recourse.

For the first few days of October a huge amount of time and effort was put into attempting to program a possible solution on our order form in the form of a CAPTCHA screen, where a person has to read the characters in a graphic and type them in. It might help, it might not. Unfortunately the server environment is does not have current versions of the program modules necessary to do this, even though they claim to support these. (Perl mod GD and ImageMagick.) The current versions cannot be directly installed due to permissions, a fact it took several days of work to establish. (If we upgrade to a new server plan we would have a lot more flexibility, but there is no other compelling reason and this is a bad time of year to get into such a move.)

So as of October 4, 2004 we could not even try a CAPTCHA approach with our current cart and forms, we had no hope of iTransact fixing the processing (which is what we've been paying them fees for), and we may end up paying iPayment about $1500 for nothing. It wasn't clear if we could make the current system work again or not. Moving to a new merchant account and internet gateway is very time and labor intensive (and has high fees), but it was clear that it was time to get away from iPayment and iTransact.

The Solution

Ultimately we discovered that PayPal will process credit card transactions for business account holders. We have had a business account with them for a long time so this was very welcome news. Customers are not required to have a PayPal account. The contribution page has been rewritten to work with PayPal, and the return page is even better with a script that records the transaction immediately and invites the contributor to set up a Contributor Services account right away. The store shopping cart has been modified also, although very few changes at all were necessary to port it over to the PayPal system. However, once we got into the shopping cart code it was discovered that there is much room for improvement, and it was largely rewritten with some further enhancements still planned.

The week following these changes PayPal was not working for three to four days! However, they seem to have resolved whatever problems they were having. PayPal has been around a long time and has an excellent security record. They are now owned by ebay. Their importance in web commerce was reflected by hundreds of newsgroup postings during the multi-day outage, and they clearly have an incentive to address problems of any type very quickly.

This migration to PayPal turns out to have many advantages for the Avalanche Center and customers/contributors. For the CSAC there are no monthly fees or minimums and no per-transaction charges for declined transactions. Closing our iTransact and iPayment accounts will probably save over $50 each month. PayPal also offers a variety of protection plans for both the merchant and the customer. While the CSAC has never had a serious dispute over any sale in many years of online commerce the extra protection plans from PayPal will still provide additional peace of mind for anyone nervous about internet transactions. (The lack of any fees for declined transactions begs the question of why iPayment charged such fees and why they are unable to refund them.)

Addendum:

iPayment is now Paysafe

After moving to PayPal they had some outages. While no reason was given they probably had to find a solution to the same problem. The outages were annoying but we never suffered this problem and whatever they were were fixing was completely relatively promptly.

Paypal is not without risks as well, although we have not had this type of problem. Fortunately we learned of our vulnerability on a small order. We shipped a study kit to the UK, with tracking and via the means we charge for. The customer claimed it was not received even though it was still in transit. PayPal refunded him and of course we never received the product back. For internntional orders of any size/value it seems like a bank transfer will be our only means of accepting payment without undue risk. However, other than that underhanded means of theft we have not suffered any other problems with PayPal.

- Contributors can log in for advertising-free pages.

www.avalanche-center.org