Skip to content
b5510546140 edited this page Dec 15, 2014 · 2 revisions

Use Cases

1. Send a payment (Create a payment)

After customer decide to check out via ku paypal, client/merchant's website create a json data which contain order id, merchant email and total price to POST in our service. * Primary Actor: Merchant * Scope: Payment System * Level: Very High * Story: Merchant create a payment in service's system.

Scenario Create payment

Main Success Scenario and steps

1. Customer choose product from Merchant's website. 2. Customer place order and check out. 3. Merchant's website will send order id, merchant email, total amount to create payment in our service.

Precondition

Merchant email is exist in kupaypal system.(merchant have an account to validate a payment and get his/her money.)

Extensions

1. Total amount has negative value 2. Merchant have to resend his/her data to our service.

Trigger

Customer selects to checkout via "Ku paypal"

Guarantee

Merchant create a payment so customer can accept it.

2. Accept a payment (funds held wait for merchant validation)

After merchant's website create a payment. Customer want to pay that payment, customer just GET a acception path to accept a payment. * Primary Actor: Customer * Scope: Payment System * Level: Very High * Story: Customer accept a payment, service system hold his/her balance to wait merchant come and validate a payment.

Scenario Accept a payment

Main Success Scenario and steps

1. Customer retrieve a payment information from merchant's website e.g. list of item, total price. 2. Merchant's website redirect to payment acception page. 3. Customer accept a payment.

Precondition

Customer have an account in kupaypal system.

Guarantee

Customer accept a payment.

3. Validate a payment (funds tranferred)

After customer accept a payment, merchant come to kupaypal system and validate a payment to retrieve money. * Primary Actor: Merchant * Scope: Payment System * Level: Very High * Story: Merchant validate a payment and retrieve money to account.

Scenario Accept a payment

Main Success Scenario and steps

1. Merchant go to validate path (/payment/{id}/validate) to get validation page. 2. Merchant validate a payment.

Precondition

Customer already accept a payment.

Guarantee

Merchant validate a payment.

4. Reverse/chargeback a payment

If customer or merchant found that payment information is not correct or have a problem, they want to cancel/reverse this payment. * Primary Actor: Customer or Merchant * Scope: Payment System * Level: Low * Story: Some problem occured in a payment. Customer/merchant want to reverse/cancel a payment. They go and try to reverse/rollback a payment.

Scenario Charge back

Main Success Scenario and steps

1. Customer fullfill a cancel/reverse form in merchant's website. 2. Merchant GET cancel path to cancel/reverse a payment. 3. Customer and Merchant get chargeback amount.

Extensions

Admin of website do not permit to charge back

Trigger

Customer selects to cancel/reverse a payment. (depend on what merchant's website provided.)

Precondition

Payment already created.

Guarantee

Customer can get his/her money back.

5. User registration

User want to pay via this service, they need to register. * Primary Actor: Customer * Scope: Account Management * Level: High * Story: User want to become a member of the system.

Scenario Register

Main Success Scenario and steps

1. User provide email, password, first name, last name and address in registration form. 2. User selects "register".

Extensions

1a. E-mail is already in use .1 User need to change his/her email. 3a. The two passwords are different(use for password validation) .1 User retype his/her password

Trigger

User selects the "Sign Up".

Precondition

User is not logged in.

Guarantee

User becomes a registered user.

6. User Log In

Customer want to access the system. Customer can retrieve his/her profile and balance. * Primary Actor: Customer * Scope: Account management * Level: High * Story: Customer want to login to the system.

Scenario Login User

Main Sucess scenario

1. User provide his/her email and password. 2. User select "Sign In".

Extensions

2a. User provides invalid login parameter (see Login Failed)

Trigger

User selects the "Sign In". User access resource that need authentication.

Precondition

User does not login yet.

Guarantee

User can see his/her own information in paypal.

6. User Log In Failed

When customer want to accessto the system. * Primary Actor: Customer * Scope: Account management * Level: High * Story: Customer want to login to the system.

Scenario Login failed

Login Failed

Precondition

- The user provides invalid login parameters Precondition should be identical with the condition of the extension point

Main success scenario

1.System redirects the User to the Login page 2.System informs the User that he/she typed a non-registered user name

Login without Registration

Precondition

- The User typed a non-registered user name - Precondition should refine the precondition of Login Failed

Main success scenario

1. System redirects the User to the Login page 2. System informs the User that he/she typed a non-registered user name

Functional Requirement

1. Transaction history 2. Current balance for each user. 3. (Extra) Support multiple currency and multiple language