topic Re: Too many void transaction in our production environment in Integration and Testing

Too many void transaction in our production environment

EddieLascu88CNP — Thu, 16 Jun 2016 19:02:51 GMT

We have started our system in Production recently. We request payments from two web portals. Users of the web portals are creating payment profiles directly in Authorize.Net as we used CIM with Hosted Forms in our implementation. We have noticed in the Batch information coming back daily from Authorize.Net that there are a lot of voided transactions. Obviously, we do not have access to the Merchant Account web portal, so we can't see more details related to these voids. The developers of the Web Portal claim that there is nothing in their logs to suggest that approved transactions are being voided. Is Authorize.Net creating some charges that then are voided when a customer creates a new payment profile? That would explain the high number of voids that we can't account for. If not, is there another scenario in which these voids are created? We don't want to involve the client and ask for additional information that may be available on the Merchant's web portal until we do our due diligence and rule out any issues that may be caused by our implementation.

TIA,

Eddie

Re: Too many void transaction in our production environment

RaynorC1emen7 — Thu, 16 Jun 2016 19:47:27 GMT

If the void amount is 0 or 0.01, this should explain it

https://community.developer.authorize.net/t5/Integration-and-Testing/Help-Understanding-Test-vs-Live-Mode/m-p/54940/highlight/true#M29892

Re: Too many void transaction in our production environment

EddieLascu88CNP — Thu, 16 Jun 2016 20:51:09 GMT

Hi there,

I don't think that is the reason because we create all Customer Profiles using "ValidationModeEnum.none". I cannot tell the amount of the voids because I cannot connect to the Merchant Account and see the original transactions. The Batch information shows zero for the amounts, but I think that's normal since this is a void. Should the batch information contain a different amount for a void, if the amount of the original transaction was different than zero? Is there another explanation?

Also, if we are to use "ValidationModeEnum.liveMode", will it force the users of the web portal to enter an address? Our client does not want us to force the users of the web portal to enter an address as they don't use the address and want to make the customer and payment profile creation process as fast as possible. Sorry, this is a different question that perhaps should be placed in its own thread.

Thanks,

Eddie

Re: Too many void transaction in our production environment

EddieLascu88CNP — Thu, 16 Jun 2016 21:04:04 GMT

In addition, we have more payment profiles created than the number of voids, so it's not a one-to-one relationship, even though all payment profiles are created through your Hosted Page, redirected from the web portal.

Re: Too many void transaction in our production environment

RaynorC1emen7 — Thu, 16 Jun 2016 21:25:02 GMT

They will need to look at the original transactionID to see the detail.

If I remember correctly, those from the create profile ValidationModeEnum livemode do have the description said it from creating payment profile. The mechant need to go check to see what any detail said from the original transaction.

Re: Too many void transaction in our production environment

EddieLascu88CNP — Fri, 17 Jun 2016 18:41:44 GMT

The documentation says that liveMode is the default setting for the Validation Mode. Is it conceivable that our client has set the Validation Mode parameter to liveMode and that overwrites what we send in our calls, when we create the customer profiles?

Re: Too many void transaction in our production environment

RaynorC1emen7 — Fri, 17 Jun 2016 19:05:48 GMT

anything is possible, but getting the detail would tell you 100% what happened

Re: Too many void transaction in our production environment

EddieLascu88CNP — Fri, 17 Jun 2016 22:49:56 GMT

That means we need to involve our client and I was hoping we can rule out our fault before we reach out to them.