Case Studies

  • Case Study 1
  • Case Study 2
  • Case Study 3
  • Case Study 4
  • Case Study 5
  • Case Study 6
  • Case Study 7
Chapter 11 Panic stations!

Scenario:

Bill Parson's transaction gateway service just filed for Chapter 11. As a result, Bill is panicking because he doesn't have a lot of time to integrate a new solution. Nor is he even sure which new solution he would go with, if he did have the time. Bill feels that by the time he researches this matter properly, his current provider might already have been dissolved and in the process put Bill out of business as well. Thus, Bill wants to start a new integration today, but he is still having a hard time deciding on what service would be the right one for him. What can oPAYc do for Bill?

Solution:

oPAYc integration is the same for ALL of the drivers. Bill can start integration with oPAYc right now, and not lose any time. At the same time Bill can do his research on which processor best suits his needs, and simply load the correct driver when the integration is complete. In addition to this, Bill can do both tasks in parallel and cut a lot of time out of the process. If this ever happens again, Bill will be in a far better position to switch processors without needing to panic at all.
Tailor The Gateway For The Task

Scenario:

Greg Holden operates an online business in Greece. He currently does business with a local gateway provider that allows him to accept payment in the local currency. His customers like the convenience of being able to pay for purchases using the local currency. Greg likes the services provided by the local gateway provider since the gateway provider gives him an attractive discount rate. However, Greg also has a lot of North American customers, who prefer to do transactions in US dollars. Greg's local payment gateway does not support this payment form. Can oPAYc help Greg?

Solution:

Yes, oPAYc can solve this problem for Greg, since oPAYc supports a transaction string that is common to ALL of the drivers. But Greg must first register with a North American service that is willing to do his company's transactions in USD. Then within the e-Commerce application, Greg should display the amount in both local currency and USD that he wishes to charge. Greg can either let the customer click on the amount they wish to pay, or decide based on the country of their address which of the two systems he wishes to process the transaction through. The information collected is the same for both drivers with the exception that Greg can pass in the amount and currency symbol for USD in one, and local currency in the other one. It's that simple.
Switch For A Better Deal

Scenario:

Monica Hartland does a large number of very small online transactions. Her current gateway provider operates on a per transaction flat fee which takes a really big bite out of her bottom line. Monica can get a better deal elsewhere but is worried about disturbing an already operating e-Commerce site. How can oPAYc help Monica?

Solution:

With oPAYc it is easy to change which gateway is used without ANY recoding of the e-Commerce application. Applications that work with oPAYc supply a set of standardized values to the gateway. These values were carefully selected to cover all the possibilities for various gateways. To switch, Monica would simply register with her new gateway provider, incorporate her new merchant account information into a data source for the driver, and switch the oPAYc call to use that new data source instead. As well, Monica can have as many data sources setup at one time as she wants and switch between them as often as she likes.
Multi-Gateway Robustness

Scenario:

Bill Thompson is an online retailer who makes sales only during very short periods of time around holidays. If his payment gateway is down for only an hour during these critical times he loses a substantial portion of his business. Can oPAYc help Bill?

Solution:

Yes, oPAYc can help Bill. When doing transactions with oPAYc, errors are returned in the "Internet" standard way. The error codes are all 3 digit numbers with 200 series meaning OK, 400 series meaning customer problem of some sort, and 500 series meaning technical problem of some sort. Bill can recognize these families of errors from those he sees in his web browser. In general terms, the meanings are the same as there. Upon attempting a transaction if Bill finds the transaction to have returned a 500 series error, either there is something wrong in the network, or the gateway website is malfunctioning. Should that happen, Bill can simply try the same transaction at another gateway he is registered with and setup for this purpose. The information will already have all been collected, so the customer does not even have to know this took place. They will just see the order being processed.
A Non-Web Solution

Scenario:

Preethi Shah has an Integrated Voice Response System (IVR) setup. She would like to compete with some of the websites that take online payments by offering the same service over the phone. Can oPAYc help Preethi accomplish this?

Solution:

Yes oPAYc can. Don't think of oPAYc as only a web based solution. While many of the payment gateways (the redirect ones) work only with forms on the Internet, oPAYc changes this. For the first time, merchants are able to access the capabilities of those systems from any application front-end. If your IVR system allows communication with an ODBC data source, it has all the capabilities needed to work with oPAYc. You will be able to collect enough information easily over the phone to provide the drivers all they need to process a transaction. Due to the fact that it is more cumbersome for a user to enter textual information over the phone several things should be kept in mind with the system's design. If using a system that supports AVS, it is likely the merchant's best option to not pass address information in at all, and ignore low AVS scores. (Forcing the customer to type their address on a phone is not user friendly.) A better option is to use the IVR system for an alternative front-end where the caller already has an account number which stores all their relevant personal information. Examples of this are - purchasing prepaid phone cards, paying utility bills, re-filling previous medical delivery orders, fast food delivery ordering systems, etc. Another trick can be avoiding name entry by verbally confirming the Caller ID data matches the name on the Card. A second step to this can be to then match the phone number in one of the various databases available, and extract address information from that for the transaction.
Hacker Thwarting

Scenario:

Casey Mayfield storefront business was going well. Her store was configured to automatically bill her customer's credit cards. Once the shopper made their selections, they hit a "Buy" button, and then they're taken to a purchase form. A "Prod_Description" field in that form was sent to a payment form so that Casey could later track what they purchased.

Solution:

The purchase form source looked something like this:

<form method=post method="https://secure.mystore.com/gw/native/interface">
<input type=hidden name="Account" value="111222333444:SITEX">
<input type=hidden name="Prod_Description" value="Deluxe $$$ Product">
<input type=hidden name="Price" value="995.50">
<input type=hidden name="Purch_Type" value="SALE">
<input type=hidden name="TransactType" value="CHARGE">

<input type=submit value="Make purchase">
</form>

Every night, Casey would look at the purchase record to review all the sales, and then get her products ready to ship. Case offers a wide variety of products listed in her inventory, and thus, has quite a wide price range. She recently had a problem with someone viewing the source of that purchase form with an ordinary browser. The individual saved the HTML source of the form as a file using an ASCII editor, and then changed some of the fields so that it looked something like this:
<form method=post method="https://secure.mystore.com/gw/native/interface">
<input type=hidden name="Account" value="111222333444:SITEX">
<input type=hidden'name="Prod_Description"'value="Deluxe'$$$'Product">
<input type=hidden name="Price" value="5.00">
<input type=hidden name="Purch_Type" value="SALE">
<input type=hidden name="TransactType" value="AUTH">

<input type=submit value="steal deluxe $$$ product">
</form>

Using their own "special" purchase form in their personal browser, the individual then clicked the "Buy" button. Notice the individual managed to charge himself only $5.00 for a product valued at $995.50. And to top it all off, the individual changed the transaction type, "TransType" to "AUTH", so his credit card wasn't even charged at all.

Casey figures she didn't review her purchase record very carefully that day, and as a result didn't even notice the changed price. She shipped the deluxe product without noticing and the individual got the product for free. Casey wants to know if by using oPAYc, could she have avoided the incident?

Solution:

With oPAYc, the customer's browser never actually contains any of the data sent to the payment processing gateway, so the opportunity for them to alter any of it is eliminated. The shopper will never have the chance to enter their own personal pricing structure. So Casey could have avoided the incident if she had been using oPAYc.
A Back Office Tool

Scenario:

Every night the Stanford Hills clearing house gets submissions from hundreds of clients for payment claims. These claims are against the respective company's account receivables. During the setup of the clearance system it is not known in advance which of several transaction clearing systems will actually be used to transfer the funds around. Client claims come in as simply a long list of all claims and are not divided by which client should be charged for which transfer. The system runs automatically, with no user interface except to validate or deny any transactions which are flagged as abnormal by the system. The Stanford Hills clearing house wants to know if oPAYc can make this clearing system more efficient.

Solution:

The first step in the application is to sort out a matrix of transactions to see how much is coming from each client, and how much is going out to the account receivables. If the clients are both consumers and providers, the net amounts are computed.

Next, the ACH commissions from each client are to be deducted/added (this would normally be on the gross transactions, but could be calculated based on any agreed upon rules). These final amounts can all be processed using oPAYc driver transactions to move funds from client accounts to the ACH account where there is a deficit, and using oPAYc CREDIT transactions to credit funds to clients where there is a surplus due. The net effect is the funds are moved around from the consumers to the producers, with the commissions staying in the ACH account. And the gateway used may be selected or altered at any time without affecting the rest of the system.

Another bonus is that the specific gateway may be chosen based on the transaction amount. For example, a fixed fee system may be used for larger transactions and a percentage based one may be used for small transactions.

Since there is no user input driving the system, transactions may also be deferred. For example, nothing under $50 would be processed, and would simply roll over to the next transaction period.
Copyright © 1998-2008 Inline Internet Systems, Inc.