In general the Moneris integration is all right. The testing with transactions under $11 with different cent amounts is actually an extremely difficult way to test a production e-commerce system that charges taxes for multiple items, normally over $1000. It means lots of custom code to fudge numbers just to test. This is why normally different card numbers are used to simulate error scenarios.
Basically by implementing this way of testing, developers need to make a module/functions that is/are completely different than production in order to test - which is the polar opposite of what you want to be doing. In order to simulate certain scenarios, our developers then need to create their own set of cards, which are then internally translated to a sub $11 value with a specific cent amount. When changing back to production, this code is not used at all, and production code (technically not tested) is then utilized.
Using cents to simulate error scenarios is fine I suppose for something super simple that takes manually entered amounts, but not complex e-commerce solutions where the charged amount is based on complex totals.
If you check the penny value simulator table you'll see that there are some always approve/always decline cards that can be used to simulate approved/declined scenarios. There are also some value ranges that approve/decline.
There are also cards in the e-fraud penny value table that will approve/decline (Visa/MC/Amex). They are mostly used to test card verification (non financial transaction) but will work the same with an amount for financial transactions.
In reply to MB_Moneris:
In reply to WyrkFlow: