|
2 | 2 |
|
3 | 3 | ## Prerequisites |
4 | 4 |
|
5 | | -Install and configure the InStore app to execute payments (see main DevKit README for further details). |
| 5 | +Install and configure the **InStore app** to execute payments. For more information, see the [Development Kit README](https://github.com/fiskaltrust/possystemapi-devkit/blob/main/README.MD). |
6 | 6 |
|
7 | | -## What to expect when running this HOWTO |
| 7 | +## What to expect when running this How-To |
8 | 8 |
|
9 | | -All our howtos are reusing some code that is provided as a .NET Assembly/library in source and can be found in `../libPosSystemAPI/` directory. Please check it after trying out the HOWTOs to get a better understanding what it does under the hood and how it interacts with the POS System API. |
| 9 | +All How-To's reuse code provided as a .NET assembly/library in source, which can be found in the `../libPosSystemAPI/` directory. After trying out the How-To's, reviewing this code is recommended to gain a better understanding of how it works under the hood and how it interacts with the **POS System API**. |
10 | 10 |
|
11 | | -The HOWTO demonstrates |
| 11 | +This How-To demonstrates the following: |
12 | 12 |
|
13 | | -- initial credential reading and executing an `/echo` request to know if the fiskaltrust / POS System API backend is reachable (actually done by libPosSystemAPI) |
14 | | -- creates a `/pay` request with `action: payment` |
15 | | -- writes the result of that request to the console |
16 | | -- basic error handling (see next) |
| 13 | +- Initial credential reading and executing an `/echo` request to verify that the **fiskaltrust POS System API** backend is reachable (handled by `libPosSystemAPI`). |
| 14 | +- Creation of a `/pay` request with `action: payment`. |
| 15 | +- Writing the result of the request to the console. |
| 16 | +- Basic error handling as described in the following section. |
17 | 17 |
|
18 | 18 | ## Errors to be handled |
19 | 19 |
|
20 | | -There are multiple critical issues to be handled nicely to avoid double payments or the loss of a payment. |
| 20 | +Several critical error scenarios must be managed carefully to prevent double payments or loss of a payment. |
21 | 21 |
|
22 | | -### We were able to send the payment request but we were not able to receive the response |
| 22 | +**Example:** A payment request is successfully sent, but the response cannot be received. Possible causes include: |
23 | 23 |
|
24 | | -- Because we lost internet connectivity while waiting |
25 | | -- Because we could not get the response in time (= http timeout waiting for the response which can be simulated by a device on which the payment gets executed looses internet connectivity during operation) |
26 | | -- ? |
| 24 | +- Internet connectivity is lost while waiting for the response. |
| 25 | +- The response is not received within the expected time frame (HTTP timeout), which can be simulated by a device losing internet connectivity during payment execution. |
27 | 26 |
|
28 | | -In all cases the solution is to resend the original request (with identical operation ID and request body). The backend will then return the final result. |
| 27 | +In all of these cases, the solution is to resend the original request using the identical operation ID and request body. The backend will then return the final result of the operation. |
0 commit comments