Authorize - error in capturing if entering comma

[apollowilcox]

Is there a way to modify Authorize AIM payment module so that an amount entered with a thousands comma will be captured correctly?

Our website routinely gets orders of $1000.00 and we only authorize at time of order, then capture when the order ships. Our process calls us to copy/ paste the dollar amount into the "Amount to Capture" field, which reduces risk of typo.

The problem is that if we enter 1,234.56 instead of 1234.56, Authorize will only capture $1. It cuts off at the comma. This seems counter-intuitive that an obviously numeric field would not be able to understand a comma but i assume there's a good programming reason.

So then we lose the authorization and have to bother the customer and beg for c.c. information again.

Is there a way to modify the Authorize AIM module so that it can capture the correct amount even with the comma?

Thank you.

[mc12345678]

Two ways I can think of. One is to work with authorize.net in making the comma acceptable on their end. The other is to modify the file where ['total'] is used it seems to remove a comma from the value entered. The concern of this in the specific case of only addressing comma as the character of concern is in other currencies where the comma serves as the place holder to identify smaller parts of the currency and the period as the thousands indicator... but... that also depends on the support of the payment module. E.g. If it can't be used to accept currency say from Germany where 1.234,24 is written for what is used in the US as 1,234.24, then the debate is over. :)

Using a function like str_replace(',', '', $amount) would remove the comma from the content wherever it may be...

[apollowilcox]

Two ways I can think of. One is to work with authorize.net in making the comma acceptable on their end.

Thank you for the reply. It does not appear that this is an authorize.net issue. We use authorize.net website directly for our commercial customers paying by credit card and the comma is no issue there.

The other is to modify the file... Using a function like str_replace(',', '', $amount) would remove the comma from the content wherever it may be...

I like this idea. May try to track this down. Anyone have any idea which file this might involve? Is it one of the authorize_aim files, or perhaps the admin/ orders.page or perhaps some module?

Thanks,

Matt

[mc12345678]

With a little more digging it appears that the issue is in line 853 of: https://github.com/zencart/zencart/b...izenet_aim.php

The amount entered in the notifier file (which is not sanitized by javascript during entry) is processed to be a float. As a result, everything up to the first character is captured where in this case the first non-numeric character is the comma.
So, could add some sanitization in a line before this to account for the removal of the comma or whatever other character(s) are to be removed (ie. Currency symbol or something else applicable.)

[mc12345678]

Further it looks like the line could be rewritten like:

$captureAmt = (float)preg_replace("/[^0-9.]/", "", $_POST['captamt']);

That way, only the numbers entered would be involved, though if there was say a line of text entered with multiple numbers throughout, then they would basically get combined...

I'm still somewhat wondering if the above string should incorporate the decimal placeholder for the filtering instead of blindly applying the filter to keep only the decimal and not the comma if there is some system condition that would treat the float of the number differently in different currencies/system configurations...

I typically work in a comma separated thousands and decimal for parts of a whole system, so for me it requires a little more research to determine how other systems operate if different...

[apollowilcox]

Further it looks like the line could be rewritten like:

$captureAmt = (float)preg_replace("/[^0-9.]/", "", $_POST['captamt']);

Thank you mc12345678. I tried that and ran a trial using my own credit card and it successfully ran the correct amount that i entered with a comment. I'll keep this under close scrutiny for other issues, but it seems solid. Thank you!

Matt

[mc12345678]

Thank you mc12345678. I tried that and ran a trial using my own credit card and it successfully ran the correct amount that i entered with a comment. I'll keep this under close scrutiny for other issues, but it seems solid. Thank you!

Matt

Good to know. So did some reading of the php manual and postings of other's issue(s). The casting to float regardless of locale appears to expect a period to represent the decimal place holder, so while I'm not off the cuff sure what currencies are accepted in this module, this solution may cause a problem. If a currency uses a comma for the decimal place and a period for the thousands and that currency is displayed for copying, then when processed after pasting, the same problem as described before occurs though holding multiple values in the decimal place holder.

The above discussion may not apply to you, but is here for those that may consider using this solution to solve their own problem(s).