Troubleshooting Invoicing

Invoice creation is made up of 2 requests:

• Store Transaction: Invoice details are specified in the JSON that is attached to a Store Transaction request.
• Confirm Transaction:

This document describes how an API client should handle other failures, such as server errors (HTTP 500's) or network failures. Approaches outlined in this document do not apply to cases when a response is received (such as HTTP 4xx).
In order to obtain an invoice in the V3 solution, two API calls need to be made:

1. A store transaction request2. A confirm transaction requestIn the first step, transaction is stored in the system. This step does not result in an invoice being issued. The second step, confirming a transaction stored in the previous step, causes the invoice number to be assigned and an invoice to be issued. Such confirmed transaction does appear in reports too, unlike an uncofirmed transaction.
   The two step nature of the transaction process is designed to make error recovery possible and unambiguous. Specifically, it is meant to resolve confusion in cases when the API client does not receive a response to the request it has issued, leading to a situation where the API client has no knowledge as to whether the request was handled or not by the V3 API.
   An unexpected failure can occur at the following points in time:

Store transactionShould the API client not receive a response to a store transaction request, it is safe to retry such request again. The are two possible scenarios here:

• the first request (to which response was not received) was not handled by V3. In this case the second request will be handled and one transaction will exist in the system. This is exactly the desired behavior.- the first request was actually handled by V3. In this case the second request will also be handled and two instances of otherwise almost identical transactions will exist in the system. However, the API client will have no knowledge of the first transaction, will not even have its key, and will not confirm it. Because no invoice are ever issued for non-confirmed transactions, the end result in this scenario will be only one invoice being issued (and one transaction being reported), which is an expected behavior.## Confirm transactionShould the API client not receive a response to the transaction confirm request, it's safe to simply retry this request again.
  The are again two possible scenarios as to what would've happen:
• the first confirm request (to which the response was never received) was not handled by V3. In such case the second request will confirm the transaction.- the first confirm request was handled by V3. In this case the second request is idempotent, meaning it does not change neither the transaction nor the invoice or reports. It's safe to retry the transaction confirm request multiple times.