Over the past few months we’ve seen several common issues crop up as our partners are going through integration and certification testing with IBX. So let’s run through a couple of common issues that cause confusion.
Test Card Numbers
“Which test cards should we use?” is a common question. If you look at our online APIs you will find we use 4012888888881881 as our card number in the examples. This is a perfectly fine test card number to use (it’s a Visa) and you can use expiration dates set out into the future (Eg. 12/18). This will let you run transactions for various amounts without issue. Similarly you can also use 4242424242424242 (Visa) or 5454545454545454 (MasterCard) with 12/20 expiration dates and CVV codes of 999 and 998 respectively. In the end, if you aren’t sure how to run a transaction ask our integration team. When you came on board we should have provided you with a document of test card numbers, expiration dates and CVV codes to use.
“Well that’s all fine and good,” I hear you say, “But I run a transaction and then when I run another one with the same amount, I get a duplicate transaction error. What’s up with that?” It turns out that IBX has functionality (turned on by default) to allow the gateway to catch duplicate transactions and prevent them from being sent to the processor. This comes in handy in catching either manual entry errors where transactions are duplicated by mistake or by coding errors that cause transactions to be duplicated. We prevent a transaction with the same card, amount, etc… to be run until the current batch is closed or the transaction is run with the force flag being set either in the API or via the entry input checkbox in the virtual terminal. So, to avoid duplicate transactions either close out the batch frequently, set the force flag or use random amounts for your transactions.
While partners can choose to use a semi-integrated solution where swipes and EMV dips are sent to the gateway by a terminal, there are still scenarios where card data that is swiped needs to be accepted by software and sent via API to IBX. Our existing API handles this without issue. There is a MagData argument to the ProcessCreditCard call. Simply fill in this field with the full value returned by card swiper you are using. You can find an explanation of what that data looks like here and you can contact our integration team for samples that you can use if you are having problems.
Username, UserName, or username
When accessing the SOAP API from languages where the toolkit doesn’t autogenerate client methods you can run into the problem where the underlying calls expect parameter names from the WSDL that unfortunately don’t always follow the same convention. (I know… I know… we are in the process of punishing the offenders but alas these are the published API specs we now have to support.) Specifically some of the calls for processing cards use UserName in some calls, and Username in others. We’ve tried to make sure our documentation points out these differences and the WSDL is always the “ground truth” for what the names should be. All I can do is offer another mea culpa and ensure our RESTful APIs will be better (including how we version them).
If you’ve found other issues please let us know, we’re always looking for ways to improve our documentation, code and ultimately our customer interactions with you, our partners!
Till next time,