"Policy" question: what would you do?

[Kent Multer]

Hi folks --

I've run into an odd situation with a client: a gateway company for whom I'm writing a custom payment module. As usual, the client gave me some dummy credit-card numbers to use for testing purposes. But those cards don't generate enough different types of responses for me to fully test the module. I asked them to give me some other card numbers, and they refused. They told me that I should either use my own card, or give them the URL so they can run some tests.

I don't like the idea of using my own credit cards for software testing. But if I let them do tests, the debugging process is going to get slowed down, because I have to wait for them to report a bug, then I change some code, then I ask them to do another test, etc. etc.

I've written quite a few payment modules, and I've never run into a situation like this before. Most gateways have dummy card numbers, as well as tricks such as setting the dollar amount to a specific value, that can be used to generate all the various types of Accept's and Decline's. No one has ever asked me to use my own credit card.

Does anyone have a recommendation about how to handle this?

Thanks --

[dotCOM_host]

Does that gateway not accept the usual test CC numbers? Most payment gateways I've run into either use the standard, well known test numbers, or have their own "always accept", "always decline", and other card numbers available for testing. What is the payment gateway involved here?

[ids]

I might have not completely understood something.

The gateway company is your client or your client uses that gateway?

FWIW, IMO, common sense probably won't prevail.

If the latter, your client should pony up real credit card #'s. Because they should be able to void transactions, etc.

If the client is the gateway company, I think you're dealing with a high class mickey mouse operation -- although I shouldn't besmirch Mickey's good name.

Either case, I don't think you're responsible for testing all scenerios if you don't have they necessary tools for testing them. I'd say without more help, write the code the best you can and document the limitations and possible problems with the gateway. Then of course charge them to fix it later when a problem comes up. The one sounds a little hanky to me. They are probably lucky to have you coding the interface.

FWIW,

Scott

[cagdas]

I ran into situations like these before where the gateway does not have a proper testing environment. Your best choice is to write your own test environment (a dummy server that emulates the gateway that you can write with PHP or ASP) based on the specifications. Obviously this doesn't help you catch the bugs on the gateway side or cases where they don't follow the specifications but at least you can make sure that your code is functioning properly according to the specs. After that you can tell them to run some final tests and maybe use your credit card in production once or twice for sanity checks.

[Kent Multer]

Thanks, everyone, for the advice. For now, I decided to keep it low-key. I told them, in effect, "OK, the module's passed all the tests you've given me so far; so I guess it's time for that next payment." They're OK with that. I'm going to send them a copy of the .mvc, and also give them the URL of my test store, so they can do some testing with their own cards. We'll see how it goes. Maybe all the untested features will work right the first time, and no additional debugging will be needed ... yeah, sure, that'll happen :^) ...