Moodle
  1. Moodle
  2. MDL-27717

Language Packs causing incorrect amounts to be sent to Authorize.net

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.9.11
    • Fix Version/s: 1.9.13
    • Component/s: Enrolments, Language
    • Labels:
    • Environment:
      MoodleRooms hosting environment.
    • Database:
      MySQL
    • Testing Instructions:
      Hide

      1) install language packs for Spanish - International, and Spanish - Mexico
      2) Force a course to use language pack for Spanish - Mexico
      3) Require the course to have a registration fee of greater than $0.0; for example $1.00
      4) configure enrollments to utilize (by default) the Authorize.net Payment Gateway
      5) attempt to register for the course; price is displayed as $1,00
      6) when purchasing the course, authorize.net should submit a request to the Merchant Account for $1 (not $100, as is currently occuring).

      Show
      1) install language packs for Spanish - International, and Spanish - Mexico 2) Force a course to use language pack for Spanish - Mexico 3) Require the course to have a registration fee of greater than $0.0; for example $1.00 4) configure enrollments to utilize (by default) the Authorize.net Payment Gateway 5) attempt to register for the course; price is displayed as $1,00 6) when purchasing the course, authorize.net should submit a request to the Merchant Account for $1 (not $100, as is currently occuring).
    • Workaround:
      Hide

      disabled the language packs as a short term solution.

      Show
      disabled the language packs as a short term solution.
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Pull from Repository:
    • Rank:
      17369

      Description

      There are two examples of this bug:
      1) a posting to the forum: by Rob Rashotte - Tuesday, January 27, 2009, 12:47 AM
      I (Rob Rashotte) have several language packs installed on my moodle site and it appears that if someone selects a language that uses a comma for a decimal place holder that the amount of the transaction is misinterpreted by authorize.net.

      For example I have a course that costs $500 US.

      If someone is using the default language settings then $500.00 is displaced as the price of the course and is interpreted by auth.net as $500.00

      If Someone has the DE language pack selected (for example), the price is displaced as $500,00 but authorize.net is interpreting this as $500,00.00 or $50 Thousand dollars.

      2) and my installation of Moodle (via MoodleRooms), have experienced the same issue.

      We added a second course to our MoodleRooms site on Friday May 27, 2011. The new course is a 100% duplicate of the first course, except the course content has been translated into Spanish.

      So, as part of the configuration of the new course, we configured the Spanish course content to "Force" the users to use Spanish language pack. After configuring this everything seemed to work fine, EXCEPT, the price of the course changes from $99.00 to $9,900.00; so when students try to register for the class, their credit cards are being declined because of this higher price.

      The attached screen shot shows something we noticed when the Spanish Language pack is forced; the price of the course is DISPLAYED with a comma instead of a period after the "99".

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this.

          I've put it on our backlog and elevated it.

          In the meantime, if you have a change to work on a code solution, that will help us and other users.

          Show
          Michael de Raadt added a comment - Thanks for reporting this. I've put it on our backlog and elevated it. In the meantime, if you have a change to work on a code solution, that will help us and other users.
          Hide
          malcolm added a comment -

          I have also contacted our Authorize.net support team. Here is their response:

          Hello Malcolm,
          We received your inquiry about the wrong amount on the transaction.

          We just submit the transaction to the processor that you pass on to us. We show that your system submitted it to us for the $9,900. You are going to need to contact your developer to see why it is being submitted that way. There is nothing on the account that would cause that. All the formatting of the transaction is done on your end. ...

          Sincerely,

          Robert B
          Authorize.Net
          Customer Support

          Show
          malcolm added a comment - I have also contacted our Authorize.net support team. Here is their response: Hello Malcolm, We received your inquiry about the wrong amount on the transaction. We just submit the transaction to the processor that you pass on to us. We show that your system submitted it to us for the $9,900. You are going to need to contact your developer to see why it is being submitted that way. There is nothing on the account that would cause that. All the formatting of the transaction is done on your end. ... Sincerely, Robert B Authorize.Net Customer Support
          Hide
          Michael de Raadt added a comment -

          Just a note to say that we are planning to give this some attention after Moodle 2.1 is released.

          Michael;

          Show
          Michael de Raadt added a comment - Just a note to say that we are planning to give this some attention after Moodle 2.1 is released. Michael;
          Hide
          malcolm added a comment -

          thank you. let me know if you need any support with UAT.

          Show
          malcolm added a comment - thank you. let me know if you need any support with UAT.
          Hide
          Aparup Banerjee added a comment -

          ok, i haven't completed looking deeper into this but just thinking out loud:

          essentially we have to make an exception to the currency string being manipulated. This could be based on:

          1) who the payment processor is and what languages they recognize.
          or
          2) incorrect language string substitution going on.

          Show
          Aparup Banerjee added a comment - ok, i haven't completed looking deeper into this but just thinking out loud: essentially we have to make an exception to the currency string being manipulated. This could be based on: 1) who the payment processor is and what languages they recognize. or 2) incorrect language string substitution going on.
          Hide
          malcolm added a comment -

          this approach seems reasonable.

          Show
          malcolm added a comment - this approach seems reasonable.
          Hide
          Aparup Banerjee added a comment -

          This patch should fix the issue.

          Essentially the localized format should never have been used for charging (calculations) purposes as described in the get_course_costs() -> format_float() function.

          (this is a 1.9 fix only, no authorize.net in later versions hence no 2+ branches)

          Show
          Aparup Banerjee added a comment - This patch should fix the issue. Essentially the localized format should never have been used for charging (calculations) purposes as described in the get_course_costs() -> format_float() function. (this is a 1.9 fix only, no authorize.net in later versions hence no 2+ branches)
          Hide
          Petr Škoda added a comment -

          I did not test this, but the patch makes sense. I did not study the authorize.net api either.

          Integrated, thanks.

          Show
          Petr Škoda added a comment - I did not test this, but the patch makes sense. I did not study the authorize.net api either. Integrated, thanks.
          Hide
          Rajesh Taneja added a comment - - edited

          Works as expected
          Thanks for providing the patch Aparup.

          Don't you think this should go in other branches, as this is broken functionality in 2.0 and 2.1 as well.

          Show
          Rajesh Taneja added a comment - - edited Works as expected Thanks for providing the patch Aparup. Don't you think this should go in other branches, as this is broken functionality in 2.0 and 2.1 as well.
          Hide
          Aparup Banerjee added a comment - - edited

          We need to find out if authorize.net is supported in 2.x onwards. (I was under the impression that it isn't) - Petr any comments? (heard from Martin that you had strong opinions about this.)

          Rajesh has pointed out, its still there under enrol/authorize for some reason. -> MDL-28466

          Show
          Aparup Banerjee added a comment - - edited We need to find out if authorize.net is supported in 2.x onwards. (I was under the impression that it isn't) - Petr any comments? (heard from Martin that you had strong opinions about this.) Rajesh has pointed out, its still there under enrol/authorize for some reason. -> MDL-28466
          Hide
          Petr Škoda added a comment -

          Thanks everybody, this is now part of the weekly build.

          Show
          Petr Škoda added a comment - Thanks everybody, this is now part of the weekly build.

            People

            • Votes:
              4 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: