Perhaps They Should Have Tested More - Moneris Solutions Corp.

Annually, the holiday season brings us shopping, visits from far-flung relatives, overeating, and reports of software failure.


I laughed when I read the response of the Senior VP of Marketing - "we would like to reassure them that we have identified the problem as a software problem". That's supposed to be reassuring?

Fortunately their system is "now up and running in a highly reliable fashion" - presumably as opposed to the largely unreliable fashion prior to this timely failure.

Debit and credit blackout

Times Colonist; CanWest News Service; Canadian Press

Saturday, November 25, 2006

Many shoppers on the Island and across the country couldn't pay for their purchases yesterday afternoon after a debit and credit card system failed.

A software glitch at payment processor Moneris Solutions Corp. was blamed.

Card holders were left scrambling to find ways to pay for their purchases.

"Some people were definitely inconvenienced," said Alex Mutrie, a clerk at the Petro Canada station on Douglas Street.

"They pumped their gas, tried to use their debit and had no way to pay," said Mutrie. "We took their ID, something they'll come back for. A couple of people were really angry."

The outage began around 1 p.m. Pacific time and lasted until about 3:45 p.m., said Royal Bank spokeswoman Beja Rodeck.

Moneris is jointly owned by the Royal Bank and Bank of Montreal, but the problems appeared to affect whatever credit or debit card was used in a Moneris point-of-sale terminal.

"This is a highly unusual incident. Our system has been running without incident for years," said Brian Green, Moneris senior vice-president of marketing.

"It kind of screws up your whole day," said Brianna Cameron, who was walking around Mayfair Shopping Centre with a friend.

"The stores told us we couldn't use our debit. So we went to get a drink at the food court and their debit wasn't working either," said Thais Robson, a Grade 9 student at Reynolds Secondary School.
--------------------------------------------------------------------------------

Christmas shopping glitch was in the cards

Tough time for Royal Bank

TORONTO -- A software glitch at Moneris Solutions Corp. prevented some merchants across the country from completing credit and debit transactions for about 2 1/2 hours yesterday until the problem was fixed.

Brian Green, senior vice-president of marketing for Moneris, said the system went down about 4 p.m. Eastern time and was fixed by about 6:30 p.m. ET.

The problem was traced to a software application.

"We were able to isolate that software and essentially pull it out and thereby restore service fully," Green said. "This is a highly unusual incident. Our system has been running without incident for years."

Moneris is Canada's largest processor of debit and credit card transactions. It processes more than 2.3 billion payment transactions a year. Green said the problems cropped up across the country.

Moneris is jointly owned by Royal Bank of Canada (TSX:RY) and Bank of Montreal (TSX:BMO) but the problems yesterday affected whatever credit card or bank card was used in a Moneris point-of-sale terminal.

"We deeply regret the inconvenience and frustration that we caused our customers and their customers," Green said.

"However, we would like to reassure them that we have identified the problem as a software problem, certainly not a capacity or volume problem, and our system is now up and running in a highly reliable fashion."

--------------------------------------------------------------------------------
Moneris Restores Service After ‘Glitch’ Cuts off POS Traffic in Canada

(November 27, 2006) While American consumers were flocking to the stores on Friday and whipping out their credit and debit cards for payment, their Canadian counterparts were forced to find cash, their checkbooks, or to come back later because the network of the nation’s largest merchant acquirer went down for two and a half hours.

Moneris Solutions Corp. reports that a software problem in its main processing switch that began about 4 p.m. Eastern time left its merchants unable to process any credit or debit card transactions until about 6:30 p.m. A spokesperson for Toronto-based Moneris, which has 300,000 merchant locations, did not have details Monday morning about the technical nature of the problem. The problem, however, did not arise from heavy volume or insufficient capacity, Moneris reports. Nor does there appear to be evidence of outside tampering. “All indications point to an internal glitch,” the spokesperson says.

In a news release late Friday, Moneris said that when it became aware of the problem it immediately started a diagnostic and restoration process and concurrently set in motion a process to move to its back-up system. The restoration process was successful and the back-up system conversion was not implemented. During the outage, calls flooded into Moneris’s customer-service center, creating a backlog that caused some merchants to receive a busy signal.

Besides Visa and MasterCard credit card sales, the glitch affected Interac PIN-based point-of-sale transactions and American Express Co. transactions in Canada, the spokesperson says. The problem did not affect Moneris’s U.S. affiliate, Moneris Solutions Inc., which is based in suburban Chicago.

The spokesperson says that until Friday’s incident, Moneris’s system had operated virtually flawlessly for years. Network uptime exceeds 99.9%, according to the release. “It was a minor headache, and certainly frustrating for the merchants and customers,” he says.

Moneris is a joint venture of RBC Financial Group and BMO Financial Group, parent companies of the Royal Bank of Canada and Bank of Montreal, respectively. It processes more than 2.3 billion transactions annually.
--------------------------------------------------------------------------------

Interac glitch slows holiday sales
Peter Rusland

By Peter Rusland

News Leader
Nov 29 2006

Local fallout from Friday’s nationwide computer software glitch is still being tallied by hundreds of Cowichan shoppers whose debit and credit cards were refused for use in shops throughout the Valley.

“It was hit and miss; some cards worked and others didn’t. It was a hodgepodge mess and it’s happening again today,” said Bruce’s Grocery manager Loren Halloran.

Staffer Jason Battie noted customers were able to get cash from the store’s ATM machine while regular shoppers charged groceries to their Bruces’ account.

“They seemed to be taking it fine considering the situation.”

Duncan Safeway’s first assistant manager Darren Bognar said his store’s customers were also understanding during Friday’s 1 to 3:30 p.m. downage that affected businesses using payment processors from Toronto-based Moneris Solutions Corp.

“The customers were really good about the inconvenience,” said Bognar who wasn’t on duty Friday.

“I’m sure it was cash only and some people got really good deals for waiting,” he said. “We tried to take care of our customers.

“We haven’t had any problems with our system for that long a period before outside of individual machines that had nothing to do with Moneris.”

Moneris spokesman Matthew Cramm says the Canada-wide blackout believed caused by wonky software is still being probed by the firm owned by the Royal Bank and the Bank of Montreal.

“It caused the network to go down so they took that software off line and restarted the network,” he told the News Leader.

“As far as I know the new network has worked. It was as if your Internet crashed.”

Cramm calls the problem “extremely rare.”

“Moneris’ network has been running incident-free for years. It was software and had nothing to do with (purchasing) volume.

“Their network is designed to handle even more capacity and was built to grow over time. It was just one of those things but it was frustrating for merchants and customers.”

Most bank machines were unaffected.

Canada’s half-dozen other payment processors for bank debit cards, plus Visa, MasterCard and American Express charge cards were unaffected, he notes.

Customers should contact their local bank to discuss problems or call Moneris’ merchant line at 1-866-319-7450.

HTTP Response Codes

1xx Codes	Informational
100 - Continue	An interim response telling the browser the initial part of its request has been received and not rejected by the server. A final response code should be sent when the remainder of the material has been sent.
101 - Switching Protocols	The browser may wish to change protocols it's using. If such a request is sent and approved by the server this response is given.
2xx Codes	Success
200 - OK	The request was successful and information was returned. This is, by far, the most common code returned on the web.
201 - Created	If a POST command is issued by a browser (usually in processing a form) then the 201 code is returned if the resource requested to be created was actually created. If there is a delay in creating the resource the response should be 202, but may be 201 and contain a description of when it will be created.
202 - Accepted	If a request for processing was sent and accepted but not acted upon and the delay in acting is unknown, then this code should be sent instead of 201. Note that 202 does not commit to processing the request; it only says the request was accepted. A pointer to some status monitor for the task is often included with this response so users can check back later.
203 - Non-Authoritative Information	Usually the preliminary information sent from a server to a browser comes directly from the server. If it does not, then this code might also be sent to indicate that information did not come from a known source.
204 - No New Content	The request was accepted and filled but no new information is being sent back. The browser receiving this response should not change its screen display (although new, and changed, private header information may be sent).
205 - Reset Content	When you fill in a form and send the data, the server may send this code telling the browser that the data was received and the action carried out so the browser should now clear the form (or reset the display in some manner).
206 - Partial Content	This code indicates the server has only filled part of a specific type of request.
3xx	Redirection
300 - Multiple Choice	You should not see 300 standing alone; it serves as a template for the following specific codes.
301 - Moved Permanently	As the name implies, the addressed resource has moved and all future requests for that resource should be made to a new URL. Sometimes there is an automatic transfer to the new location.
302 - Moved Temporarily	The addresses resource has moved, but future requests should continue to come to the original URL. Sometimes there is an automatic transfer to the new location.
303 - See Other	The response to your browser's request can be found elsewhere. Automatic redirection may take place to the new location.
304 - Not Modified	In order to save bandwidth your browser may make a conditional request for resources. The conditional request contains an "If-Modified-Since" field and if the resource has not changed since that date the server will simply return the 304 code and the browser will use its cached copy of the resource.
305 - Use Proxy	This is notice that a specific proxy server must be used to access the resource. The URL of the proxy should be provided.
4xx	Error - Client Side
400 - Bad Request	The server did not understand the request. This is usually cured by resending the request.
401 - Unauthorized	The request requires some form of authentication (e.g., userid and/or password) but did not contain it. Usually, this code results in a box popping up in your browser asking you for the required information. Once you supply it the request is sent again.
402 - Payment Required	Reserved for future use. [Who says the web is not moving toward being a commercial medium!]
403 - Forbidden	This is a sort of catch-all refusal. If the server understood the request but, for whatever reason, refuses to fill it, a code 403 will often be returned. The server may or may not explain why it is sending a 403 response and there is not much you can do about it.
404 - Not Found	If you happen to mistype a URL or enter an old one that no longer exists this is the error you will likely see. The condition may be temporary or permanent but this information is rarely provided. Sometimes code 403 is sent in place of 404.
405 - Method Not Allowed	Your browser has requested a resource using a procedure not allowed to obtain that resource. The response should contain allowed procedures.
406 - Not Acceptable	Your browser said only certain response types will be accepted and the server says the content requested does not fit those response types. (This is one way content monitoring can be implemented.)
407 - Proxy Authentication Required	This code is similar to 401, except that the browser must first authenticate itself.
408 - Request Timeout	Your browser waited too long and the server timed out. A new request must be sent.
409 - Conflict	If a site allows users to change resources and two users attempt to change the same resource there is a conflict. In this, and other such situations, the server may return the 409 code and should also return information necessary to help the user (or browser) resolve the conflict.
410 - Gone	Code 410 is more specific than 404 when a resource can't be found. If the server knows, for a fact, that the resource is no longer available and no forwarding address is known, then 410 should be returned. If the server does not have specific information about the resource, then 404 is returned.
411 - Length Required	For some processes a server needs to know exactly how long the content is. If the browser does not supply the proper length code 411 may result.
412 - Precondition Failed	A browser can put conditions on a request. If the server evaluates those conditions and comes up with a false answer, the 412 code may be returned.
413 - Request Entity Too Large	If your browser makes a request that is longer than the server can process code 413 may be returned. Additionally, the server may even close the connection to prevent the request from being resubmitted (this does not mean a phone connection will hang up; just that the browser's link to the site may be terminated and have to be started over again).
414 - Request-URI Too Long	You will likely not see this one as it is rare. But, if the resource address you've sent to the browser is too long this code will result. One of the reasons this code exists is to give the server a response when the server is under attack by someone trying to exploit fixed-length buffers by causing them to overflow.
415 - Unsupported Media Type	If your browser makes a request using the wrong format, this code may result.
5xx	Error - Server Side
500 - Internal Server Error	An unexpected condition prevented the server from filling the request.
501 - Not Implemented	The server is not designed (or does not have the software) to fill the request.
502 - Bad Gateway	When a server acts as a go-between it may receive an invalid request. This code is returned when that happens.
503 - Service Unavailable	This code is returned when the server cannot respond due to temporary overloading or maintenance. Some users, for example, have limited accounts which can only handle so many requests per day or bytes send per period of time. When the limits are exceeded a 503 code may be returned
504 - Gateway Timeout	A gateway or proxy server timed out without responding.
505 - HTTP Version Not Supported	The browser has requested a specific transfer protocol version that is not supported by the server. The server should return what protocols are supported.

Perhaps They Should Have Tested More - Excelsior Software

Teachers' Input of Grades Crashes System

By Daniel de Vise
Washington Post Staff Writer
Saturday, November 4, 2006; B03


There are probably some Montgomery County students who would prefer that their first-quarter grades never saw the light of day. For a few hours this week, it almost appeared that their prayers would be answered.

A new computerized grading system in 52 middle and high schools seized up Wednesday, overwhelmed as thousands of teachers simultaneously typed in final grades for the marking period. It was the first real test of a new electronic grade book that frees teachers from the tedium of marking grades in ovals with No. 2 pencils and feeding them into Scantron machines.

Officials eventually shut down the system and fixed a glitch that had caused the networking equivalent of a rush-hour pileup on the Beltway.

At a union meeting Wednesday night, frustrated teachers logged what might be the first-ever no-confidence vote in an educational software program.

"They had spent hours in front of their computers, trying to enter their data, and it wouldn't go through," said Tom Israel, executive director of the Montgomery County Education Association, which represents teachers.

The Pinnacle electronic grade book, piloted in four schools last year, is scheduled for countywide use in secondary schools next year. A timesaver for teachers, it also offers parents a chance to monitor their children's progress from week to week on the Edline Internet site.

School system officials said the brief system failure would not delay Thursday's scheduled release of old-fashioned, hard-copy report cards to students.