The only way to really know that an eCommerce system works is by testing it against a live credit card. Sandbox mode is great for the initial 90% of development, but once you’ve debugged it and worked out all the kinks it’s time to test it the way a normal customer would. You just can’t know for certain that it works until you try it against a live credit card.

My standard method is to test with a personal card and then instantly void the transaction inside the administrative portal of the software.1

The interesting thing about this is that you’d think that there would be no implications for that credit card’s statement and monthly payment for doing this. In the software test you initiate a transaction and then 60 seconds later you void that payment. Zero-sum game, right?

Turns out it’s not.

Let’s say that you have a statement from March 14 to April 12. During that period, you spend $2,300 on stuff. When that period comes to a close, your statement shows that you owe $2,300. You have an auto-pay set up that pays 15 days after your statement closing. It pays your total new balance, which is $2,300 (anything purchased after April 12 does not figure into this, since you’re now in a new period).

Next, let’s say that on April 13 you test an eCommerce system. You test a product that’s $600 and then you instantly void the transaction. Because you voided the transaction, the credit card company issues a credit to you for that $600 because, unlike statements which are frozen in time once generated, credits and payments are based on realtime numbers.2 This credit is instantly applied to the total new balance scheduled to pay on April 27. Your new total balance just went from $2,300 to $1,700. On April 27, an auto-payment is made for $1,700.

The following statement, April 13 to May 13, you spend $1,500, excluding the software test. Guess how much your auto-payment for this period is? $2,100, because of that $600 test. Also on this statement is a $600 credit because, even though it got applied to the previous billing cycle since credits are realtime, statements are frozen once generated and so it gets bumped to this one. So you’ll see a $600 credit on your statement that looks like it didn’t get applied to the statement. Which is true, because it didn’t.

The implication is that if you’re a software developer who’s testing an expensive product, you’re deferring the amount you pay your credit card company until a future statement, essentially kicking a financial can down the street. Even if your cashflow is solid and you’re not overdrafting your bank account, it’s still a nuisance. I see a couple of ways around this:

  1. Using the example above, you can make a manual payment of $2,300 after April 12. This way you’ll be confident that you’re not having a surprisingly exorbitant statement balance the following period.
  2. You can reduce the amount of the product from (again, using the example above3) $600 to $1. Since it truly does make a difference how much the product costs when testing it, I think this is the route I’d recommend.

Credit cards are weird.

  1. I.e. ↩︎
  2. This holds true of all credit card companies. ↩︎
  3. I’m trying to make these numbers sound true to life, but they’re contrived. ↩︎