SE 3100 - Software Practices

Covers essential components of the software development life cycle, including requirements elicitation and prioritization; software development process, including methodologies, planning, estimation, and team organization; and software design, which explores the fundamental principles and architectural and design patterns essential to the production of quality software.

Learning Outcomes

At the successful conclusion of this course, students will be able to:

• Implement methodologies to facilitate the planning, estimation, risk analysis and team organization present in an effective software development life cycle.
• Elicit, define, prioritize, and validate the functional and nonfunctional requirements of a complex software system.
• Design software and related components while considering the design principles, architectural patterns, and design patterns necessary to produce quality software.

Project Title: Credit Card Clearinghouse

Developer Name: Alex Cutler

Project Requirements

Business Context

The credit card processing business is focused on facilitating communication between merchants (where people are buying things) and banks (where people's money is). Digital interaction between banks and merchants is not particularly complex, but does require security, efficiency, resilience and the ability to process a very large number of transactions. The credit card clearinghouse is designed to simplify the connectivity between merchants and banks by exposing a simple and clearly defined API for merchants to call that abstracts away the details of connecting to individual banks. The clearinghouse will then connect to the banks on behalf of the merchants to send the requests to them.

Problem Statement

Currently, banks have their own specific versions of APIs to handle transactions. If merchants had to know and connect to each of the banks on the bank's terms, this increases complexity and the likelihood for error. In addition, banks do not want to handle the problems related to connectivity. Connecting to millions of merchants is a task better suited to a centralized 'clearinghouse.' The business problem to be solved then, is connect to all the merchants, and connect to all the banks, and streamline the interaction between the two parties.

Scope

In scope for version 1.0:

• Connectivity between banks and merchants - initial version will simulate 100 merchants and 5 banks (US Bank, Wells Fargo, Citibank, Chase, Capital One).
• Banks have balances and will be used to process debit transactions.
• 3 credit card vendors (Visa, American Express, Mastercard) have 'credit limits' and will process credit transactions.

Out of scope for version 1.0:

• Bank to bank transactions
• ACH transactions (non-credit card sales)
• POS User Interface - the POS simulator needs no UI
• Support for disputes and refunds
• Fraud detection

Functional Requirements

1. Create an API that accepts a call from a merchant that includes a credit card and an amount to deduct for the purchase. Ensure that the Merchant is authorized to utilize the Clearinghouse. Get the bank from the submission, and then call the correct bank to make sure that the funds are available at the bank. Ensure that the credit card number is valid and that the purchase will not exceed the credit limit if it is a credit transaction.
2. If the transaction is successful, deduct the amount (or update the amount of credit used) and report success to the merchant.
3. If the transaction is unsuccessful, do nothing at the bank, and notify the merchant of the reason.
4. Create a merchant simulator that mimics a card swiped at POS and calls your API. The merchant collects or 'simulates' the following information:
   • CC#, expiration date, security code, billing zip, amount, merchant name, merchant ID, transaction date/time, user PIN, credit/debit, bank, card type (Visa, Mastercard, ...). Not all this information comes every time - it is specific to the card type.
5. The merchant (point of sale system) simulates authentication with the CH by passing a token (a secret shared between the merchant and the CH).
6. The merchant should keep a log of successful and unsuccessful transactions.
   • Merchant name, merchant ID, last 4 of card, amount, date/time, status (success, denied) - It does NOT store the credit card number (PCI laws).
7. Your merchant simulator should run and submit a certain number of transactions (make a certain number of calls) per minute.
8. Your CH API should be able to handle a large number of simultaneous calls.
9. CH saves a record of the transaction.
10. Call the right API for the bank. The bank has the following information:
    • Account Number
    • Balance
11. Simulate credit card companies. The credit card companies have the following information:
    • Account number (credit card number)
    • Credit limit
    • Amount of credit used
12. Support the following banks: Wells Fargo, Citibank, US Bank, Capital One, Chase
13. Support the following credit cards: American Express, Visa, Mastercard
14. I will create a set of APIs that represent banks and credit cards. Your will need to call these APIs as specified (detailed specs TBD).
15. The API that you create will accept a JSON object that is formatted like this:

myobject = {'bank': 'Chase', 'merchant_name': 'Petco', 'merchant_token': 'Za1reQlY', 'account_num': '12345', 'card_type': 'Debit', 'security_code': '123', 'amount': '2.00', 'card_zip': '84765', 'timestamp': '2025-01-21 15:45:30'};

It will be slightly different for the credit card type:

myobject = {'vendor': 'Visa', 'merchant_name': 'Harmons', 'merchant_token': 'BlT12343', 'account_num': '123456893', 'card_type': 'Credit', 'security_code': '889', 'amount': '9.00', 'card_zip': '84790', 'timestamp': '2025-01-21 14:45:29'};

Non-Functional Requirements

1. Scalability – Simulate up to 100 Merchants submitting simultaneously. You may need multiple computers to do this.
2. Create your Clearinghouse API in a way that scales automatically. (100's of merchants should not cause any trouble.) Be careful with this! If we’re using Amazon Web Services Free Tier, it may not cost things, but depending on how many transactions we try to send, it may suddenly skip into the ‘non-free tier’ We should avoid this. Ensure that cloudwatch is turned off.
3. Extensibility – The first version of this solution does not need to be extended in any way. We may want to be able to add ACH capability in the future, so we should not do anything that would make us only be able to use credit cards.
4. Responsiveness – The maximum “service level agreement” or SLA with the merchants is 3 seconds. The merchant should timeout and throw an error if the card clearinghouse does not respond within 3 seconds. Desirable response time is less than 1 second.
5. Availability – 24x7x365 (minimize downtime) 99.9% This may be very hard to achieve in the free tier. In real life we’d make this 99.999% up. But that would be really expensive. Maybe it would be a good exercise for us to determine how expensive it would actually be.
6. Security – We will not store PCI information at the clearinghouse. Obviously, our simulations (merchant and bank) will need to have and use fake credit card numbers. The credit card numbers actually follow an algorithm and have check-sums to ensure that they are valid visa or mastercard or american express numbers and we can check that and make sure our fake data meets those requirements. See this website: https://www.groundlabs.com/blog/anatomy-of-a-credit-card/#:~:text=The%20final%20digits%20of%20your,to%20validate%20primary%20account%20numbers
7. Authentication will be through the use of 'fake' tokens that we setup where each merchant will have a merchant name, a merchant id, and a token that will need to match at the clearinghouse. I will supply the list of merchants and tokens – that way we can all use the same data and our simulators will be interchangeable. When the merchant calls the API, they will pass the token. If the token is invalid the transaction is rejected.
8. Usability – this is a back end app - so users are API callers. We need good api documentation. Have some sample code so implementers would be able to call your API easily. Test out your documentation on your friends to make sure they can call your API.
9. Accessibility - Not in scope.
10. Supportability – In real life, we'd have a 24x7 help line staffed by people who could troubleshoot problems or help API clients to get setup.
11. Dependencies - We may need some Python libraries to do REST based HTTPS communications.