Validate the selected capabilities on a prepared terminal. For payment and refund, perform end-to-end testing using a real payment card.
| Scenario | Expected result |
|---|---|
| Build and deploy | The correct SDK and required runtime files are included for the selected platform and architecture. |
| Cold start | Platform startup completes before discovery or business entry points are used. Required host objects remain available. |
| Required permission is unavailable | The application explains the unavailable capability and allows authorization or a supported configuration change. |
| Discover and select a terminal | The intended terminal is selected from the available results; the request reaches that terminal. |
| Restart the application | The selected strategy is restored, or the application offers the intended selection flow. |
| Switch or clear a terminal | Subsequent requests follow the new selection; obsolete remembered choices do not silently route them elsewhere. |
| Leave and reopen a screen | SDK startup is not repeated by each screen, and callbacks reach the active consumer without updating a closed screen. |
For integrations that include payment and refund, start with the following basic scenarios:
If possible, verify the transaction details on the payment terminal (e.g., in the acquiring application).
Make sure that key information—such as the transaction amount and reference data—matches the response received by your integrated application.
To ensure the robustness of your integration, you should also verify that the following scenarios are properly handled:
For each selected capability, verify its expected response and observable terminal behavior using the corresponding business guide and API reference. Record build checks separately from results observed on a real terminal. Use Error Codes, FAQ, and Developer Resources for diagnosis and supporting resources.
