A DESCRIPTION OF RECENT PROBLEMS ASSOCIATED WITH PayPal AND WHAT WE'RE DOING ABOUT THEM

Some of you have recently experienced delays in receiving the RBR and A3P reports you have ordered online on our website. Normally, reports are emailed to customers within 2 minutes of receipt. The way we accomplish this is to have a computer program running around the clock that checks a dedicated email folder every 60 seconds for new incoming orders. Upon recognition of such an email, the program quickly determines the customer's email address, the report(s) ordered and validates the transaction-ID provided by PayPal in the emails.

Recent technical problems experienced on PayPal's end have caused these emails to go out without identifying the items ordered. They basically just said "you received $5.00 from customer X with transaction-ID of 0ZS11832Q5186544T". No mention that customer X wanted the RBR for Wednesday's Aqueduct card. In the 6 years we've been dealing with PayPal, problems like this have been rare and overall we are very satisfied with the service they provide.

When this occured during normal business hours, we noticed it immediately and manually emailed the RBR to the customer. But in the late night and early morning hours when our system was running unattended, it was unable to fill the orders that were missing the name of the item ordered.

We immediately contacted PayPal and brought the issue to their attention. While waiting for them to come up with a solution, we started working on our own solution. In short, we created a"backup" procedure that would be able to fill orders without having to rely upon the notification emails that are normally sent to us by PayPal seconds after verifying a transaction. For those of you with PayPal accounts, you are familiar with the various features you can use. You basically go to their website, enter your user name and password, and you're in and able to view your recent transactions and perform tasks like depositing or withdrawing funds or creating reports.

As users of our software know, recent versions of our programs interface with the internet in many ways. 9.0 allows users with access to quickly download our A3P Past Performance Files. A+ Basic also has this feature for the "compact version" of A3P files. We control access with a "key record" that identifies users and the date their access runs through. For our purpose, this is a very simple chore as no fancy security is imposed. But users do need our software in order to use our files. In a more secure environment like PayPal where sensitive data is stored, they need to prevent people from accessing user information. They do this with passwords.

So basically, our task was to write a procedure that simulated every keystroke necessary to get to the PayPal web page that contained all recent transactions. This was a little tricky, but yesterday we ran our first successful test and simulated orders were processed with our backup system. Here's how our system works. At various prescribed times, the program starts automatically, opens a web browser window, "types" in the URL for PayPal's website and "presses" Enter. It then "types" in our user name and password and "presses" Enter. Those actions take us to a summary page containing recent transactions. But none of the information on that page identifies the 3 pieces of data necessary to fill orders. What is important on that page is the date of each transaction and a link that takes us to another page identifying the details of that particular transaction. By examining the date, we can easily determine which transactions are recent. Those are the only ones we are concerned with. After converting the HTML of the summary page to plain text, our program is able to determine the URL of each pertinent transaction. At that point, the program opens a URL sub-window by "pressing" Ctrl-O and "types" in the first URL. At that point, the window containing the details of the transaction opens. After converting to plain text, our program can easily pick out the buyer's email address, the transaction-ID and the report(s) ordered. At this point, we have everything we need to fill an order.

Going forward, we plan on running both systems simultaneously and need to determine the intervals at which the backup system needs to check. Our usual program checks every 60 seconds and runs 24x7. Initially, the backup system will check 3 or 4 times each hour during times when the normal system runs in unattended mode. What this means to you is that until PayPal fixes the bug, you will receive your "after hours" orders within 15 or 20 minutes instead of the normal 1 to 2 minutes. During "normal" business hours when our system is running in attended mode, your orders will be processed immediately either through our primary system or manually if PayPal issues persist.

Since we store records of each transaction, both systems will "know" which orders have already been filled so duplication of orders should not occur. So when PayPal implements a fix to their problem, orders should be filled in the "normal" manner. Until then, the backup program will be capable of filling orders using the procedure described above.

We learned long ago that pointing fingers and placing blame never solves problems. We also learned that fixing problems associated with external entities by coding "workarounds" is the best (and fastest) way to provide service to our valued customers. We've done it in the past when third party vendors changed Past Performance Files without notice, when website procedures changed without notice and when access to files was simply withdrawn from the public.

We've been in this business since 1991 and our customers know that when problems arise, we take ownership of them regardless of who is at fault. And when reports are emailed late, we refund the purchase price in full immediately. Customer satisfaction is JOB ONE with us.