An invalid currency type is used as payment or requested as change

Currency type is a enum. This literally shouldn't be happening. If the calling code is intentionally producing invalid enums, that's an abuse of the type system and user code should be be expected to handle that. (Especially since this cannot happen in some other strongly typed languages.)

The kata just assumes that everyone knows what value every note/coin is. What are the values of Quarter, Dime, Nickel and Penny? They need to be clarified.

You should clarify that price and payment are in the same currency (I assumed price was always in US$)
I had lots of troubles to get the right approximation. In the end I got the tests to pass by truncating instead of rounding cents. It doesn't sound reasonable to me. Maybe there is some other error in my code and this strange approximation compensates for it...don't know

JS:

DecodePangramTest
  Decoding ' TBM VLDLN mTGLK TUM HEHCI HKAW LBM QMAY CSV. '
✔  Test Passed: Value ==  THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG. 

I think that the testcase of decode function should not contains the lowercase characters, such as m in this testcase. Because the result of the encode function all are the uppercase characters. If the lowercase letters appears, this string should be an invalid string and should not be decoded correctly.

Needs random test cases (or an alternative would be to execute the tests in random order since the range of acceptable inputs is limited anyway)

Why artificuially limit it to 10?

When multiplying and dividing Javascript starts approximating at n>=24, but with additions (or smarter multiply/divide) you should be able to go way, way up. Why not? :]