topic Re: Overcharge (sliding decimal point) / Setting a maximum amount in Integration and Testing

Overcharge (sliding decimal point) / Setting a maximum amount

GolfnetJim — Wed, 05 Feb 2014 14:32:09 GMT

I am posting on behalf of the developer so apologies beforehand and thanks for assistance.

We had one transacation where the decimal point "slid" - for example a charge of $15.25 was processed as $1525.00. The value is static and pulled from a data table; the user cannot manipulate the price. The records on our side show the proper value was sent. We have only happened a single instance of this over ~100 transacations. Has anyone encountered this before? What could my developer have overlooked?

Related to that, is there a setting anywhere, whether on the account side or in the integration where we could "cap" the allowed charge amount as a stopgap to prevent this in the future?

Thanks again,

Re: Overcharge (sliding decimal point) / Setting a maximum amount

RaynorC1emen7 — Wed, 05 Feb 2014 16:01:11 GMT

The only amount stopgap is from their "Fraud Detection Suite", I think there is a monthly fee. where you can set a transaction upper and/or lower limit.

The records on our side show the proper value was sent.

What kind of records? the post string? the response? could they change the qty?

Re: Overcharge (sliding decimal point) / Setting a maximum amount

GolfnetJim — Wed, 05 Feb 2014 18:31:03 GMT

Thank you for the info on the Fraud Detection Suite.

The user selects the item to purchase, there isn't a field to change the qty.

We don't store the post string, we store the relevant values that were sent via the post string (ie, they select Item A at Cost X from the list of items, we'll store a record of the purchase, including the price, in a "purchases" table). The value we stored in this "purchases" was correct. I know that doesn't help us out too much, but my developer assures me that this value is the same as what is posted in the transacation.

Re: Overcharge (sliding decimal point) / Setting a maximum amount

RaynorC1emen7 — Wed, 05 Feb 2014 18:55:51 GMT

The other thing was to have authorize.net look at the transaction with the transactionID that you received from that. But I doubt they would see anything different.