QA checklist
To ensure you have a smooth onboarding with face-to-face payments on your EPOS, Dojo has prepared a comprehensive testing checklist that you can follow before going live with your integration.
Configuration
These tests relate to how your EPOS is setup to interact with the Dojo API, taking into account authorization flow, user experience, and versioning.
| Scenario | Steps to Reproduce | Expected Outcome |
|---|---|---|
| Authorization | See where these details are configured. This might not need to be in the UI of the EPOS software itself, but it could be in a configuration file, a database elsewhere, or even in a back-office system that end-users log in to. Also, record who is expected to enter the Cloud credentials: yourself, an installer, or the merchant. | POS allows configuring different API Keys. The API Key should never be hard-coded. |
| Incorrect authorization credentials | Input an invalid API Key. | The EPOS should display an error prompting the user to check authentication credentials. |
| Retrieve terminal(s) | EPOS must be able to check for available terminals, preferably using the GET /terminals endpoint, or at a bare minimum offer the ability to manually enter the required TID. | POS should be able to check for available terminals or enable you to configure preferred TID. This should never be hard-coded. |
| API version | Note which version of the API you are testing | This data is to be provided during QA. |
| POS version | For our records, we prefer to keep a note of the minimum version of your POS which is compatible with this API - this allows us to track historic versions which may be incompatible. If this isn't providable (such as in the instance where only one version of the POS exists) then this step can be omitted. | Data to be provided during QA completion. |
Payment intents
These tests concern the creation of and management of payment intents, as well as additional features like itemLines and Webhooks.
| Scenario | Steps to Reproduce | Expected Outcome |
|---|---|---|
| [Create] Payment intent (Auto) | Initiate a sale using capture mode AUTO | Payment intent created successfully with the capture mode set to AUTO |
| [Create] Payment intent (Manual) [Optional] | Initiate a sale using captureMode: Manual | Payment intent created successfully with the capture mode set to Manual (Optional) |
| [Retrieve] Payment intent | GET /terminals the final result/transaction details from the Payment IntentsAPI after the terminal session has concluded. | The POS recognizes the status of the intent and records the sale on the POS |
| [Change] Payment intent amount [Optional] | Using the payment intent from a successful pre-authorization, use the POST /payment-intents/{paymentIntentId}/amount endpoint - This is before any pre-authorization or terminal session has taken place | Payment intent amount successfully updated |
| [Cancel] Payment intent [Optional] | Cancel a payment that has not yet been authorized by using DELETE /payment-intents/{paymentIntentId} | Payment intent is successfully cancelled |
| [List] All Payment intents [Optional] | List all payment intents by posting to POST /payment-intents/search. | |
| Create Payment intent - MOTO (CNP) | Initiate a transaction with cardHolderNotPresent set to true. | |
| itemLines | Use item lines to define checkout/bill items, and modifiers where applicable | Item lines should be correctly displayed and if discounts are present, these discounts should correctly display as modifiers. |
| Webhooks | Subscribe to Webhook events to be notified of specific events. |
[Auto] Create Terminal Session - Sale
These tests cover the sales flow of terminal sessions created using CaptureMode: Auto, meaning that the transaction will be completed immediately. We look to cover as many possible transaction outcomes, including less common but still crucial flows such as Expired and Signature Verification.
| Scenario | Steps to reproduce | Expected outcome |
|---|---|---|
| Create terminal session - Successful while inserting card | Complete a transaction by inserting a card and using PIN entry or by using a Virtual Machine with TID ending in SIP0. | Must display transaction status of Captured. |
| Create terminal session - Successful with cashback | Complete a transaction with cashback amount specified. | |
| Create terminal session - Successful with gratuity | Complete a transaction with gratuity amount specified. | |
| Create terminal session - Successful with contactless | Complete a transaction by presenting card to contactless reader or by using a Virtual Machine with TID ending in SCD0. | |
| Create terminal session - Successful with signature | Initiate a transaction by using a Virtual Machine with TID ending in SIP0. | POS should provide user with a dialogue box specifying that signature verification is required, and give the user an option to either accept or reject the signature. Selecting the accept option should send a PUT /terminals of accepted: true to the signature endpoint and lead to a successful payment. |
| Create terminal session - Successful with signature after 80 seconds | Initiate a transaction by using a Virtual Machine with TID ending in SIP0. At the status "SignatureVerificationRequired" the user should not select an option for 80s, allowing the sale to roll over to a successful state. The user should then either select to accept the signature, or the POS should gain the result from continued polling. Regardless, the status should be Captured. | POS should display result of Captured. |
| Create terminal session - Declined | Initiate a transaction by using a Virtual Machine with TID ending in DIP0. | POS should display status Declined. POS should re-use Payment Intent if transaction is re-attempted. |
| Create terminal session - Unsuccessful with signature rejection | Initiate a transaction by using a Virtual Machine with TID ending in SIP0. | POS should provide user with a dialogue box specifying that signature verification is required, and give the user an option to either accept or reject the signature. Selecting the accept option should send a PUT /terminals of accepted: false to the signature endpoint and lead to a declined payment. |
| Create terminal session - Successful with signature - rejection after 80 seconds | Initiate a transaction by using a Virtual Machine with TID ending in SIP0. At the status SignatureVerificationRequired the user should not select an option for 80s, allowing the sale to roll over to a successful state. The user should then either select to reject the signature, or the POS should gain the result from continued polling. Regardless, the status should be Captured. | POS should display result of Captured. |
| Create terminal session - Failure with busy terminal | Initiate a sale while PDQ is in menu. | POS should display that PDQ is not available. |
| Create terminal session - Cancel transaction from PDQ | Initiate a sale and cancel by selecting the X at the top of the PDQ screen before the card has been presented. | POS should display a result of Canceled. |
| Create terminal session - Cancel transaction from POS - Successful | Initiate a sale and cancel by sending a PUT /terminals to the cancel endpoint before the card has been presented. | POS should confirm status via polling and display a result of Canceled. |
| Create terminal session - Cancel transaction from POS - Unsuccessful | Initiate a sale and cancel by sending a PUT /terminals to the cancel endpoint after the card has been presented. | POS should confirm status via polling and transaction flow should be unaffected. |
| Create terminal session - Expired | Initiate a transaction by using a Virtual Machine with TID ending in TIP0. | POS should display a dialogue advising that the result of the transaction cannot be confirmed and provide an option to manually record the sale on the POS as successful or retry if unsuccessful. |
| Terminal session - polling rate | POS should call GET on terminal session regularly (once per second) to receive notificationEvents and TerminalSessionStatus updates | |
| Terminal session - display notifications | Terminal should display relevant notificationEvents and TerminalSessionStatus messages to the user to confirm the current state of the card machine. |
[Manual] Create Terminal Session - Preauth
These tests cover the sales flow of terminal sessions created using captureMode: Manual, meaning that the transactions will be pre-authorized and then captured subsequently. We will also look to cover behaviours such as incrementing the pre-authorized amount to ensure that the user experience is consistent.
| Scenario | Steps to Reproduce | Expected Outcome |
|---|---|---|
| Create terminal session - Successful with inserting card | Create a payment intent with capture mode set to manual. Create a terminal session and successfully authorize the payment using Chip and Pin or device verification. | |
| Create terminal session - Successful with contactless | Create a payment intent with capture mode set to manual. Create a terminal session and successfully authorize the payment using device verification. | |
| Create terminal session - Successful with different card type | ||
| Create terminal session - Unsuccessful | ||
| Update intent - Successful with increasing amount | Using the payment intent from a successful pre authorisation, use the "change payment intent amount" endpoint to increase the pre-authorized amount. | |
| Update intent - Unsuccessful amount change | Try to update a previously captured payment intent. | The POS would display the error returned from the Dojo API, such as Invalid request for payment with id pi_sandbox_EaaC8tw2fUKVVoSUt5JgJQ. The status Captured does not allow this change. |
| Update intent - Failure with non-existing payment intent id | Try to update an intent which does not exist. | The POS would ideally protect the user from this use case ever happening. |
| Update intent - Failure when updating amount to zero | Try to update an intent to an amount 0. | The POS would ideally protect the user from this use case ever happening. The POS would error with amount must be higher than 0. |
| Update intent - Failure when updating amount to current amount | Try to update an intent to the amount already defined. | Check expected behaviour. |
[Auto] Create Terminal Session - Refund
These tests cover the refund flow of terminal sessions created using captureMode: Auto, meaning that the refunds will be completed immediately.
| Create Terminal Session - Refund | Description / Steps |
|---|---|
| Create terminal session [Unlinked Refund - Successful] | |
| Create terminal session [Unlinked Refund - Declined] | |
| Create terminal session [Unlinked Refund - Expired] | |
| Create terminal session [Unlinked Refund - Cancelled] | |
| Create terminal session [Unlinked Refund - Signature verification pass] | |
| Create terminal session [Unlinked Refund - Signature verification fail] | |
| Create terminal session [Matched Refund - Successful] | |
| Create terminal session [Matched Refund - Declined] | |
| Create terminal session [Matched Refund - Expired] | |
| Create terminal session [Matched Refund - Cancelled] | |
| Create terminal session [Matched Refund - Signature verification pass] | |
| Create terminal session [Matched Refund - Signature verification fail] |
Error testing
These tests ensure that the POS is able to handle errors which will be returned from our API, ensuring that a valid error message and call to action is always displayed to the user.
| Error testing | Description / Steps |
|---|---|
| HTTP status code 400 - Bad Request | |
| HTTP status code 401 - Unauthorized | |
| HTTP status code 404 - Not found (TID unavailable) | |
| HTTP status code 422 - Unprocessable Entity |