Use case: ProcessPaymentRequest
ID: UC-PPR
Brief description:
Customer attempts a payment on their Z-Flexi Card. Z-Server then invokes Z-Client to obtain the Customer’s selected payment method for a pending authorisation. The Customer chooses either to pay by card or by reward points. Z-Client relays this choice to Z-Server, which authorises the transaction, applies rounding rules, and updates both the credit and reward-points registers. If reward points are insufficient, Z-Server automatically splits the payment between reward points and card. Confirmation is sent by email via Z-Server.
Primary actors:
Z-Server
Secondary actors:
Customer
Preconditions:
1.	Z-Client and Z-Server are operational and can communicate.
2.	Customer is authenticated in Z-Client and securely prompted by Z-Server.
3.	Z-Server holds a pending transaction (merchant, amount, currency).
4.	Z-Client holds the latest local balances (available credit, reward points).
5.	This use case may be invoked directly or included from MakeReservation.
Main flow:
1.	The use case starts when a payment is attempted on the Z-Flexi Card.
2.	Z-Server invokes Z-Client with the pending transaction details and triggers a dialog to establish payment method.
3.	Z-Client displays the merchant and amount and prompts the Customer to select a payment method.
4.	The Customer selects either Pay by Card or Pay by Reward Points.
5.	Z-Client relays the selected method to Z-Server.
6.	Z-Server performs authorisation and applies the correct rules:
 6.1. If the method is Card, Z-Server increases the card balance by the transaction amount and increases reward points by the whole-pound value of the amount (rounding down).
 6.2. If the method is Reward Points, Z-Server deducts the rounded-up number of points required for the amount.
 6.3. If reward points are insufficient, Z-Server redeems all available points and charges the remaining balance to card, awarding points only on the card-charged portion.
    6.4. If the chargeable amount changes, re-prompt the Customer to confirm. On confirm continue, on cancel go to A2.
7.	Z-Server returns the result and new balances.
8.	Z-Client updates its local balances, displays the confirmation message, and Z-Server sends a confirmation email.
9.	Z-Client clears the session data and returns to the previous screen.

Postconditions:
1.	The transaction attempt has been fully processed and its outcome recorded by Z-Server.
2.	Z-Server and Z-Client hold consistent, synchronised reward-points and credit-balance registers.
3.	A confirmation or cancellation message has been displayed to the Customer.
4.	Z-Server has issued an email notification describing the outcome (approved, split, or declined).
5.	Temporary PPR state is cleared and Z-Client returns to the previous screen.

Alternative flows:
ProcessPaymentRequest:A1 – Insufficient Credit
1.	Triggered after step 6.1 when the Customer chooses Pay by Card and available credit is below the transaction amount.
2.	Z-Server reports “insufficient credit.”
3.	Z-Client informs the Customer and allows selection of Reward Points (return to step 3) or cancellation.
4.	Z-Server logs the outcome.
Postconditions: The system state satisfies all postconditions listed above.
ProcessPaymentRequest:A2 – Customer Cancels at Prompt
1.	Triggered at step 2 or 3 when the Customer cancels the dialog.
2.	Z-Client reports cancellation to Z-Server.
3.	Z-Server records a declined transaction.
Postconditions: The system state satisfies all postconditions listed above.
ProcessPaymentRequest:A3 – Amount Adjusted Before Confirm
1.	Triggered during step 5 when Z-Server returns a revised amount (e.g. tip or price change).
2.	Z-Client re-prompts the Customer and then continues from step 3.
Postconditions: The system state satisfies all postconditions listed above.

Notes on relationships:
•	MakeReservation «include» ProcessPaymentRequest