Certain 'invoiceNumber' values predictably triggering errors

[tan]

Hey. I'm having a most bizarre issue. I'm able to predictably trigger certain errors by setting specific invoiceNumber values. I don't know whether this issue only exists in the sandbox or if it happens in production as well.

I have tested numbers 1 through 20. So far I have found that sending '2' and '11' results in "This transaction has been declined." and sending '3' results in "An error occurred during processing. Call Merchant Service Provider.".

I haven't been able to find any documentation mentioning this, nor any mentions of it elsewhere on the internet. The Testing Guide says nothing about it.

Is this a bug or a feature? Does it happen in production? Is there any way to turn this off?

Thank you.

[mmcguire]

I haven't heard of invoice working that way. What api method are you using?

[tan]

I'm sending a createTransactionRequest to https://apitest.authorize.net/xml/v1/request.api.

Are you able to reproduce the issue?

[RichardH · Accepted solution]

Hello @tan

This is a known issue with our sandbox simulator.  We had an rogue internal developer add a new trigger value without considering the implications.

Richard

[mako]

Can you share any details on how to avoid getting this error until it is fixed in your Sandbox environment?  Or should we be developing against your production environment?

Unfortunately I am in the position where I am already trying to use a suggested work-around (sending my refId in either the order invoiceNumber or description field because it is not echoed back in the webhook), but the workaround itself is not working because at the payment page I get a "Unexpected error.  Please try again"

[Renaissance]

@mako your issue seems completely different. The unexpected error is driven by something else. Sounds like something related to getting a token or not having something set right in your api call. If you do a sample transaction without the invoice do you get a working payment page? For production environment that’s a definite no. You’ll be pulling your hair out because production environments do not store transaction data in test mode. So your webhooks will come back blank or will fail validation. It’s sandbox all the way.

[mako]

Yes, it happens whenever I set the order details on my getHostedPaymentPageRequest. 

I get a token back fine, but after landing on the hosted payment form and submitting the payment I get the error. 

If I remove the order details, the payment goes through fine.

[RichardH]

@mako

The simplest solution is to create a realistic invoice number when submitting your token request.  Try something with 3 or more digits.

Richard