Overcharge (sliding decimal point) / Setting a maximum amount

[GolfnetJim]

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,

J

[RaynorC1emen7]

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?

[GolfnetJim]

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.

[RaynorC1emen7]

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.