AURORA’S TECHNOLOGICAL

AND RESEARCH INSTITUTE

(Parvathapur, Uppal, Hyderabad-98)

SOFTWARE ENGINEERING LAB

[Under the Guidance of Mr.AR. Sofi (Asst. Prof, Dept of CSE)]

B. Tech-III Year
(R18 Regulation)
Document By:-
M.ABHINAYA-19841A0582

V.TEJASWI-19841A0599

P.RAJITHA-19841A0591

S.NIKITHA-19841A0595

T.RAMYA-19841A05A0

BRANCH: COMPUTER SCIENCE AND ENGINEERING

 CREDIT CARD PROCESSING SYSTEM
SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT (SRS)
Aim: To create an Online platform to perform the credit card processing .

SOFTWARE REQUIREMENT SPECIFICATION

1) INTRODUCTION:
Credit card Processing is a series of operations required to complete payments made with
a credit card in person, online, over the phone or by mail.

Who are involved in Processing?

1. The card holder: Anyone who own a credit card.
2. Merchant: Business Owner who accepts credit & debit card.
3. The Payment Processor: The Institution that oversees credit card transactions and
payment processing.
4. Credit card Issuer: Bank that issues the card to the holder. These organizations
primarily establish the fee structure for the merchants, also called as ‘Interchange’.
5. Credit card Network: Cards like VISA, Master Card, Discover and AMEX.
 A Card holder pays through Credit/Debit card.
 The merchants process the card through a point-of-sale device or terminal, online
gateway or through a mobile app.
 This transaction goes through the network to the card issuing bank for approval.
 The payment processor enables data between the ,merchant and the credit card
issuer all while monitoring for any fraudulent activity on behalf of the merchant.
 Once the credit card issuer (Bank) sends an approval, the payment processor
receives an appropriate fund from the card issuer and the merchant gets paid,
usually within 24-48hours.

Selecting a Credit card processor:

 The costs of working with a Credit card processor.
 Credit card fraud protection and Security.
 Merchant Services
 Customer Support
 Additional services
1.1 PURPOSE:
By securely transmitting crucial information between issuing banks and acquiring banks
(merchants), to protect the sensitive data from fraudulent practices.

1.2 SCOPE:
 Automatically connects to your financial network or credit card authorization and
settlements.
 Time saving processing, rather than any manual work.
 Easy access to the data.
 Integrates with Sales Order, Accounts Receivable, e-Business Management.
1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS:
 User: One who uses the Credit card.
 HTML: Hyper Text Markup Language, used to create web pages at different stages.
 POS: Point Of Sale which includes a card reader to process debit/credit card
payments.
 TCP/IP: Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on internet.
1.4 REFERENCES:
IEEE Software Requirement Specification format.
1.5 OVERVIEW:
SRS includes two sections –overall description and specific requirements.

Overall Description: Describes major role of the system components and inter-
connections.

Specific Requirements: Describes role and functions of the Actors- “BANKER, CUSTOMER,
RETAILER”, etc.

EXISTING SYSTEM: As per the present system, the customer needs to visit the bank for
acquiring bank details which is troublesome.

PROPOSED SYSTEM: The proposed system is aimed at easing the process-that would be
effective in using and accessing every detail of bank easily.

2) OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE:
This solution involves signing up for a free Business Account. Once this is done and the e-
commerce site is properly configured, you can accept payments from Visa, MasterCard,
Amex, and Discover cards payments.
2.2 PRODUCT FUNCTIONS:
1. Accept credit card numbers on the web, store them in a database, then process them
offline

2. Credit card processing with CCP

3. Credit card processing with a third-party credit card processing company

2.3 USER CHARACTERISTICS:

1) User/Customer - They are the people who desires to purchase the goods using credit
card.

2) Authorization Service -

 Validate the credit card payments to ensure that the card number is valid and the
card has not expired
 Deposit processing to apply the deposit payment to the card
 Prepare Credit card transaction reports that show authorization codes, amounts,
and error/success messages.
2.4 CONSTRAINTS:
 Trusted if using a well-known third-party processor
 Must suite for higher-volume sites
 Cheaper transaction rates
 Getting money transferred may be very fast
 Must provide fraud prevention measures and fraud protection programs

2.5 ASSUMPTIONS AND DEPENDENCIES:

 The Applicants and Administrator must have basic knowledge of computers and
English Language.
 The applicants may be required to scan the documents and send.

3) EXTERNAL INTERFACE REQUIREMENTS

3.1 SOFTWARE INTERFACE:

• Front End Client - The applicant and Administrator online interface is built using JSP
and HTML. The Administrators's local interface is built using Java.

• Web Server - Glassfish application Server (SQL Corporation).

 • Back End - SQL database.

3.2 HARDWARE INTERFACE:

The server is directly connected to the client systems. The client systems have access to
the database in the server.

4) SYSTEM FEATURES:
1. Security:
When hackers steal personal information, suspicion isn't limited to credit card processors.
Customers often become skeptical of retailers themselves.

 Small business owners must protect customers, and themselves, by prioritizing

security.

 Today, most reputable credit card processors use a security feature called
tokenization. This process uses point-to-point encryption to conceal identifying
information. 

2. Reliable access to funds:

 Delays allow time for your credit card processor to verify information with the
customer's bank. This helps prevent fraud. Delays are often batched for greater
efficiency.
 Because these delays occur on the banking side, credit card processors have no
control over them. A processor that specifies a longer waiting period–or one that's
less than 24 hours–may not be telling the whole story.
3. User Friendly Interface:
Whether your customers shop in person, online or via mobile, they expect a frictionless
experience. Your credit card processor should keep things simple by providing an
instinctive interface. 
For online payments, user experience designers recommend:

 Sticking with short, simple phrases

 Confirming the payment amount
 Displaying visuals to show which cards are accepted
 Using a "MM/YY" expiration date format
 Including a zip code field to minimize fraud
 If you accept mobile payments, your processor should use design features such as:

 Technology that signal incorrectly entered information

 Incentive or loyalty reward features

4. Plenty of Payment Options:

Every customer has their own preferred payment method. Your credit card processor
should accept a wide range of payment options.

 . Your credit card processor should accept these options, along with standards like
Visa.
 By accepting a wide range of payment options, your credit card processor can help
keep things simple for customers.

5) UML DIAGRAMS
5.1 USE CASE DIAGRAM:
Credit card processing system use cases are:
1. Creating Account: Used to create an account.
2. Credit card request: Used to send the request to credit card.
3. Bank Enquiry: Used to get the bank enquiry like pin code to verify your user
account.
4. Issuing card: Used for issuing the card to machine.
5. Purchase the item: Used to list out the purchase details in shop.
6. Prepare the bill: Used to issuing the bill for the purchased item.
7. Paying bill: Used to transaction of money to paying the bill.

ACTORS INVOLVED:-

 Customer/user: The person who order for the item.

 Banker: The person to check the account details.
 Retailer: The person to preparing the bills.

USE-CASE NAMES:
PURCHASE PRODUCT: Customer purchases items from ecommerce site then
proceeds to the site’s secure checkout area. .
 AUTHORIZATION REQUEST: Credit card processor collects billing information
from the customer via a secure connection.

AUTHORIZATION RESPONSE: Billing information is verified and the transaction is

completed by the credit card issuer.

PAYMENT APPROVAL: The transaction details are recorded by the credit card
processor and results are securely relayed to the merchant. Merchant’s site receives
transaction result and does appropriate actions (e.g. saves the order & shows message).

Fig.1: Use-Case diagram for Credit card Processing System

5.2 CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis diagram.
The main task of object modeling is to graphically show what each object will do in the
problem domain. The problem domain describes the structure and the relationships among
objects.

The Credit Card Processing system class diagram consists of three classes. They are:-

1. Banker

2. Customer

3. Retailer

Fig.2: Class diagram

5.3 ACTIVITY DIAGRAM:

Activity diagrams are graphical representations of progressive activity routines.

 Choice, iteration, and concurrency are all supported through actions. Unified
Modeling is a term that refers to a method of modelling that is
 Activity diagrams can be used to describe the business and operational processes in
a step-by-step manner.
 Component workflows in a system An activity diagram depicts the total control
flow.
 An activity is represented by a circular box with the operation's name.
 The system's behaviour is depicted in this activity diagram.
 Fig.3: Activity Diagram

5.4 DATA FLOW DIAGRAM:

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where
data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a
part in the order that acts as a starting point for redesigning a system. The DFD is also
called as a data flow graph or bubble chart.
 Fig.4 (a): Zero-Level DFD

Fig.4 (b): Level-1 DFD

6) TEST CASES
Credit card processing test cases:-
 Check the valid card number, month and year;
3-digit CVV pin is valid or not.
 If any card details fail, it should throw an error message.

 If the credit card is valid one,

 Check for:
 Valid user(number)
 His/her last login(whether that falls within quota, the date after their bill was
sent)
 Balance amount that they can access from allowed card.

Proceed for transaction.

Processing fails for below conditions:

 Check with a invalid card number and

invalid CVV number past expiration month and year.
o Show error message for above conditions saying “invalid card”.
 The transaction will be declined when a card does not have enough balance
in their account.