WIP External Response Codes
Wallet initiated payment response codes and external response codes.
Wallet Response Codes — ECR Integration Guide
What to read, and what to expect, in the merchant callback and the get wallet status response.
Where to read the transaction status/result
In both scenarios (Merchant callback AND Wallet status) , read the root responseCode — this is the outcome of the wallet transaction.
- root
responseCode— the transaction result (see codes below). externalResponseCode— the underlying provider code (from Wallet Response codes).
Common responseCode values:
responseCode | Meaning |
|---|---|
0 | Successful |
1001 | Authorization declined |
1003 | Capture failed |
1005 | Authorization pending — not final yet, check again later |
1006 | Declined |
1012 | Insufficient funds |
1016 | Invalid amount |
2001 | Cancelled by consumer |
2003 | Cancelled by merchant |
10006 | No payment instruments found |
40007 | Forbidden – inconsistent data |
50000 | Internal error |
1005(pending) — the transaction is still in progress; poll status or wait for the callback.
See complete list here: PSP Response codes.
transactionDetails[] — per‑payment breakdown
transactionDetails[] — per‑payment breakdownBoth Merchant callback and Wallet status include transactionDetails[], with one entry per payment leg. A single payment has one entry; a hybrid payment (paid with more than one instrument) has one entry per instrument.
- Use it to see which instruments were used and information about each payment instrument.
- The
responseCode/externalResponseCodeinside each entry are raw provider codes (from Wallet Response codes ) and are not the same values as the rootresponseCode. Do not interpret them with the table above — treat them as informational only. The transaction result is always the rootresponseCode.
The get status response has two separate places that look like reflecting the transaction status. Read the correct one:
| Field | Tells you | Use it to… |
|---|---|---|
responseInfo.responseCode | Whether the status request itself worked (0 = ok, 50000 = lookup failed) | Decide whether the response is usable |
root responseCode | The transaction status/result | Decide the payment outcome |
responseInfo.responseCode = 0only means "we successfully looked up the status". It does not mean the payment succeeded.
{
"responseInfo": { "responseCode": "0" }, // lookup succeeded
"responseCode": "2001", // ← the transaction result (cancelled by consumer)
"externalResponseCode": "68606",
"pspReference": "...",
"merchantReference": "...",
"transactionDetails": [ ... ] // informational per-sub-transaction breakdown
...Sent from the PSP to the ECR when the transaction is complete (amount(s) authorized or rejected/failed).
- The transaction status/result is the root
responseCode(see table above). - There is no
responseInfo— the callback describes the transaction only, so read the rootresponseCodedirectly.
{
"responseCode": "2001", // ← the transaction result (cancelled by consumer)
"externalResponseCode": "68606",
"pspReference": "...",
"merchantReference": "...",
"transactionDetails": [ ... ] // informational per-sub-transaction breakdown
...In short
- Transaction status/result = root
responseCode. Always, in both responses. - The merchant callback has no
responseInfo; get status does — and thereresponseInfoonly tells you if the request was served, not the payment outcome. transactionDetails[]are a per‑sub-transaction breakdown (one entry for single‑instrument, more for hybrid); its codes are not PSP codes.1005means pending — not final.
Updated 1 day ago
