Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-27717

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

    Details

    • Type: Bug
    • Status: Closed
    • Priority: 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:

      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".

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              salvetore 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
              salvetore 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 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 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
              salvetore 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
              salvetore 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 malcolm added a comment -

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

              Show
              malcolm malcolm added a comment - thank you. let me know if you need any support with UAT.
              Hide
              nebgor 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
              nebgor 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 malcolm added a comment -

              this approach seems reasonable.

              Show
              malcolm malcolm added a comment - this approach seems reasonable.
              Hide
              nebgor 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
              nebgor 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
              skodak Petr Skoda 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
              skodak Petr Skoda 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
              rajeshtaneja 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
              rajeshtaneja 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
              nebgor 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
              nebgor 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
              skodak Petr Skoda added a comment -

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

              Show
              skodak Petr Skoda 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:
                    Fix Release Date:
                    1/Aug/11