cancel
Showing results for 
Search instead for 
Did you mean: 

Overcharge (sliding decimal point) / Setting a maximum amount

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

GolfnetJim
Member
3 REPLIES 3

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?

RaynorC1emen7
Expert

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.

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.