Final Report 5

CREDIT CARD APPROVAL SYSTEM
CHAPTER 1
INTRODUCTION TO THE
PROJECT
1 Introduction
1
A credit card is part of a system of payments named after the small plastic card issued to users
of the system. It is a card entitling its holder to buy goods and services based on the holder's
promise to pay for these goods and services.[1] The issuer of the card grants a line of credit to the
consumer (or the user) from which the user can borrow money for payment to a merchant or as a
cash advance to the user. A credit card is different from a charge card, where a charge card
requires the balance to be paid in full each month. In contrast, credit cards allow the consumers
to 'revolve' their balance, at the cost of having interest charged. Most credit cards are issued by
local banks or credit unions, and are the shape and size specified by the ISO/IEC 7810 standard
as ID-1. This is defined as 85.60 × 53.98 mm in size.
1.1 History
The modern credit card was the successor of a variety of merchant credit schemes. It was first
used in the 1920s, in the United States, specifically to sell fuel to a growing number of
automobile owners. In 1938 several companies started to accept each other's cards. Western
Union had begun issuing charge cards to its frequent customers in 1921. Some charge cards were
printed on paper card stock, but were easily counterfeited.
The Charge-Plate was an early predecessor to the credit card and used during the 1930s and late
1940s. It was a 2 1/2" x 1 1/4" rectangle of sheet metal, similar to a military tag, that was
embossed with the customer's name, city and state (no address). It held a small paper card for a
signature. It was laid in the imprinter first, and then a charge slips on top of it, onto which an
inked ribbon was pressed.[26] Charga-Plate was a trademark of Farrington Manufacturing Co.
Charga-Plates was issued by large-scale merchants to their regular customers, much like
department store credit cards of today. In some cases, the plates were kept in the issuing store
rather than held by customers. When an authorized user made a purchase, a clerk retrieved the
plate from the store's files and then processed the purchase. Charga-Plates speeded back-office
bookkeeping that was done manually in paper ledgers in each store, before computers. The
concept of customers paying different merchants using the same card was invented in 1950 by
Ralph Schneider and Frank X. McNamara, founders of Diners Club, to consolidate multiple
2
cards. The Diners Club, which was created partially through a merger with Dine and Sign,
produced the first "general purpose" charge card, and required the entire bill to be paid with each
statement. That was followed by Carte Blanche and in 1958 by American Express which created
a worldwide credit card network (although these were initially charge cards that acquired credit
card features after BankAmerica demonstrated the feasibility of the concept).
However, until 1958, no one had been able to create a working revolving credit financial
instrument issued by a third-party bank that was generally accepted by a large number of
merchants (as opposed to merchant-issued revolving cards accepted by only a few merchants). A
dozen experiments by small American banks had been attempted (and had failed). In an odd
coincidence, both of the products that finally succeeded were born in the U.S. state of California.
In September 1958, Bank of America launched the BankAmerica in Fresno, California.
BankAmerica became the first successful recognizably modern credit card (although it
underwent a troubled gestation during which its creator resigned), and with its overseas affiliates,
eventually evolved into the Visa system. In 1966, the ancestor of MasterCard was born when a
group of California banks established Master Charge to compete with BankAmerica; it received
a significant boost when Citibank merged its proprietary Everything Card (launched in 1967)
into Master Charge in 1969.
Early credit cards in the U.S., of which BankAmerica was the most prominent example, were
mass produced and mass mailed to bank customers who were thought to be good credit risks;
that is, they were unsolicited. These mass mailings were known as "drops" in banking
terminology, and were outlawed in 1970 due to the financial chaos that they caused, but not
before 100 million credit cards had been dropped into the U.S. population. After 1970, only
credit card applications could be sent unsolicited in mass mailings. The fractured nature of the
U.S. banking system under the Glass-Steagall Act meant that credit cards became an effective
way for those who were traveling around the country to move their credit to places where they
could not directly use their banking facilities. In 1966 Barclaycard in the UK launched the first
credit card outside of the U.S. There are now countless variations on the basic concept of
revolving credit for individuals (as issued by banks and honored by a network of financial
institutions), including organization-branded credit cards, corporate-user credit cards, store cards
and so on.
In contrast, although having reached very high adoption levels in the US, Canada and the UK, it
is important to note that many cultures were much more cash-oriented in the latter half of the
twentieth century, or had developed alternative forms of cash-less payments, such as Carte blues
or the Euro card (Germany, France, Switzerland, and others). In these places, the take-up of
credit cards was initially much slower. It took until the 1990s to reach anything like the
percentage market-penetration levels achieved in the US, Canada, or the UK. In many countries
acceptance still remains poor as the use of a credit card system depends on the banking system
being perceived as reliable. Of particular note is Japan, which remains a very cash oriented
3
society, with credit card adoption being limited to only the largest of merchants, although an
alternative system based on RFIDs inside cell phones has seen some acceptance.
In contrast, because of the legislative framework surrounding banking system overdrafts, some
countries, France in particular, were much faster to develop and adopt chip-based credit cards
which are now seen as major anti-fraud credit devices.
The design of the credit card itself has become a major selling point in recent years. The value of
the card to the issuer is often related to the customer's usage of the card, or to the customer's
financial worth. This has led to the rise of Co-Brand and Affinity cards - where the card design is
related to the "affinity" (a university, for example) leading to higher card usage. In most cases a
percentage of the value of the card is returned to the affinity group.
1.2 How credit cars works
Credit cards are issued after an account has been approved by the credit provider, after which
cardholders can use it to make purchases at merchants accepting that card. When a purchase is
made, the credit card user agrees to pay the card issuer. The cardholder indicates consent to pay
by signing a receipt with a record of the card details and indicating the amount to be paid or by
entering a personal identification number (PIN). Also, many merchants now accept verbal
authorizations via telephone and electronic authorization using the Internet, known as a
'Card/Cardholder Not Present' (CNP) transaction.
Electronic verification systems allow merchants to verify that the card is valid and the credit card
customer has sufficient credit to cover the purchase in a few seconds, allowing the verification to
happen at time of purchase. The verification is performed using a credit card payment terminal or
Point of Sale (POS) system with a communications link to the merchant's acquiring bank. Data
from the card is obtained from a magnetic stripe or chip on the card; the latter system is in the
United Kingdom and Ireland commonly known as Chip and PIN, but is more technically an
EMV card.
Other variations of verification systems are used by ecommerce merchants to determine if the
user's account is valid and able to accept the charge. These will typically involve the cardholder
providing additional information, such as the security code printed on the back of the card, or the
address of the cardholder.
Each month, the credit card user is sent a statement indicating the purchases undertaken with the
card, any outstanding fees, and the total amount owed. After receiving the statement, the
cardholder may dispute any charges that he or she thinks are incorrect (see Fair Credit Billing
Act for details of the US regulations). Otherwise, the cardholder must pay a defined minimum
proportion of the bill by a due date, or may choose to pay a higher amount up to the entire
4
amount owed. The credit issuer charges interest on the amount owed if the balance is not paid in
full (typically at a much higher rate than most other forms of debt). Some financial institutions
can arrange for automatic payments to be deducted from the user's bank accounts, thus avoiding
late payment altogether as long as the cardholder has sufficient fund.
1.3 Credit Card Numbering
The numbers found on credit cards have a certain amount of internal structure, and share a
common numbering scheme. The card number's prefix, called the Bank Identification Number, is
the sequence of digits at the beginning of the number that determine the bank to which a credit
card number belongs. This is the first six digits for MasterCard and Visa cards. The next nine
digits are the individual account number, and the final digit is a validity check code.
In addition to the main credit card number, credit cards also carry issue and expiration dates
(given to the nearest month), as well as extra codes such as issue numbers and security codes.
Not all credit cards have the same sets of extra codes nor do they use the same number of digits.
1.4 Features of credit card
Some of the features of credit cards are:
• Logos: The card carries logos of the card association (Visa, MasterCard) as well as that
of the issuing bank (ICICI, HDFC and so on) in the front.
• Number: The card number is embossed in the front. This is usually a 16-digit number.
The first digit symbolizes the major industry. Banking industry cards usually start with 4,
5 or 6. The first six digits identify the issuing organization. The next nine digits denote
the individual’s account number. The last digit is a check digit.
• Name: Also embossed on the front of the card is the name of the cardholder.
• Expiry date: The date till which the card is valid is embossed on the front of the card.
• Magnetic stripe: There is a magnetic stripe (called magnetic strip) running through the
length of the card on its reverse. This contains the identification information of the card
which is transmitted during a transaction.
• CVV No.: This is a three-digit number that appears on the reverse of the card after the
16-digit card number. This is used as an additional security check, mostly in online
transactions.
5
• Signature: There is a space below the magnetic stripe where the cardholder is supposed
to sign. While processing a transaction, the merchant has to verify this signature.
• Contact Nos.: On the reverse of the card, the issuing bank’s contact numbers are printed.
The cardholder can call these numbers for any card-related queries.
1.5 Transaction Steps
• Authorization: The cardholder pays for the purchase and the merchant submits the
transaction to the acquirer (acquiring bank). The acquirer verifies the credit card number,
the transaction type and the amount with the issuer (Card-issuing bank) and reserves that
amount of the cardholder's credit limit for the merchant. An authorization will generate
an approval code, which the merchant stores with the transaction.
• Batching: Authorized transactions are stored in "batches", which are sent to the acquirer.
Batches are typically submitted once per day at the end of the business day. If a
transaction is not submitted in the batch, the authorization will stay valid for a period
determined by the issuer, after which the held amount will be returned back to the
cardholder's available credit (see authorization hold). Some transactions may be
submitted in the batch without prior authorizations; these are either transactions falling
under the merchant's floor limit or ones where the authorization was unsuccessful but the
merchant still attempts to force the transaction through. (Such may be the case when the
cardholder is not present but owes the merchant additional money, such as extending a
hotel stay or car rental.)
• Clearing and Settlement: The acquirer sends the batch transactions through the credit
card association, which debits the issuers for payment and credits the acquirer.
Essentially, the issuer pays the acquirer for the transaction.
• Funding: Once the acquirer has been paid, the acquirer pays the merchant. The merchant
receives the amount totaling the funds in the batch minus either the "discount rate," "mid-
qualified rate", or "non-qualified rate" which are tiers of fees the merchant pays the
acquirer for processing the transactions.
• Charge backs: A chargeback is an event in which money in a merchant account is held
due to a dispute relating to the transaction. Charge backs are typically initiated by the
cardholder. In the event of a chargeback, the issuer returns the transaction to the acquirer
for resolution. The acquirer then forwards the chargeback to the merchant, who must
either accept the chargeback or contest it.
6
1.6 Advantage
The major benefit of a credit card is that the individual using it dose not require ready cash to
make payments for various purchase
• No immediate cash
• Free credit
• World wide usage
• Tracking expense
• E-buying Cash
• withdrawal
1.7 Disadvantage
There is various feature of a credit card that seem to be a gift for the this person using the card
but a little bit of carelessness can change the entire position the same factor can end up being a
course for user.
• Interest cost 14%-15%person
• Charge
• Credit trap
• Multiple card
7
CHAPTER 2
SECURITY PROBLEMS
AND
SOLUTIONS
2 Security Problems and Solutions
8
Credit card security relies on the physical security of the plastic card as well as the privacy of the
credit card number. Therefore, whenever a person other than the card owner has access to the
card or its number, security is potentially compromised. Once, merchants would often accept
credit card numbers without additional verification for mail order purchases. It's now common
practice to only ship to confirmed addresses as a security measure to minimize fraudulent
purchases. Some merchants will accept a credit card number for in-store purchases, whereupon
access to the number allows easy fraud, but many require the card itself to be present, and
require a signature. A lost or stolen card can be cancelled, and if this is done quickly, will greatly
limit the fraud that can take place in this way. For internet purchases, there is sometimes the
same level of security as for mail order (number only) hence requiring only that the fraudster
take care about collecting the goods, but often there are additional measures. European banks
can require a cardholder's security PIN be entered for in-person purchases with the card.
The PCI DSS is the security standard issued by The PCI SSC (Payment Card Industry Security
Standards Council). This data security standard is used by acquiring banks to impose cardholder
data security measures upon their merchants.
A smart card, combining credit card and debit card properties. The 3 by 5 mm security chip
embedded in the card is shown enlarged in the inset. The contact pads on the card enable
electronic access to the chip.
The low security of the credit card system presents

countless opportunities for fraud. This opportunity has
created a huge black market in stolen credit card
numbers, which are generally used quickly before the
cards are reported stolen.
The goal of the credit card companies is not to

eliminate fraud, but to "reduce it to manageable levels".
This implies that high-cost low-return fraud prevention
measures will not be used if their cost exceeds the potential gains from fraud reduction - as
would be expected from organizations whose goal is profit maximization.
Most internet fraud is friendly fraud. The rest is done through the use of stolen credit card
information which is obtained in many ways, the simplest being copying information from
retailers, either online or offline. Despite efforts to improve security for remote purchases using
credit cards, systems with security holes are usually the result of poor implementations of card
acquisition by merchants. For example, a website that uses SSL to encrypt card numbers from a
client may simply email the number from the web server to someone who manually processes
the card details at a card terminal. Naturally, anywhere card details become human-readable
before being processed at the acquiring bank, a security risk is created. However, many banks
9
offer systems where encrypted card details captured on a merchant's web server can be sent
directly to the payment processor.
Controlled Payment Numbers which are used by various banks such as Citibank (Virtual
Account Numbers), Discover (Secure Online Account Numbers, Bank of America (Shop Safe), 5
banks using eCarte Blue and CMB's Virtual is in France, and Swanbank of Sweden's eKort
product are another option for protecting one's credit card number. These are generally one-time
use numbers that front one's actual account (debit/credit) number, and are generated as one shops
on-line. They can be valid for a relatively short time, for the actual amount of the purchase, or
for a price limit set by the user. Their use can be limited to one merchant if one chooses. The
effect of this is the users’ real account details are not exposed to the merchant and its employees.
If the number the merchant has on their database is compromised, it would be useless to a thief
after the first transaction and will be rejected if an attempt is made to use it again.
The same system of controls can be used on standard real plastic as well. For example if a
consumer has a chip and pin (EMV) enabled card they can limit that card so that it be used only
at point of sale locations restricted from being used on-line) and only in a given territory only for
use in Canada). This technology provides the option for banks to support many other controls too
that can be turned on and off and varied by the credit card owner in real time as circumstances
change they can change temporal, numerical, geographical and many other parameters on their
primary and subsidiary cards). Apart from the obvious benefits of such controls: from a security
perspective this means that a customer can have a chip and pin card secured for the real world,
and limited for use in the home country assuming it is totally chip and pin. In this eventuality a
thief stealing the details will be prevented from using these overseas in non chip and pin (EMV)
countries. Similarly the real card can be restricted from use on-line so that stolen details will be
declined if this tried. Then when card users shop online they can use virtual account numbers. In
both circumstances an alert system can be built in notifying a user that a fraudulent attempt has
been made which breaches their parameters, and can provide data on this in real time. This is the
optimal method of security for credit cards, as it provides very high levels of security, control
and awareness in the real and virtual world. Furthermore it requires no changes for merchants at
all and is attractive to users, merchants and banks, as it not only detects fraud but prevents it.
The Federal Bureau of Investigation and U.S. Postal Inspection Service are responsible for
prosecuting criminals who engage in credit card fraud in the United States, but they do not have
the resources to pursue all criminals. In general, federal officials only prosecute cases exceeding
US $5,000 in value. Three improvements to card security have been introduced to the more
common credit card networks but none has proven to help reduce credit card fraud so far. First,
the on-line verification system used by merchants is being enhanced to require a 4 digit Personal
Identification Number (PIN) known only to the card holder. Second, the cards themselves are
being replaced with similar-looking tamper-resistant smart cards which are intended to make
forgery more difficult. The majority of smart card (IC card) based credit cards comply with the
10
EMV (Euro pay MasterCard Visa) standard. Third, an additional 3 or 4 digit Card Security Code
(CSC) is now present on the back of most cards, for use in "card not present" transactions.
2.1 Over limit charges
Consumers who keep their account in good order by always staying within their credit limit, and
always making at least the minimum monthly payment will see interest as the biggest expense
from their card provider. Those who are not so careful and regularly surpass their credit limit or
are late in making payments are exposed to multiple charges that were typically as high as £25 -
£35 [17] until a ruling from the Office of Fair Trading[18] that they would presume charges over
£12 to be unfair which led the majority of card providers to reduce their fees to exactly that level.
2.2 Credit Card Fraud
The credit card industry is keenly seeking ways to control and minimize the billions of dollars
lost every year due to credit card fraud. If credit card issuers could accomplish that goal, they
could reap big benefits not merely by reducing losses and thus increasing revenues, but by
lowering their business risks and raising both customer confidence and satisfaction. Predictive
analytics is a powerful tool to help achieve that goal. 1So far the trend has been to bring in
customer analytics to analyze historical data after an event has occurred. This limits its value as
far as effective decision making is concerned. For example, credit card issuers use customer
analytics to sift through past transaction data to detect fraudulent transaction patterns. However,
since the losses have already arisen, the value of that insight remains limited. Predictive analysis,
on the other hand, provides intelligence in real time before the event. It can, therefore, be
invaluable in the detection and prevention of credit card fraud, by allowing issuers to catch
suspicious transactions before they go through, thus actually helping prevent fraud. So far,
predictive analytics in fraud detection has been constrained by issues of high costs and response
times. Therefore, it has not been used in a widespread manner. Now, however, powerful
computing hardware and network bandwidth are both widely available and much more
affordable. Simultaneously, over the last few years, credit card fraud has been on the rise
worldwide and is itself evolving, which makes detecting and preventing frauds an urgent
imperative. This confluence of events implies that the time is ripe for credit card issuers to begin
implementing fraud detection and prevention (FD&P) systems.
2.2.1 Overview of Real-time Fraud Detection and Prevention
So how does a FD&P system work? It intercepts all relevant transactions before they are
approved by the card issuer’s existing authorization system and passes them through algorithms
that calculate a Fraud Potential Index (FPI), which is a measure of how likely the transaction is
to be fraudulent. The card issuer assigns a certain weightage for each algorithm in the set, which
11
can differ based on a broad range of parameters. Both the number of algorithms to be used and
their relative weightages can be configured to suit individual card issuers’ policies. Using the
FPIs returned by individual algorithms, the FD&P system computes a ‘composite FPI’ across all
applicable algorithms, based on which it derives an action code that it sends to the existing
authorization system.
The card issuer can specify different actions depending on the parameters of the transaction. For
example, certain transactions can be approved, others declined and still others can be passed but
marked for future declines or interventions. Such marking can be performed by amount, or
incidence, or by other parameters decided by the issuer. A card issuer could choose to use
proprietary or industry standard algorithms. A good FD&P solution should come with a rich set
of industry standard algorithms along with the ability to be augmented with issuer specific,
proprietary and customized ones.
12
CHAPTER 3
SOFTWARE DEVELOPMENT LIFE

CYCLE
3 SOFTWARE DEVELOPMENT LIFE CYCLE

13
3.1 Introduction
The product developed which achieves customer satisfaction is not done in a single step. It
involves series of steps in a software development process. This is needed to develop quality
products with error free products to achieve customer satisfaction. There are many models
available in the software development process.
But majority of software development process follow the model named as software development
life cycle. This software develop life cycle has number of steps in it. The below article describes
about the software development life cycle and the steps involved into it.
Software development life cycle model is also called as waterfall model which is followed by
majority of systems.
The largely growing body of software development organizations implement process
methodologies. Many of them are in the defence industry, which in the U.S. requires a rating
based on 'process models' to obtain contracts. The international standard for describing the
method of selecting, implementing and monitoring the life cycle for software is ISO 12207.
A decades-long goal has been to find repeatable, predictable processes that improve productivity
and quality. Some try to systematize or formalize the seemingly unruly task of writing software.
Others apply project management techniques to writing software. Without project management,
software projects can easily be delivered late or over budget. With large numbers of software
projects not meeting their expectations in terms of functionality, cost, or delivery schedule,
effective project management appears to be lacking.
Organizations may create a Software Engineering Process Group (SEPG), which is the focal
point for process improvement. Composed of line practitioners who have varied skills, the group
is at the center of the collaborative effort of everyone in the organization who is involved with
software engineering process improvement.
1.System Requirements Analysis

2. Feasibility study
3. Systems Analysis and Design
4. Code Generation
5. Testing
6. Maintenance
7. Implementation
Software development activities:
14
Fig 3.1.1
The activities of the software development process represented in the waterfall model.
3.2 Requirement Analysis:

A systematic investigation of a real or planned system to determine the function of the system
and how they relate to each other and to any other system is known as system analysis.
System analysis is conducted with the following objectives in mind:

• Identify the customer’s need,
• Perform economic and technical analysis,
• Evaluate the system concept for feasibility,
• Allocate functions to hardware, software, people, database and other
system elements,
• Establish cost and schedule constraints,
• Create a system definition that forms the foundation for all subsequent
engineering work.
3.3 Overview
Problem recognition means detailed study of the current system being used by the user. A
detailed study of system being currently used must be carried out of sessions with customer and
end user. It can be termed as a process of recognizing problems and opportunities. A complete
15
understanding of software requirement is essential to the success of a software development

effort. The problem evaluation and solution synthesis is the next area of effort for analysis. It
enables the system, engine to redefine the software allocation and build model of process
followed
• Identification of need
• Preliminary investigation
3.3.1 Identification of need

The first step of the system Analysis process involves the identification of need. The analyst
meets the customer and the end user (if different from the user). The intent is to understand the
products objective and to define the goals required to meet the objectives. Timely Customer-
Analyst communication is an important ingredient of the system analyst’s work. The specific
objectives are:
• Reducing the Duplication during manual Processing
• Designing and Developing User friendly interfaces through which user will
interact with the package.
• Interaction of these GUI with the Database.
• Managing the Database.
• Improve efficiency and quality of services.
There are the number of factors that needs to be actively handled, the system must track the data
and be able to manage it as give the detailed account of the comparative study in the forms of
graphs and reports.
Every system must have some complexity attached with it , which is needed to the simplified so
that we can achieve a system, which is easier, less complex and easily accessible to the less
trained user.
The above started complexity being faced by the staff in respect of such a large number of
departments and variety of programs being run by each department, each having its own criteria
makes it entice the official to look for a system which can operate with a such a complex nature
of data and be developed in such away so that it becomes relatively easier to operate by the end
user.
3.3.2 Preliminary Investigation:

During the analysis phase of the project, first we decided to sit/talk/ and understand the current
workflow. And found that the basic functionality is divided into 12 major modules, which deals
with registration management, searching for tender management, supplying and purchasing of
16
tender management, generation of reports for each requirement and searching for many other
facilities etc.
3.4 FEASIBILTY STUDY:
3.4.1 Technology and system feasibility:

The assessment is based on an outline design of system requirements in terms of Input,
Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes
of data, trends, frequency of updating, etc. in order to estimate whether the new system will
perform adequately or not this mean that feasibly is the study of the based in outline.
3.4.2 Economic feasibility:

Economic analysis is the most frequently used method for evaluating the effectiveness of a new
system. More commonly known as cost/benefit analysis
, the procedure is to determine the benefits and savings that are expected from a candidate
system and compare them with costs. If benefits outweigh costs, then the decision is made to
design and implement the system.Feasibily is how an entrepreneur is based on his or her work.
3.4.3 Legal feasibility:

Determines whether the proposed system conflicts with legal requirements, e.g. a Data
Processing system must comply with the local Data Protection Acts.
3.4.4 Operational feasibility:

Is a measure of how well a proposed system solves the problems, and takes advantages of the
opportunities identified during scope definition and how it satisfies the requirements identified in
the requirements analysis phase of system development.
3.4.5 Schedule feasibility

A project will fail if it takes too long to be completed before it is useful. Typically this means
estimating how long the system will take to develop, and if it can be completed in a given time
period using some methods like payback period. Schedule feasibility is a measure of how
reasonable the project timetable is. Given our technical expertise, are the project deadlines
reasonable? Some projects are initiated with specific deadlines. You need to determine whether
the deadlines are mandatory or desirable.
3.4.6 Market and real estate feasibility:

Market Feasibility Study typically involves testing geographic locations for a real estate
development project, and usually involves parcels of real estate land. Developers often conduct
17
market studies to determine the best location within a jurisdiction, and to test alternative land
uses for a given parcels. Jurisdictions often require developers to complete feasibility studies
before they will approve a permit application for retail, commercial, industrial, manufacturing,
housing, office or mixed-use project. Market Feasibility takes into account the importance of the
business in the selected area.
3.4.7 Resource feasibility:

This involves questions such as how much time is available to build the new system, when it can
be built, whether it interferes with normal business operations, type and amount of resources
required, dependencies, etc. Contingency and mitigation plans should also be stated here.
3.4.8 Cultural feasibility:

In this stage, the project's alternatives are evaluated for their impact on the local and general
culture. For example, environmental factors need to be considered and these factors are to be
well known. Further an enterprise's own culture can clash with the results of the project. Once
the general requirements are gleaned from the client, an analysis of the scope of the development
should be determined and clearly stated. This is often called a scope document. Certain
functionality may be out of scope of the project as a function of cost or as a result of unclear
requirements at the start of development. If the development is done externally, this document
can be considered a legal document so that if there are ever disputes, any ambiguity of what was
promised to the client can be clarified.
18
CHAPTER 4
DESIGN SPECIFICATIONS
4 Design Specifications
19
4.1Scope
In this section we define the scope of the design effort. The design phase is an important part of
the system development phase. A good design of the system needs creativity and flair from the
designer and is the key to effective and successful engineering The following are the basic
objectives of the software design process:
• To describe the process of software design where informal ideas are transformed into
detailed implementation description.
• Introduction of different stages in the design process.
• Understanding whether an Object Oriented or a Functional Oriented approach or both

should be applied to the software.
• Determining and improving, cohesion control and coupling within subsystems.
In the project, the design phase has been identified as one of the most crucial documents.
In this phase, we have identified the various aspects of the “CRM”, which have to be
implemented as subsystems and their further components.
4.2 Flow Chart

A flowchart is a common type of diagram, that represents an algorithm or process, showing the
steps as boxes of various kinds, and their order by connecting these with arrows. Flowcharts are
used in analyzing, designing, documenting or managing a process or program in various fields.
Symbols:
A typical flowchart from older Computer Science textbooks may have the following kinds
of symbols:
• Start and end symbols
Represented as circles, ovals or rounded rectangles, usually containing the word "Start" or
"End", or another phrase signalling the start or end of a process, such as "submit enquiry" or
"receive product".
• Arrows
Showing what's called "flow of control" in computer science. An arrow coming from one symbol
and ending at another symbol represents that control passes to the symbol the arrow points to.
20
• Processing steps
Represented as rectangles.
• Input/output
Represented as a parallelogram.
• Conditional or decision
Represented as a diamond (rhombus). These typically contain a Yes/No question or True/False

test. This symbol is unique in that it has two arrows coming out of it, usually from the bottom
point and right point, one corresponding to Yes or True, and one corresponding to No or False.
The arrows should always be labelled. More than two arrows can be used, but this is normally a
clear indicator that a complex decision is being taken, in which case it may need to be broken-
down further, or replaced with the "pre-defined process" symbol.
Enter user id
A number of other symbols that have lessanduniversal
password currency, such as:
• A Document represented as a rectangle with a wavy base;

• A Manual input represented by parallelogram, with the top irregularly sloping up from
left to right. An example would be to signify data-entry from a form;
• A Manual operation represented by a trapezoid with the longest parallel side at the top, to
represent an operation or adjustment to process that can only be made manually.
Flowcharts may contain other symbols, such as connectors, usually represented as circles, to
represent converging paths in the flowchart. Circles will have more than one arrow coming into
them but only one going out. Some flowcharts may just have an arrow point to another arrow
instead. These are useful to represent an iterative process (what in Computer Science is called a
loop). A loop may, for example, consist of a connector where control first enters, processing
steps, a conditional with one arrow exiting the loop, and one going back to the connector. Off-
page connectors are often used to signify a connection to a (part of another) process held on
another sheet or screen. It is important to remember to keep these connections logical in order.
All processes should flow from top to bottom and left to right.
4.2.1 Flow Chart For Admin

START
Login
21 Click to the card

number and then to the
approved
Correct Check user Incorrect

id and Match all
password the
entries
Id/password is
wrong
Click to add button Reject
View the entry in

the data base
Enter card number,
holder name, CW
number, card issue
month, card expiry
enter
month, user id, password,
and bank
Check all
Click to save button
above entries
Correct wrong
END
Display a msg
corresponding to the
Fig 4.2.1 Flow Chart for admin error
login
4.2.2 Flow Chart For User
Start
22
Check user id
Various options Enter user id and
and password in
will displayed to password
database
the user END Error msg will display
Correct incorrect
Fig 4.2.2 Flow Chart for User
4.3 Data Flow Diagram [D F D]

A data flow diagram is the graphical representation of the “flow” of data through an
INFORMATION SYSTEM. It differs from the FLOW CHART as it shows the data flow instead
of control of the program.
There are several modelling rules that are followed in creating a DFD
1) All processes must have one data flow in and one data flow out.
23
2) All processes must modify the incomplete data, producing new forms of outgoing data.
3) Each data store must be provided with at least one data flow.
4) Each external entity must be involved with atleast one data flow.
5) A data flow must be attached to atleast one process.
Primitive Symbols Used For Constructing D F D

Function Symbol
A function is represented using a circle. This symbol is called a process or a bubble. Bubble is
denoted with the names of corresponding functions.
External Entity Symbol
An external entity such as a librarian, a library member etc., is represented by a rectangle. The
external entities are essentially those physical entities external to the software system or by
consuming the data produced by the system.
Data Flow Symbol
A directed arc or an arrow is used as a data flow or an arrow is used as a data flow symbol. A
data flow symbol. A data flow symbol represents the data flow occurring between two processes,
or between two process, or between an external entity and a process in a data flow arrow.
Data Store Symbol
A data store represents a logical file. It is represented using two parallel line .A logical file can
represent either a data store symbol which can represent either data structure or a physical file on
disk.
Developing A Data Flow Diagram
24
1)The system designer makes “ a context level D F D “ or level 0 , which shows the “ the
interaction “ (data flows) between “the system” (represented by one process) and “ the
system environment “ ( represented by entity).
2)The system is “decomposed in lower level D F D (“decomposed in lower level D F D ( level 1)

into a set of processes , data stores and the data flows between these processes and data stores .
3) Each process is then decomposed into an “even –lower –level diagram containing its sub
process.
4) This approach “then continues on the subsequent sub process “ , until a necessary and
sufficient level of detail is reached which is called primitive process.
Event Partitioning Approach

1) Construct detailed data flow diagram.
2) The list of all events is made.
3) For each event a process is constructed.
4) Each process is linked directly with other process via data stores, so that it has enough
information to respond to a given event.
5) The reaction of each process to a given event is modelled by an outgoing data flow.
Context Level Diagram OR Zero Level D F D

This level shows the overall context of the system and its operating environment and shows the
whole system as just one process. It does not usually show data store, unless they are owned by
the external system.
4.3.1 0-Level DFD For Admin Module

25
Filling entries approved data saved in

User Approv
Entries are wrong al Database
Process
Fig 4.3.1 DFD Level 0 For Admin
4.3.2 1- Level DFD For Admin Module
Enter the data Process (1.1)

User
Form filling
Data is correct process
Entries send to
Process
(1.2)
Entries are wrong Approval
Process
Entries are correct and saved in
Database
Send entries to
Process (1.3)
Process of
saving the Save in Database
approved
Fig 4.3.2 DFD Level 1 For Admin entries
4.3.3 0- Level DFD For User Module

26
Enter information info is correct

Process
User of Perform operations on data
providing stored in database
Info is wrong options
Fig 4.3.3 DFD Level 0 For User
4.3.4 1- Level DFD For User Module
Process (1.1)
Fill entries Form filling

User process
Entries are wrong
Send entries to
Perform op. on
Process (1.2)
Process of Data stored in

providing database
operations
Fig 4.3.4 DFD Level 1 For User
4.4 Entity Relationship Modelling
27
An ERM is an abstract and conceptual relationship of data. ERM is a database modelling

method used to produce a type of conceptual schema or semantic data model of a system, often a
relational database and its requirements in a top – down fashion.
Diagrams created using this process are called ERD’s. An ERD is a data modeling technique
that creates a graphical representation of the entities and relationship within the entities, within
an information system. Entity-relationship diagrams don't show single entities or single instances
of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an
entity. The collection of all songs in a database is an entity set. The eaten relationship between a
child and her lunch is a single relationship. The set of all such child-lunch relationships in a
database is a relationship set.
The three main components of an ERD are:
Entity
The entity is a person, object, place or event for which data is collected. For example, if you
consider the information system for a business, entities would include not only customers, but
the customer's address, and orders as well. The entity is represented by a rectangle and labelled
with a singular noun.
Relationship
The relationship is the interaction between the entities. In the example above, the customer
places an order, so the word "places" defines the relationship between that instance of a customer
and the order or orders that they place. A relationship may be represented by a diamond shape, or
more simply, by the line connecting the entities. In either case, verbs are used to label the
relationships.
Attributes
An entity is represented by a set of attributes. Attributes are descriptive properties possessed by

each member of an entity set. The designation of an attribute for an entity set expresses that the
28
database stores similar information concerning each entity in the entity set; however each entity
may have its own value for each attribute.
The steps involved in creating an ERD are:
• Identify the entities.

• Determine all significant interactions.
• Analyze the nature of the interactions.
• Draw the ERD.
ERD brings out issues:
• Many-to-Many
• Ambiguities
• Entities and their relationships
• What data needs to be stored
• The Degree of a relationship
How do we start an ERD?
• Define Entities: these are usually nouns used in descriptions of the system, in the
discussion of business rules, or in documentation; identified in the narrative
• Define Relationships: these are usually verbs used in descriptions of the system or in
discussion of the business rules (entity ______ entity); identified in the narrative.
Add attributes to the relations; these are determined by the queries, and may also suggest new
entities, e.g. grade; or they may suggest the need for keys or identifiers.
Add cardinality to the relations
Many-to-Many must be resolved to two one-to-many with an additional entity
• Represent that information with symbols.
4.4.1 Entity Relationship Diagram For Credit Card Approval System
29
User id
User
User User security
User id name nu
name
Give
approv User
Admin
al
Date of
updatin User’s
List of g security
transact nu
ions
Transa
ctions
Database and
updati
ng
User
User id
name
Fig 4.4.1 Entity Relationship Diagram
30
CHAPTER 5
SYSTEM SPECIFICATIONS
5 Hardware & Software Requirements

31
5.1 Hardware requirement
1. Main Processor: Pentium IV

2. Hard-disk Capacity: 8 G.B
3. RAM: 256 MB
4. Clock Speed: 2.8 Hz
5. Floppy Drive: 1.44MB
6. Keyboard : 104 Key
7. Monitor: V.G.A
5.2 Software Requirement
Operating System:
Windows 98, XP and above
Language Used:
JAVA (j2sdk1.4.2_04)
32
CHAPTER 6
SNAPSHOTS
33
34
35
36
37
CHAPTER 7
TESTING
7 Software testing
38
Software testing is an investigation conducted to provide stakeholders with information about

the quality of the product or service under test. Software testing also provides an objective,
independent view of the software to allow the business to appreciate and understand the risks at
implementation of the software. Test techniques include, but are not limited to, the process of
executing a program or application with the intent of finding software bugs.
Software testing can also be stated as the process of validating and verifying that a software
program/application/product:
1. meets the business and technical requirements that guided its design and development;
2. works as expected; and
3. can be implemented with the same characteristics.
Software testing, depending on the testing method employed, can be implemented at any time in
the development process. However, most of the test effort occurs after the requirements have
been defined and the coding process has been completed. As such, the methodology of the test is
governed by the software development methodology adopted.
Different software development models will focus the test effort at different points in the
development process. Newer development models, such as Agile, often employ test driven
development and place an increased portion of the testing in the hands of the developer, before it
reaches a formal team of testers. In a more traditional model, most of the test execution occurs
after the requirements have been defined and the coding process has been completed.
7.1 Overview
Testing can never completely identify all the defects within software. Instead, it furnishes a
criticism or comparison that compares the state and behavior of the product against oracles—
principles or mechanisms by which someone might recognize a problem. These oracles may
include (but are not limited to) specifications, contracts,[2] comparable products, past versions of
the same product, inferences about intended or expected purpose, user or customer expectations,
relevant standards, applicable laws, or other criteria.
Every software product has a target audience. For example, the audience for video game
software is completely different from banking software. Therefore, when an organization
develops or otherwise invests in a software product, it can assess whether the software product
will be acceptable to its end users, its target audience, its purchasers, and other stakeholders.
Software testing is the process of attempting to make this assessment.
39
A study conducted by NIST in 2002 reports that software bugs cost the U.S. economy $59.5
billion annually. More than a third of this cost could be avoided if better software testing was
performed.
7.2 Scope
A primary purpose for testing is to detect software failures so that defects may be uncovered and
corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly
under all conditions but can only establish that it does not function properly under specific
conditions. The scope of software testing often includes examination of code as well as
execution of that code in various environments and conditions as well as examining the aspects
of code: does it do what it is supposed to do and do what it needs to do. In the current culture of
software development, a testing organization may be separate from the development team. There
are various roles for testing team members. Information derived from software testing may be
used to correct the process by which software is developed.
7.3 Testing methods
7.3.1 The box approach
Software testing methods are traditionally divided into white- and black-box testing. These two
approaches are used to describe the point of view that a test engineer takes when designing
test cases.
7.3.2 White box testing
White box testing is when the tester has access to the internal data structures and algorithms
including the code that implement these.
The following types of white box testing exist:
• API testing (application programming interface) - testing of the

application using public and private APIs
• Code coverage - creating tests to satisfy some criteria of code coverage
(e.g., the test designer can create tests to cause all statements in the program to be
executed at least once)
• Fault injection methods - improving the coverage of a test by introducing
faults to test code paths
• Mutation testing methods
• Static testing - White box testing includes all static testing
40
7.3.3 Black box testing
Black box testing treats the software as a "black box"—without any knowledge of internal
implementation. Black box testing methods include: equivalence partitioning, boundary value
analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory
testing and specification-based testing.
Specification-based testing: Specification-based testing aims to test the functionality of

software according to the applicable requirements. Thus, the tester inputs data into, and
only sees the output from, the test object. This level of testing usually requires thorough
test cases to be provided to the tester, who then can simply verify that for a given input,
the output value (or behavior), either "is" or "is not" the same as the expected value
specified in the test case. Specification-based testing is necessary, but it is insufficient to
guard against certain risks.
7.3.4 Grey box testing
Grey box testing (American spelling: gray box testing) involves having knowledge of internal
data structures and algorithms for purposes of designing the test cases, but testing at the user, or
black-box level. Manipulating input data and formatting output do not qualify as grey box,
because the input and output are clearly outside of the "black-box" that we are calling the system
under test. This distinction is particularly important when conducting integration testing between
two modules of code written by two different developers, where only the interfaces are exposed
for test. However, modifying a data repository does qualify as grey box, as the user would not
normally be able to change the data outside of the system under test. Grey box testing may also
include reverse engineering to determine, for instance, boundary values or error messages.
7.4 Testing levels
Tests are frequently grouped by where they are added in the software development process, or by
the level of specificity of the test.
7.4.1 Unit testing
Unit testing refers to tests that verify the functionality of a specific section of code, usually at the
function level. In an object-oriented environment, this is usually at the class level, and the
minimal unit tests include the constructors and destructors.
These type of tests are usually written by developers as they work on code (white-box style), to
ensure that the specific function is working as expected. One function might have multiple tests,
to catch corner cases or other branches in the code. Unit testing alone cannot verify the
41
functionality of a piece of software, but rather is used to assure that the building blocks the
software uses work independently of each other. Unit testing is also called component testing.
7.4.2 Integration testing
Integration testing is any type of software testing that seeks to verify the interfaces between
components against a software design. Software components may be integrated in an
iterative way or all together ("big bang"). Normally the former is considered a better
practice since it allows interface issues to be localized more quickly and fixed.
Integration testing works to expose defects in the interfaces and interaction between integrated
components (modules). Progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the software
works as a system.
7.4.3 System testing
System testing tests a completely integrated system to verify that it meets its requirements.
7.4.4 System integration testing
System integration testing verifies that a system is integrated to any external or third party
systems defined in the system requirements.
7.4.5 Regression testing
Regression testing focuses on finding defects after a major code change has occurred.
Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such
regressions occur whenever software functionality that was previously working correctly stops
working as intended. Typically, regressions occur as an unintended consequence of program
changes, when the newly developed part of the software collides with the previously existing
code. Common methods of regression testing include re-running previously run tests and
checking whether previously fixed faults have re-emerged. The depth of testing depends on the
phase in the release process and the risk of the added features. They can either be complete, for
changes added late in the release or deemed to be risky, to very shallow, consisting of positive
tests on each feature, if the changes are early in the release or deemed to be of low risk.
7.4.6 Acceptance testing
Acceptance testing can mean one of two things:
42
1. A smoke test is used as an acceptance test prior to introducing a new build to the main
testing process, i.e. before integration or regression.
2. Acceptance testing performed by the customer, often in their lab environment on their
own hardware, is known as user acceptance testing (UAT). Acceptance testing may be
performed as part of the hand-off process between any two phases of development.[
7.4.7 Alpha testing
Alpha testing is simulated or actual operational testing by potential users/customers or an

independent test team at the developers' site. Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing, before the software goes to beta testing]
7.4.8 Beta testing
Beta testing comes after alpha testing. Versions of the software, known as beta versions, are
released to a limited audience outside of the programming team. The software is released to
groups of people so that further testing can ensure the product has few faults or bugs. Sometimes,
beta versions are made available to the open public to increase the feedback field to a maximal
number of future users.
7.5 Testing tools
Program testing and fault detection can be aided significantly by testing tools and debuggers.
Testing/debug tools include features such as:
• Program monitors, permitting full or partial monitoring of program code including:

o Instruction set simulator, permitting complete instruction level monitoring and
trace facilities
o Program animation, permitting step-by-step execution and conditional breakpoint
at source level or in machine code
o Code coverage reports
• Formatted dump or symbolic debugging, tools allowing inspection of program variables
on error or at chosen points
• Automated functional GUI testing tools are used to repeat system-level tests through the
GUI
• Benchmarks, allowing run-time performance comparisons to be made
• Performance analysis (or profiling tools) that can help to highlight hot spots and resource
usage.
Overview
43
Test plan objectives To ensure that the Credit card approval System
will:
- Function consistently and reliably in
accordance with current business operations.
- Meet or exceed user requirements and
technical specifications.
- Not adversely impact other systems or the
existing technology environment
Testing Assumptions It is assumed that there are few reviewers and

customers whose personal details, username
and password are already stored in the
database.
- The subscription codes of each customer are
assumed to be unique
Risks & Contingencies The following risks apply to the testing process
and may impact either the comprehensive level
of testing that can be performed in each of the
Functional Units:
- The actual deployment of Article Information
System may take longer to perform than
anticipated, as the admin is also using the same
database for maintenance.
Table 7.1.1
Test Scope
Features to be Tested All features, forms, reports and interfaces will be
tested. These include:
- Login forms
- Registration form
-Transaction
-Approval form
-Credit card security code
-Database used for both authentication and

validation
44
Features Not to be Tested - Data integrity and system functionality

contained within the
Credit card Approval System and which is not
Online
Table 7.2.1
Test Methodologies
Testing Approach The following approach will be used to test the
Credit card Approval
System
- System integration & system testing will be
conducted to provide an initial stable testing
environment as follows:
Integration
 Testing: Ensure operability of
System application within each of the new
modules.
System
 Testing: Ensure that all the test
databases are accessible for testing.
- Test cases and associated scripts for user
acceptance testing are created.
- For testing the functional specification the
unit testing is performed
.
Test Documents The following test documents will be created

and maintained throughout
the project lifecycle:
- System Test Plan
- Master test case lists for each of the following
functional units:
Login,
Add,Save,Approval,Transaction,Security code,
Search
- Test case scripts for each test case recorded in
the master test case list
- Log of all problems encountered during the
45
testing phase of the project
Test Case Pass/Fail Each Test Case will be evaluated against the
Criteria acceptance criteria as outlined in the test case
scripts to determine if the test passed or failed.
In the case of a failure, the tester will assign a
severity to the problem using the appropriate
priority rating system established within
Tracker for each application.
Suspension/Resumption Test Cases that do not run to completion will
Criteria be evaluated on a case by case basis to
determine if the testing must start over or
resume at the point where the failure occurred.
In extremely long test cases, checkpoints will
be established for resumption in the middle of
a test case where appropriate. In general, a test
may be resumed in the middle when the error is
not critical.
Problem Errors identified through testing will be logged.
Logging/Resolution Resolve the problem According to the deemed
severity level, and update the master test case
list. Once the problem has been fixed, record
the resolution into the database The failed test
case will then be retested using the same test
case script that detected the error in order to
verify that the problem has been rectified.
Table 7.3.1
7.6 Test Schedule
Testing Activity Dependencies Timeframe

Preparation of the testing None Feb – Mar
environment
Integration & System Testing environment has been Mar 14

testing set up
Establishment of Test Plan None Mar 14

46
and Testing Templates
Updating of Functional None Start Apr 14

Unit Master Test Case Lists
and Test Case Scripts
Actual Testing (execution Testing environment has Start Apr 14, 2009
of Test Case Scripts) been set up
- Integration & System
Testing has been
completed
- Test Case Scripts have
been developed
Final Functional User - Deployment of Credit card Apr 21 , 2009

Acceptance Testing & Approval system
Sign-off
Table 7.6.1
47
CHAPTER 8
CONCLUSION
8 Conclusions
48
Using the credit card number, you submit an electronic request to the processing network for
"authorization to capture funds" from the cardholder's credit card account in the amount of the
purchase. Traditionally, one would submit this request by swiping a credit card through an
electronic transaction terminal provided by the bank. With the system, this request is provided
electronically to our payment gateway servers, which then route the request along the processing
network. Other variations of verification systems are used by ecommerce merchants to determine
if the user's account is valid and able to accept the charge. These will typically involve the
cardholder providing additional information, such as the security code printed on the back of the
card, or the address of the cardholder.
8.1The Future Work
It is expected that credit cards will gradually give way to smart cards. A smart card has a
microprocessor built into the card itself .Cryptography is essential to the functioning of these
cards in several ways; the user must corroborate with his identity to the card each time a
transaction is made, in much the same way that a PIN is used with an ATM. The card reader
execute a sequence of a encrypted – Sign/Counter- Sign-Like exchanges to verify that each is
dealing with a legitimate counter part. Once this has been established, the transactions itself is
carried out in encrypted from to prevent anyone, including the card holder or the merchant whose
card reader is involved, from “Eaves Dropping” on the exchange and later impersonating either
party to defraud the system. This elaborate protocol is conduct in such a way that it is invisible to
the user; accept for the necessity of entering a PIN to begin the transaction. Smart card first saw
general use in France in 1984. They are now hot commodities that are expected to replace the
simple plastic cards most of us use now. Visa & master Card are leading the way in the USA.
With their Smart Card technologies. The chips in these cards are capable of many kinds of
transactions. For example you could make purchases from your credit account, debit account or
from a stored account value that’s re-loadable. The enhanced memory and processing capacity of
the smart card is many times that of traditional magnetic strip card and can accommodate several
different applications on a single card. It can also hold identification information, keep track of
your participation in an affinity (Loyalty) program or provide access to your office. The means
no more shuffling through cards in your wallet to find the right one- the smart card will be the
only one you need. Experts say that internationally accepted smart cards will be increasingly
available over the next several. Many parts of the world already use them, but their reach is
limited. The smart card will eventually be available to any one who wants one, but for now, it’s
available mostly to those participating in special programs.
8.2 References
8.2.1 Internet References
49
1. http://www.identitytheft.info/optingout.aspx
2. http://www.theukcardsassociation.org.uk/misc/-/page/faqs/#question2
3. http://money.cnn.com/2008/07/28/news/credit_card_interchange/
4. http://www.creditcards.com/credit-card-news/merchants-who-violate-credit-card-terms-
1275.php
7. www.ezinearticles.com
8. www.scribd.com
8.2.2 Book references

1. THE ART OF JAVA, Herbert Schildt / James Holmes, NEW YORK, 2003
2. HEAD FIRST JAVA, Kathy Sierra & Bert Bates, AMERICA, MAY 2003
3. THE COMPLETE REFERENCE, Herbert Schildt, NEWYORK, 2003
50
APPENDIX
Frame
51
Frame encapsulates what is commonly thought of as a “window”. It is subclass of

window and has a title bar, menu bar,borders,resizing corners. If you create a frame
object from with in an applet, it will contain a warning message, such as “java Applet
window, “to the user that an applet window has been created. This message warns users
that the window they see was started by an applet and not by software running on their
computer
creditadmin() {
setTitle("Login");
gl=new GridBagLayout();
gbc=new GridBagConstraints();
setLayout(gl);
lb1=new Label("Enter UserID");
txt1=new TextField(10);
lb2=new Label("Enter Password");
bt1=new Button("Login");
gbc.anchor=GridBagConstraints.NORTHWEST;
gbc.gridx=0;
gbc.gridy=0;
gl.setConstraints(lb1,gbc);
add(lb1,gbc);
gbc.gridx=1;
gbc.gridy=0;
gl.setConstraints(txt1,gbc);
add(txt1,gbc);
gbc.gridx=0;
gbc.gridy=1;
52
add(lb2,gbc);
gbc.gridx=1;
gbc.gridy=1;
add(txt2,gbc);
gbc.gridx=1;
gbc.gridy=2;
gl.setConstraints(bt1,gbc);
add(bt1,gbc);
txt2.setEchoChar('*');
bt1.addActionListener(new ActionListener()
{public void actionPerformed(ActionEvent e)
{processLogin();}});
addWindowListener(new WindowAdapter()
{public void windowClosing(WindowEvent e)
{System.exit(0);}});}
class creditentry extends Frame{
Connection cn;
Statement st;
ResultSet rs;
String flag,code,user;
Panel pnl1,pnl2;
TextField txt1,txt2,txt3,txt4,txt5;
List lst1,lst2,lst3,lst4,lst5;
53
TextArea txta;
Button bt1,bt2,bt3,bt4,bt5,bt6;
Label lb1,lb2,lb3,lb4,lb5,lb6,lb7,lb8,sp1,sp2,sp3,sp4,dv1,dv2;
GridBagLayout gl;
GridBagConstraints gbc;
creditentry(){
setTitle("Credit Card Entry");
setLayout(gl);
flag="";
code="";
pnl1=new Panel();
pnl2=new Panel();
lb1=new Label("Enter Card No.");
lb2=new Label("Enter Holder Name");
lb3=new Label("Enter Card CVV");
lb4=new Label("Enter Card Issue Month");
lst1=new List(1);
dv1=new Label("/");
lst2=new List(1);
lb5=new Label("Enter Card Expiry Month");
54
lst3=new List(1);
dv2=new Label("/");
lst4=new List(1);
lb6=new Label("Enter UserID");
lb7=new Label("Enter Password");
lb8=new Label("Bank");
lst5=new List(2);
txta=new TextArea(2,30);
sp1=new Label(" ");
sp2=new Label(" ");
sp3=new Label(" ");
sp4=new Label(" ");
bt1=new Button("Add");
bt2=new Button("Modify");
bt3=new Button("Delete");
bt4=new Button("Save");
bt5=new Button("Cancel");
bt6=new Button("Close");
class credittran extends Frame{
String user;
class tran extends Frame implements Runnable{
Connection cn;
Statement st;
55
ResultSet rs;
String user;
TextField txt1;
TextArea txtd,txta;
List lst1;
Button bt1,bt2;
Label lb1,lb2,lb3,sp1,sp2,sp3,sp4;
GridBagLayout gl;
GridBagConstraints gbc;
security sec;
tran(String usr){
user=usr;
setTitle("Credit Card Transaction");
setLayout(gl);
lb1=new Label("Transaction Amount.");
lb3=new Label("Transaction Type");
lst1=new List (1);
lb2=new Label("Transaction Desc.");
txtd=new TextArea(2,30);
txta=new TextArea(2,30);
sp1=new Label(" ");
sp2=new Label(" ");
56
sp3=new Label(" ");
sp4=new Label(" ");
bt1=new Button("Add");
bt2=new Button("Close");
lst1.add("WITHDRAW");
lst1.add("DEPOSIT");
gbc.anchor=GridBagConstraints.NORTHWEST;
gbc.gridx=0;
gbc.gridy=0;
add(lb1,gbc);
gbc.gridx=1;
gbc.gridy=0;
add(txt1,gbc);
gbc.gridx=0;
gbc.gridy=1;
add(lb3,gbc);
gbc.gridx=1;
gbc.gridy=1;
gl.setConstraints(lst1,gbc);
add(lst1,gbc);
gbc.gridx=0;
gbc.gridy=2;
57
add(lb2,gbc);
gbc.gridx=1;
gbc.gridy=2;
gl.setConstraints(txtd,gbc);
add(txtd,gbc);
gbc.gridx=0;
gbc.gridy=3;
gl.setConstraints(sp1,gbc);
add(sp1,gbc);
gbc.gridx=1;
gbc.gridy=3;
add(sp2,gbc);
gbc.gridx=0;
gbc.gridy=4;
add(bt1,gbc);
gbc.gridx=1;
gbc.gridy=4;
add(bt2,gbc);
gbc.gridx=0;
gbc.gridy=5;
58
add(sp3,gbc);
gbc.gridx=1;
gbc.gridy=5;
add(sp4,gbc);
gbc.gridx=1;
gbc.gridy=6;
gl.setConstraints(txta,gbc);
add(txta,gbc);
txta.setEditable(false);
bt1.addActionListener(new BT1());
bt2.addActionListener(new BT2());
setSize(400,250);
setVisible(true);
59

Final Report 5

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Final Report 5

Hochgeladen von

Copyright:

Verfügbare Formate

CREDIT CARD APPROVAL SYSTEM

1.2 How credit cars works

1.3 Credit Card Numbering

1.4 Features of credit card

Some of the features of credit cards are:

1.5 Transaction Steps

• World wide usage

• Interest cost 14%-15%person

2 Security Problems and Solutions

The low security of the credit card system presents

The goal of the credit card companies is not to

2.1 Over limit charges

2.2 Credit Card Fraud

2.2.1 Overview of Real-time Fraud Detection and Prevention

SOFTWARE DEVELOPMENT LIFE

3 SOFTWARE DEVELOPMENT LIFE CYCLE

1.System Requirements Analysis

Software development activities:

3.2 Requirement Analysis:

System analysis is conducted with the following objectives in mind:

understanding of software requirement is essential to the success of a software development

3.3.1 Identification of need

3.3.2 Preliminary Investigation:

3.4 FEASIBILTY STUDY:

3.4.1 Technology and system feasibility:

3.4.2 Economic feasibility:

3.4.3 Legal feasibility:

3.4.4 Operational feasibility:

3.4.5 Schedule feasibility

3.4.6 Market and real estate feasibility:

3.4.7 Resource feasibility:

3.4.8 Cultural feasibility:

• Introduction of different stages in the design process.

• Understanding whether an Object Oriented or a Functional Oriented approach or both

• Determining and improving, cohesion control and coupling within subsystems.

4.2 Flow Chart

Represented as a diamond (rhombus). These typically contain a Yes/No question or True/False

• A Document represented as a rectangle with a wavy base;

4.2.1 Flow Chart For Admin

21 Click to the card

Correct Check user Incorrect

View the entry in

Fig 4.2.2 Flow Chart for User

4.3 Data Flow Diagram [D F D]

5) A data flow must be attached to atleast one process.

Primitive Symbols Used For Constructing D F D

External Entity Symbol

Data Flow Symbol

Data Store Symbol

Developing A Data Flow Diagram

2)The system is “decomposed in lower level D F D (“decomposed in lower level D F D ( level 1)

Event Partitioning Approach

2) The list of all events is made.

3) For each event a process is constructed.

Context Level Diagram OR Zero Level D F D

4.3.1 0-Level DFD For Admin Module

Filling entries approved data saved in

4.3.2 1- Level DFD For Admin Module

Enter the data Process (1.1)

4.3.3 0- Level DFD For User Module

Enter information info is correct

Fig 4.3.3 DFD Level 0 For User

4.3.4 1- Level DFD For User Module