EX.

NO:

DATE:
CREDIT CARD PROCESSING SYSTEMS

OBJECT ORIENTED ANALYSIS

INTRODUCTION:

Credit Card Processing is an interface between the customer and the system administrator. It
aims at introducing an automated system for purchase and payment. This software will make
transactions like issue of purchase code, reciepts easier, and hassle – free.

OBJECTIVES:

The objective of this software is similar to Credit card processing installed in online. It
should first validate the transaction id of the credit card. Then the type of transaction is enquired
and the information from the customer is validated. After the money is delivered the transaction
just made is updated in the database where the customer’s information is stored.

SCOPE:

• The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning).
• This system provides communication platform between the customer and the system.

• This system eliminates the use of long human processing

PROBLEM STATEMENT :

Credit Card Processing is used in the effective dispatch of product to all of the applicants. This
system adopts a comprehensive approach to minimize the manual work and schedule resources,
time in a cogent manner. The core of the system is to get the online purchase form (with details
such as product_code, price etc.,) filled by the applicant. This credit card processing should be
user friendly and not confusing. Help manuals should be provided in case any customer has
problem working with the software. It should provide easy access to the data for the customer. It
should also have a highly secure interface so that one can take money one behalf of others. So
the security is one of the main aspects in credit card process.
PROBLEM STATEMENT( USE CASE ANALYSIS) :

Identified Use cases :

a) Login ID:

Here the user enters the card and password to enter into the main form. If the
password is correct the system will display the next form.

b) get prod_details:

Allows the user to get the product details.

c) select products:

Allows the user to select the particular product to be purchased.

d) enter cust_details:

Enter the customer details to verify by the systems.

e) Verify:

It is used to verify the details given by the user.

Identified Actors:

a) Customer:

He is the external user of the Credit card processing system for purchasing products
and payment also.

b) SystemAdmin:

System administrator plays an important role. He is the system designer. All the
updating works is done by him only like adding, deleting customer accounts.
Issue of purchase code :

USE CASE DIAGRAM :

login_id

get prod_details

select products
customer system

enter cust_detail

verify

issue purchase_code
SEQUENCE DIAGRAM:

customer system

login_id

get prod_details

select product

enter cust_id

verify

issue purchase_code

COLLABORATION DIAGRAM :

5: verify
1: login_id
2: get prod_details
3: s elec t produc t
4: enter c us t_id
c us tom er s y s tem

6: is s ue purchas e_c ode

ACTIVITY DIAGRAM :

start

login_account

get prod_detail

select product

enter
cust_detail

valid verify details invalid

issue reject
purchase_code

merge

stop
CASH PAYMENT :

USE CASE DIAGRAM :

enter purchase_code

request for payment

select pay_mode

enter card_no
customer system

verify detail

enter amount

enter trans_id

verify payment

issue receipt
SEQUENCE DIAGRAM:

System Customer

enter purchase_code

select pay_mode

enter card_no

verify detail

enter amount

give transaction_id

verify detail

issue receipt
COLLABORATION DIAGRAM :

4: verify detail
7: verify detail

8: issue receipt
System Customer

1:enter purchase_code
2: select pay_mode
3: enter card_no
5: enter amount
6: give transaction_id
ACTIVITY DIAGRAM :

start

enter
purchase_code

select
payment_mode

enter card_no

valid verify details invalid

enter amount reject

give trans_id

issue receipt valid verify details invalid reject receipt

merge

stop
 OBJECT ORIENTED DESIGN

Class diagram for Issue of Purchase Code :

Customer
System
name
name
address
license
cust_id
issue prod_details()
request prod_detail()
verify_detail()
select product()
issue purchase_code()
issue details()

Class diagram for Cash Payment:

Customer
System
name
name
login_id
license
card_no
give detailt()
give amount()
verify_payment()
give_trans_id()
issue receipt()
request receipt()
 UNIFED PROCESS IMPLEMENTATION

:
CODING:

CREDIT CARD PROCESSING FORM:

Private Sub Command1_Click()

Form1.Show
End Sub
Private Sub Command2_Click()
Form2.Show
End Sub
Private Sub Command3_Click()
Form4.Show
End Sub
CREDIT CARD ATM AMOUNT FORM:

Private Sub Command1_Click()

Text4.Text = Val(Text1.Text) - Val(Text2.Text)
Text1.Text = Text4.Text
MsgBox "your validity is " + Text3.Text + " days"
End Sub
Private Sub Command2_Click()
End
End Sub
Private Sub Command3_Click()
Form3.Show
Me.Hide
End Sub

CREDIT AMOUNT FORM:

Private Sub Command1_Click()

MsgBox "you have to pay amount with in " + Text2.Text + "days"
End Sub
Private Sub Command2_Click()
End
End Sub
Private Sub Command3_Click()
Form3.Show
Me.Hide
End Sub
PAY AMOUNT FORM:

Private Sub Command1_Click()

Text3.Text = Val(Text1.Text) + Val(Text2.Text)
Text1.Text = Text3.Text

MsgBox "your total credit availabe is " + Text1.Text + ""

End Sub
Private Sub Command2_Click()
End
End Sub
Private Sub Command3_Click()
Form3.Show
Me.Hide
End Sub

TESTING

SOFTWARE TESTING:

Testing is a process of executing a program with the interest of finding an error. A good test is
one that has high probability of finding the yet undiscovered error. Testing should systematically
uncover different classes of errors in a minimum amount of time with a minimum amount of
efforts. Two classes of inputs are provided to test the process

1. A software configuration that includes a software requirement specification, a design

specification and source code.
2. A software configuration that includes a test plan and procedure, any testing tool and
test cases and their expected results.
Testing is divided into several distinct operations:

1.UNIT TESTING:

Unit test comprises of a set tests performed by an individual program prior to the
integration of the unit into large system. A program unit is usually the smallest free functioning
part of the whole system. Module unit testing should be as exhaustive as possible to ensure that
each representation handled by each module has been tested. All the units that makeup the
system must be tested independently to ensure that they work as required.
During unit testing some errors were raised and all of them were rectified and handled well. The
result was quiet satisfactory and it worked well.

2.INTEGRATION TESTING:

Integration testing is a system technique for constructing the program structure

while at the same time conducting tests to uncover errors associated with interfacing. The
objective is to take unit tested modules and build a program structure that has been dictated by
design. Bottom-up integration is the traditional strategy used to integrate the components of a
software system into functioning whole. Bottom-up integration consists of unit test followed by
testing of the entire system. A sub-system consists of several modules that communicated with
other defined interface.

The system was done the integration testing. All the modules were tested for their
compatibility with other modules .They test was almost successful. All the modules coexisted
very well, with almost no bugs. All the modules were encapsulated very well so as to not hamper
the execution of other modules.

3.VALIDATION TESTING:

After validation testing, software is completely assembled as a package,

interfacing errors that have been uncovered and corrected and the final series of software test; the
validation test begins. Steps taken during software design and testing can greatly improve the
probability of successful integration in the larger system. System testing is actually a series of
different tests whose primary purpose is to fully exercise the compute -based system.

4.RECOVERY TESTING:

It is a system that forces the software to fail in a variety of ways and verifies
that the recovery is properly performed.

5.SECURITY TESTING:

It attempts to verify that protection mechanisms built into a system will in fact
protect it from improper penetration. The system's security must of course be tested from in
vulnerability form frontal attack.
6.STRESS TESTING:

Stress tools are designed to confront programs with abnormal situations. Stress
testing executes a system in a manner that demands resources in abnormal quantity and volume.

7.BLACK BOX TESTING:

Black box testing is done to find out the following information as shown in
below:

1. Incorrect or missing functions.

2. Interface errors.
3. Errors or database access.
4. Performance error.
5. Termination error.

The mentioned testing is carried out successfully for this application

according to the user's requirement specification.

8.TEST DATA OUTPUT:

After preparing test data, the system under study is tested using the test data.
While testing the system using test data, errors are again uncovered and corrected by using above
testing and corrections are also noted for future use.