Note to the Customer: Many Compontent of the Gas Pump and the Gas Pump interface have been contracted out to a hardware company as micro-controllers are out of the scope of our company. We realize that to demonstrate how the main computer is going to work and its features that there will have to be some kind of pump transactions, this will be done through 'stubs' that will simulate gas transactions from the pump. For more information on what has been contracted out to the hardware company and what we will provide for the Gas Pump interface consult the Data Flow Diagrams . Sorry for the inconvience.
This is perfectly acceptable.
Module 1
What the customer will see initially:
(the screen shots shown on this document have been given to the hardware comany and they will be use das a template and show not be expected to change to much unless requested)
We're not certain we understand that last sentence.
1) Customer will pull up to the pump an initial screen will be showing that will prompt the
customer to insert their debit or credit card for the transaction
NOTE: we will make up or own rules for identifying what card number corresponds with the accepted cards
i.e.
cards that begin with `1111' will be a Master Card
cards that begin with `2222' will be a Visa Card
cards that begin with `3333' will be a American Express Card
cards that begin with `4444' will be a Petro 451 Card
cards that begin with `1234' will be a Debit Card
all other cards will be rejected
(1.1.1)
- if the card is a credit card:
- the pump will now search through the bank's database to check to see if the cardholder has sufficient funds. As a general rule the pump will check to make sure that the customer has at least forty dollars of credit remaining.
- If the customer does pump more than forty dollars in gas and does exceed their limit the authorization number given with the original acceptance will allow for the card to over draw.
We do not like how this is handled. We never want our company to carry an overdraw, therefore a different method of handling this type of operation will have to be devised (we do not want to be stuck with other people's credit problems).
(1.1.1.1)
- the cardholder has sufficient funds:
- the user will now be prompted to choose what type of gas they would like to purchase. (see section 1.2)
- an authorization number will be given with the acceptance of the card, this will be stored with the data for the current transaction
(1.1.1.2)
- the cardholder has insufficient funds:
- if the cardholder has insufficient funds then the credit card will be returned to the cardholder and the screen will display that the card did not have the room available to purchase gas
Given the situation in which the customer wants to fill $5.00 worth of gas, would they be denied due to a credit check of $40.00, or is the credit check done on the specific amount entered? Is the $40.00 check done only on a manual or fill setting? Please clarify.
(1.1.1.3)
- the credit card is fraudulent or stolen:
- fraudulent or stolen cards will end with the string `1234'
- in the real implementation the card company will send a flag that will let the pump know that the card is fraudulent or stolen, this can not be implemented due to technicalities
- all cards will be given back to the customer except Visa which will be held inside the machine, (this will be implemented by showing appropriate message on the screen, in the real implementation the card would be held in a secure storage device inside the pump)
(1.1.1.4)
- the card has expired:
- cards that have expired will be identified by looking at the expiration date and comparing it to the current date
- expired cards will be given back to the user with a message that lets them know that their card has expired
We are curious if the credit card company doesn't already handle this, therefore saving us the cost of inplementing something that is already handled.
For the demonstration, however, this is good enough.
(1.1.2)
- if the card is a debit card:
- a screen will prompt the user to enter their Personal Identification Number.
- once the Personal Identification Number (P.I.N.) is entered the pump will check the number against the corresponding card number in its data base. (NOTE: in the real implementation the pump will call the an Interact number and send it the appropriate information and the receive an acknowledge, or a negative acknowledge)
(1.1.2.1)
- the P.I.N. matches the debit card:
- a screen will appear that will prompt the user to enter the amount of gas that they would like to purchase. ( The screen will explain to the user that the amount that they enter will be the maximum amount that they will be allowed to pump for this transaction, if the they do not pump in the full amount that they entered then the difference will be credited back to their account)
This is a good practice. We appreciate thoughtfulness in matters concerning the user interfaces.
- once the user has entered the amount that they would like to purchase the pump will check to make sure that the funds are available for the debit card entered, the system will check from a file that will represent the bank's database. (NOTE: in the real implementation the call to the Interact machine will verify that the funds are available in the account)
When does the customer select his or her account type (savings, chequing, etc.) ?
(1.1.2.1.1)
- the funds are available:
- if the funds are available then a maximum amount of gas will be set so that the pump does not pump more than the amount entered by the customer
(1.1.2.1.2)
- funds are not available:
- if the funds are not available then the pump will let the customer know that there were insufficient funds for the amount entered, and then the customer will be prompted to enter a new amount, and this new amount will be checked as above. (1.2.2.1)
Isn't there a possiblity that the amount available could be given back to the user? Some bank machines will tell you your remaining balance if a withdrawal fails. Please let us know if this feature is available.
(1.1.2.2)
- the number P.I.N. does not match the debit card
- a screen will politely let the user know that that they have entered an invalid P.I.N.#. Then the system will ask them to enter a new P.I.N. (1.1.2)
How many times can the user enter their P.I.N? Is there a limit on invalid entries? And if the limit is reached, what happens?
This is a good safeguard, we hope that your early warning system will prevent this from ever happening.
1. Regular unleaded
2. Mid- Grade unleaded
3. Premium unleaded
4. Diesel
Would it not be good user interface practice to have a "whoops"
button that allows the user to back up one screen/option
at a time?
(1.3.1)
- if they are using a credit card:
- if the customer is using a credit card a screen will appear that will prompt the user to enter the amount of gas that they would like to pump
- once the choice is made the user may change their mind as to how much they would like to purchase. (i.e. if they choose `fill' and then decide that they only wanted $5, they can just push the $5 button, this must be done before the customer pulls the nozzle out of the holster)
- when the choice has been made the pump software will take appropriate so that the pump known exactly how much gas is supposed to be pumped
Please clarify the above sentence.
- the user still might decide to get different amount of gas and this can be done by pressing and releasing the holster handle - effectively going to manual fill
- the customer may cancel the transaction at this point if they wish by pressing a button on the bottom left of the screen
(1.3.2)
- if they are using a debit card;
- a screen will appear that will prompt the customer to enter the amount of gas that they would like to pump into there vehicle. There will only be two button present on this screen. A button `manual fill' and a button to purchase the amount that they entered previously.
- again actions will be taken so that the pump knows not to pump more gas in to the vehicle than the amount entered before.(1.1.2)
We do not understand why you do not handle credit card transactions and
debit card transactions the same way.
(1.4.1)
- the card is a credit card:
- once the user begins to pump gas the pump will stop once the previously requested amount is reached. (1.3.1) If the customer desires to pump more gas into there vehicle they may do so with the total being added on to the what has already been pumped
- if `fill' has been chosen we will choose a random number with a mean of 35 to stop the pump at. In the real implementation the nozzle would sense the gas coming back through it but due to logistics we will not be able to implement this.
We do not understand what you mean by random number generation and mean of 35. Is this computer jargon, or is it actually part of our system?
- a note on the bottom of the screen will let the user know that they are supposed to put the gas nozzle back in the holster when they are done pumping the gas.
(1.4.2)
- the card is a debit card:
- once the user begin to pump the gas the pump will automatically stop when the previously entered amount (1.3.2) has been reached.
- a note at the bottom of the screen will let the user know that they are supposed to put the gas nozzle back into the holster when they are finished pumping the gas.
- the customer will be asked whether they would like another transaction:
We do not think it is necessary that the user is prompted for another transaction. As soon as the nozzle is in the holster, give back the customer's card and and give the customer a receipt.
(1.4.2.1)
- if they choose `yes':
- if the customer would like another transaction then they will start back at (1.1.2.1), where they will be asked how much gas they would like to purchase.
(1.4.2.2)
- if they choose `no':
- the customer will be thanked for using Petro 45, their card will be given back to them and procedure (1.1) will occur.
(1.5.1)
- if they used a credit card:
- the appropriate amount will be charged to the credit card that they entered and a receipt will be printed out for the customer, a message on the screen will display a `thank you' message for using Petro 451.
- the receipt will contain:
1. the price and type of the gas that was pumped
2. the amount of gas that was pumped in dollars and liters
3. the type and the number of their credit card
4. the date and the time of the purchase
5. the location of the gas station
6. a thank you note for using Petro 451
- a receipt will be printed, (for demonstration purposes a file will be created that will contain the information that the receipt would have printed on it) for the customer and a copy of the receipt will be written to a file inside the machine, in the real implementation the a paper receipt will be made inside the machine, but this hardware is unavailable to us currently.
(1.5.2)
- if they used a debit card:
- the difference between the amount that has been pumped and the initial amount entered will be credited back to their account, this will be done by adjusting the file with the appropriate information on it so that the balance will be correct. In the real implementation the bank would be called and the amount that needs to be credited back would be done via Interact
- this difference will be displayed on to the screen and a message will let customer know that their account has been credited the difference.
- the receipt will contain:
1. the price and type of the gas that was pumped
2. the amount of gas that was pumped in dollars and liters
3. the number of their debit card
4. the amount that was originally debited and the amount that was credited back to their account(if any)
5. the date and the time of the purchase
6. the location of the gas station
7. a thank you note for using Petro 451
- a receipt will be printed, (for demonstration purposes a file will be created that will contain the information that the receipt would have printed on it) for the customer and a copy of the receipt will be written to a file inside the machine, in the real implementation the a paper receipt will be made inside the machine, but this hardware is unavailable to us currently.
1. type of fuel pumped
2. amount of fuel pumped, in liters and dollars
3. date of purchase
This could be handled as a batch process.