Post-Session Checklist

This overview details procedures for testing terminal User flows including state monitoring, screen interactions, and complete transaction processes, ensuring the system accurately handles state changes, user inputs, and transactional operations efficiently and reliably.

Objective	Steps to follow
Validate the system's ability to subscribe and receive terminal state changes.	Step 1: Subscribe state webhook. CPS Host System Action: Send subscription request for terminal state changes. Expected Result: HTTP OK response received. Step 2: Disconnect terminal. CPS Host System Action: Physically disconnect the terminal or simulate a disconnection. Expected Result: Webhook is called with status offline. Step 3: Connect terminal. CPS Host System Action: Reconnect the terminal or simulate reconnection. Expected Result: Webhook is called with status online.
Test the terminal's idle/start screen functionality	Step 1: Display the idle/start screen (ui command). CPS Host System Action: Send command to display the idle/start screen. Expected Result: Terminal displays idle screen. Step 2: Press the start button. CPS Host System Action: Simulate pressing the start button, triggering the start command. Expected Result: Callback URL is called; Terminal shows present card screen. Step 3: Wait for the card timeout to expire. CPS Host System Action: Do not present a card and wait for the session to timeout. Expected Result: Terminal displays idle screen again.
Execute a complete transaction flow including authorization and commit.	Step 1: Start a session (start command). CPS Host System Action: Send command to start a new session. Expected Result: Terminal displays the present card screen. Step 2: Present a card. CPS Host System Action: Simulate card presentation and then proceed to authorize the transaction if no active session exists for the card. Expected Result: Terminal displays authorizing; Callback URL is called or response is given with Transaction ID and Session ID. Step 3: Optional dispense message display. CPS Host System Action: Optionally, display a message or selection screen for the user. Expected Result: Terminal displays dispense screen. Step 4: Start charging/dispense product. CPS Host System Action: Begin the charging process or dispense the product as applicable. Expected Result: Charging is started/product dispensed. Step 5: Return to initial state. CPS Host System Action: Transition the terminal back to its initial state after the transaction. Expected Result: Terminal displays the start/idle screen or the present card screen. Step 6: Commit session (commit command). CPS Host System Action: Send command to commit the session. Expected Result: Session is successfully committed.
Handle a scenario where charging fails after authorization.	Step 1-4: Repeat steps 1-4 from previous test case with the same CPS host system actions and expected results. Step 5: Cancel session (cancel command). CPS Host System Action: Send command to cancel the session. Expected Result: Cancel result is given; Session successfully canceled.
Test the system's response to a declined transaction.	Step 1: Start a session (start command). CPS Host System Action: Trigger a session start with a predefined amount known to cause a decline. Expected Result: Terminal displays the present card screen. Step 2: Present a card. CPS Host System Action: Simulate card presentation and proceed to authorize, expecting a decline. Expected Result: Terminal displays authorizing; Transaction is declined. Step 3: Wait for authorization result. CPS Host System Action: Await the result of the authorization attempt. Expected Result: No charging/product dispensing; Terminal returns to initial state. Step 4: Return to initial state. CPS Host System Action: Ensure the terminal is ready for a new transaction or idle. Expected Result: Terminal displays the start/idle screen or the present card screen.