Scenario 2. Cancel payment
Koshelek Pay API
Documentation has moved
The information on this page is no longer updated and may be obsolete. The most current Koshelek documentation is now available at the new address:
Cancel payment: basic flow
This scenario explains the Koshelek API message flow when payment transaction cancellation is initiated at the cash desk.
Note that this scenario is effective until the receipt slip is received. For completed transactions, opt for the refund operation as described in Scenario 3. Refund payment.
Examples of transaction cancellation decline messages for refTransactionId
:
Transaction status | Transaction cancellation decline message |
---|---|
Canceled |
|
Accepted |
|
Any Refund status |
Please note: Although considered here, this case is not likely to occur as there is no "Cancel" button provided for payment transactions. The "Refund" status for transaction implies that the refund operation is ongoing or done, and the fact of payment is genuinely known. |
Transaction not found |
|
Message wording is shown as an example of possible reasons of transaction cancellation decline and is subject to change.
Payment cancellation may be initiated:
automatically;
by request from cash desk operator;
by request from customer.
Cancel initiated automatically
Payment cancellation must be called automatically by cash desk software in the following cases.
If X payment request retries (number must be configurable) return no response, then cash desk software must initiate automatic payment cancellation.
If cash desk software does not receive positive transaction status within X seconds (number must be configurable), then cash desk software must initiate automatic payment cancellation.
If X refund request retries (number must be configurable) return no response, then cash desk software must initiate automatic payment cancellation.
Cancel initiated by cash desk operator
Payment cancellation must be called by cash desk operator in the following cases.
Cancel after customer confirmation with subsequent payment transaction retry
In this case, cash desk software must not prompt for loyalty card re-scan. New request must contain:
Old
cardSession
(i.e. obtained on previous card scan)New
requestId
Cancel before customer confirmation with subsequent payment transaction retry
In this case, cash desk software must prompt for loyalty card re-scan. New reqeust must contain:
New
cardSession
(obtained on card re-scan)New
requestId
Cancel initiated by customer
Customer is unable to invoke payment cancellation in the Koshelek App — this is managed in communication with cash desk operator.
Last updated