The bank terminal prints "VOIDED" or "DECLINED," and the sale in Torgsoft closes: how to check the payment result

During integrated card payment, Torgsoft sends the purchase amount to the bank POS terminal, receives the bank’s response and, after a successful transaction, records the cashless payment. Entrepreneurs contact specialists when the terminal prints «CANCELLED», «DECLINED» or another negative status while the sale in Torgsoft has already been closed; when the customer receives a debit notification but the software has not received the result; when Torgsoft displays the message «RRN not received»; or when it is unclear whether the payment can be started again. In such cases, the bank transaction, the payment in Torgsoft and the PECR fiscal receipt must be checked separately. A repeated payment should only be initiated after the result of the first transaction has been established.

How card payment works through Torgsoft

If the «Integration with a bank terminal» option is used, a regular sale proceeds as follows:

1. The cashier creates a sale in Torgsoft.

2. Selects cashless payment.

3. Torgsoft sends the amount to the POS terminal.

4. The customer taps a card or phone and confirms the transaction.

5. The terminal contacts the bank.

6. The bank returns the result.

7. The POS terminal sends the result to Torgsoft.

8. After successful authorisation, Torgsoft records the payment in the relevant settlement account.

9. If PECR is connected, the card transaction data may be included in the fiscal receipt. 

In a normal scenario, all three areas should correspond to each other:

A problem occurs when one of these stages ends differently.

What «CANCELLED» and «DECLINED» mean

The text on the bank terminal slip shows the result generated by the payment terminal.

«DECLINED» usually means that the bank or payment system did not approve the transaction.

«CANCELLED» may appear after a transaction is cancelled or when the terminal cannot complete the full technical exchange with the POS system.

Torgsoft also describes a separate scenario where, when working via RDP over an unstable connection, the terminal may print «CANCELLED». For such connections, the help documentation recommends using BPOS1 with confirmation waiting from the cash register and, where possible, connecting the terminal via Ethernet. 

The text on the slip should be taken into account, but if the indications conflict, the transaction should be checked in the terminal log or banking service.

Why a debit notification on the customer’s phone is not enough

The customer may show a push notification or SMS stating that the amount has been debited. This is useful information, but it should not be the only basis for the cashier’s decision.

A card transaction passes through several stages. The customer’s banking app may show an authorisation or amount reservation before the exchange between the bank, terminal and POS software has been fully completed.

Therefore, if:

• the phone shows a debit;

• the POS prints «CANCELLED»;

• Torgsoft shows a timeout,

the final status of the transaction itself must be established. The card should not be processed again immediately.

What RRN is and why it is needed

RRN — is an identifier of a bank transaction that the payment service may return together with the transaction result.

For example, in the monobank documentation, the response to a successful terminal transaction includes separately:

• status;

• responseCode;

• approvalCode;

• rrn;

• transaction identifiers;

• masked card number;

• date and time.

This clearly demonstrates the principle: RRN is one of the transaction details, while the result is determined by the combination of data received, including the status.

Therefore, the rule «If there is an RRN, the money has definitely been received» is incorrect.

RRN helps identify a transaction, process a refund and reconcile data with the bank. To confirm the final result, the transaction status and acquirer data must be checked.

Authorisation code, RRN and response code are different data

During a transaction, the terminal may return several service values. The authorisation code confirms a specific authorisation in the payment system. RRN is used to identify the transaction. The response code reports the result returned by the bank or terminal protocol.

The exact codes depend on:

• the bank;

• terminal model;

• protocol;

• payment service.

Therefore, a cashier does not need to memorise a table of numerical codes. If an unfamiliar code appears on the terminal, it should be checked against the documentation of the specific bank or through its technical support.

The most important rule for the cashier: do not repeat the payment before checking

If a transaction ends abnormally, the cashier should stop at the current sale.

Do not:

• press «Pay» again;

• ask the customer to tap the card again;

• create a second sale;

• manually change the payment type;

• release the goods based only on a notification from the customer’s banking app.

First, the status of the first transaction must be established.

Otherwise, the following scenario may occur:

1. the first card transaction is actually successful;

2. Torgsoft does not receive the response because the connection is lost;

3. the cashier starts a second payment;

4. the bank processes both transactions.

It is the second debit that must be avoided.

Step-by-step procedure if the POS shows «CANCELLED» or «DECLINED»

Do not throw away the terminal receipt.

Record:

• the amount;

• the date;

• the time;

• Merchant ID, if printed;

• terminal identifier;

• RRN;

• authorisation code;

• the transaction result code or text.

The set of details may differ between banks.

Check whether the current sale disappeared from the sales form and whether a financial payment was created. If Torgsoft left the sale unpaid, this is one scenario. If the sale has already been closed as cashless, the situation is different.

If Software ECR is used, open: Settings → Software ECR → Software ECR Analytics.

Check:

• whether a receipt was created;

• date and time;

• amount;

• payment method;

• bank transaction data.

Under the current requirements of the STS, when card payment is made through a terminal connected or integrated with an ECR/PECR, the fiscal receipt includes the acquirer details, terminal details, payment instrument details and a code identifying the transaction in the payment system. 

If the result remains unclear, the transaction must be checked on the bank’s side.

Depending on the terminal model and bank, this can be done:

• through the POS transaction log;

• using the last transaction check function;

• in the acquiring account;

• through the bank’s support service.

Provide the bank with:

• the amount;

• the time;

• Merchant ID;

• Terminal ID;

• RRN;

• authorisation code, if available.

After that, it can be determined whether the transaction was successful, declined or cancelled.

This is the simplest case.

For example:

• the POS printed «DECLINED»;

• Torgsoft did not close the sale;

• no PECR receipt was created;

• the bank confirms that the purchase did not take place.

After this, the customer may be asked to pay again:

• with the same card;

• with another card;

• using another payment method.

The new operation will be a separate bank transaction.

This is precisely the case in which the store owner later sees a discrepancy:

• Torgsoft shows a cashless sale;

• the goods were written off;

• the bank did not receive the money.

In Torgsoft version 2026.0.5, a separate scenario was fixed in which, after an unsuccessful terminal payment, the payment could still be linked to the account in «Trade with invoicing». Timeout control was also added for JSON WebSocket. 

If this situation has already occurred, two documents should be checked:

1. the payment in Torgsoft;

2. the PECR fiscal receipt.

If there is no fiscal receipt

The incorrect internal payment record must be cancelled and the sale returned to a state in which it can be paid correctly.

The specific action depends on the sales mode and document, so if the sale has already been closed, it is better not to delete related financial records at random.

If the fiscal receipt has already been registered

The fiscal transaction must also be corrected. You cannot simply delete the Torgsoft financial document and leave the fiscal receipt as a successful card payment.

First, check the shift status and the specific receipt, then use the provided cancellation or return scenario.

This is the reverse situation.

For example:

• the customer tapped the card;

• the bank confirmed the transaction;

• the terminal has a successful transaction;

• Torgsoft received a timeout;

• the sale remained unpaid.

The POS transaction should not be run again.

Torgsoft provides a scenario for manually entering the parameters of an already completed bank transaction.

If the bank terminal is temporarily not used through the integrated connection, «Use connection with bank terminal» can be disabled in the payment form. Torgsoft then opens the «Bank terminal payment parameters» form, where data from the slip can be entered.

This makes it possible to:

• avoid sending a second purchase command to the POS;

• record the existing payment in Torgsoft;

• send the card transaction details to the PECR if the relevant settings are enabled.

Before doing this, make sure that the bank has actually confirmed the first transaction.

This is a conflicting result. In such a case, the cashier should not independently decide what matters more: the paper slip or the customer’s notification. The transaction must be checked with the acquirer using its details.

If the bank confirms that the transaction was successful and was not cancelled, proceed as with an already completed bank payment: do not start a second transaction and correctly complete the sale in Torgsoft.

If the bank confirms that the transaction was cancelled or declined, no card payment should remain in the records.

Does the presence of an RRN mean the payment can be considered successful

No. RRN is very important for finding the transaction, but by itself it does not replace its status.

For example, modern bank APIs return separately:

• status;

• RRN;

• authorisation code;

• response code.

Therefore, the final transaction status must be checked first, while the RRN is used for identification and reconciliation. 

Why Torgsoft may display «RRN not received»

The reason depends on the terminal and the bank library.

The official Torgsoft page states that for some Verifone terminals, including X990, the bank library may not send the RRN automatically. In this case, the authorisation code from the receipt may be used for a refund. 

Therefore, a missing RRN message does not always mean that the purchase did not take place in the bank. The bank status must be checked.

Why it is important to keep terminal data

Torgsoft also uses the details of the original card transaction for subsequent operations.

For example, when processing a refund, the software may use the original transaction details to return money specifically for the relevant payment. The official option page also states that Torgsoft records payment data and uses it to refund money to the card or original payment transaction. 

Version 2026.0.5 also separately fixed the transfer of RRN, PAN and other terminal parameters to the financial document when paying for an order. 

Why such situations occur when working via RDP

With a terminal setup, Torgsoft may run on a remote server while the physical POS is located next to the cashier.

If the POS is connected locally via COM/USB and the data is forwarded to the remote session via RDP, an additional communication channel appears in the setup.

The Torgsoft help documentation explicitly states that unstable RDP may cause:

• «Error No. 3»;

• connection problems;

• printing of a «CANCELLED» receipt.

For BPOS, the official Torgsoft documentation recommends:

• BPOS1 with waiting for confirmation from the cash register;

• Ethernet connection of the terminal. 

This reduces dependence of the payment exchange on COM/USB redirection through a remote session.

Why the terminal needs confirmation from the cash register

Some protocols provide for a final exchange between the POS and the POS software.

The Torgsoft BPOS settings include:

• «Use cash register confirmation»;

• «Ignore cash register confirmation».

The help documentation explains that the second parameter may be used when working via RDP in the corresponding configuration, when payment is completed on the POS but the result does not reach Torgsoft.

These parameters should not be changed by the cashier during work. The settings must match the terminal protocol and bank configuration.

Timeout: why Torgsoft may stop waiting for a response

A bank transaction takes a certain amount of time:

• the customer taps the card;

• enters the PIN;

• the bank processes the request;

• the terminal receives the response;

• the data is returned to Torgsoft.

If the connection is lost at the final stage, the bank and Torgsoft may have different views of the transaction status.

In version 2026.0.5, JSON WebSocket received timeout control for waiting for the response and the ability to configure its value. A separate terminal operation log is also created and can be used during diagnostics. 

Therefore, if timeouts recur, check:

• the Torgsoft version;

• POS protocol;

• network;

• timeout;

• terminal logs;

• bank equipment settings.

What to do if the cashier accidentally cancelled waiting

If the software was still waiting for a POS response and the cashier interrupted the process, the result of the bank transaction may remain undefined for Torgsoft.

The same rule applies: do not start a new payment until the previous one has been checked.

First:

1. check the slip;

2. check the POS log;

3. find the transaction in the bank;

4. check the sale in Torgsoft;

5. check the PECR.

Only then determine the next action.

How to check the fiscal receipt after card payment

Under the current Regulation on the form of settlement documents, when a card POS connected or integrated with an ECR/PECR is used, the fiscal receipt contains a block of payment details.

These include:

• acquirer and merchant identifier;

• payment device identifier;

• type of transaction;

• electronic payment instrument details;

• payment system;

• authorisation code or another transaction identifier;

• payment method. 

Therefore, after a conflicting POS transaction, the fiscal receipt is another source for reconciliation, but it shows what was transmitted to the PECR. The final bank status must be checked with the acquirer.

The POS slip and PECR fiscal receipt serve different purposes

The POS slip describes the payment transaction. The fiscal receipt describes the settlement transaction for the sale. Therefore, in the event of a technical failure, it is entirely possible for one document to exist while the other does not.

That is why both must be checked during diagnostics.

If Torgsoft has already created an incorrect payment

Do not compensate for it using:

• a cash order;

• a service deposit;

• a service withdrawal;

• a second card transaction.

First establish the correct status of the bank transaction. After that, correct the related financial document or sale according to the relevant scenario.

If the transaction has already been fiscalised, the PECR must be checked separately.

If one terminal works with several Sole Proprietorships

If the result is conflicting, Merchant ID must also be checked.

In Torgsoft, the connection must correspond to the following scheme: Merchant ID → settlement account → Sole Proprietorship. An incorrect merchant may cause the payment to go to another entrepreneur or prevent a refund from finding the original transaction. 

After a test payment, it is advisable to check the Merchant ID on the terminal receipt and the bank statement.

How to organise cashier work

One short rule is enough for the cashier: if the terminal does not provide an unambiguous successful result, do not release the goods and do not restart the payment until the first transaction has been checked.

The internal instruction may include the following actions:

1. Do not press «Pay» a second time.

2. Keep the POS slip.

3. Check the sale status in Torgsoft.

4. Check the PECR.

5. Check the bank transaction.

6. If the bank confirms success — complete the accounting of the already completed payment without a new request to the POS.

7. If the bank confirms the decline — repeat the payment as a new transaction.

8. If Torgsoft and the bank show different results — pass the data to the administrator or technical support.

What the owner should check if the situation recurs

If the situation occurs regularly, the issue is no longer limited to a single sale.

Check:

• the current Torgsoft version;

• POS model;

• bank;

• connection protocol;

• COM/USB, Ethernet or Wi-Fi;

• RDP usage;

• cash register confirmation settings;

• timeout;

• Merchant ID;

• settlement account;

• Sole Proprietorship;

• terminal operation log.

For JSON WebSocket, Torgsoft 2026.0.5 added separate timeout control, and separate scenarios for linking financial documents after unsuccessful payments were fixed. 

Short procedure: can a card payment be repeated

The main rule for such cases: the result of a card payment is determined by the status of the bank transaction, while the RRN, authorisation code, slip, Torgsoft financial document and PECR receipt are used to identify and reconcile it. If the results differ, the cashier first establishes the status of the first transaction and only then repeats the payment or corrects the documents.