Fetching your Payment Receipt
Fetch a payment receipt to confirm the payment was successfully submitted to the bank.
Requirements
Fetch the receipt after the user completes the payment flow. Use the id returned in step 1 (or the flow_id from the callback URL).
GET https://api.finx-s.qwist.cloud/payment-receipts/{id}
Authorization: Basic {Base64(clientId:clientSecret)}
Response
{
"id": "3ca31c37-986a-454e-ad64-8e97143c86bc",
"debtor": {
"iban": "DE93300308800013441006"
},
"creditor": {
"iban": "DE93300308800013441006",
"name": "John Doe"
},
"amount": {
"value": 23.99,
"currency": "EUR"
},
"purpose": "Thanks for all the fish.",
"sepa_purpose_code": "GDDS",
"end_to_end_reference": "5B5U3FFS9EA2LS0O",
"submitted_at": "2026-06-04T21:18:20.358Z",
"type": "SEPA transfer"
}Field reference:
| Field | Description |
|---|---|
id | Unique receipt identifier. Matches the id from step 1 and flow_id from the callback. |
debtor.iban | IBAN of the user's account the payment was sent from. |
creditor.iban | IBAN of the recipient account. |
creditor.name | Name of the recipient. |
amount.value | Amount transferred. |
amount.currency | Currency code. |
purpose | Purpose text submitted with the payment. |
sepa_purpose_code | SEPA purpose code (e.g. GDDS = Goods sold). Present when provided at initiation. |
end_to_end_reference | End-to-end reference assigned to the transaction. Can be used for reconciliation. |
submitted_at | Timestamp when the payment was submitted to the bank's payment infrastructure. |
type | Payment rail used: "SEPA transfer" (standard) or "SEPA Instant transfer". Use this field to determine settlement speed. |
submitted_at reflects submission time, not settlement. For SEPA Instant transfer, settlement typically occurs within seconds. For SEPA transfer, settlement happens during the bank's next booking cycle, usually within a few hours on business days.
Important notes
1-hour availability windowThe payment receipt is only available for 1 hour after the payment is successfully submitted. Fetch it promptly after receiving the success callback. If you miss the window, there is no way to retrieve it.
Not a settlement confirmationThe receipt confirms the payment was submitted to the bank - not that funds have settled. For
SEPA transfer, the bank may still reject it during the booking process (e.g. insufficient funds). ForSEPA Instant transfer, rejections are returned faster but are still possible. Useend_to_end_referencefor downstream reconciliation.
404 while the flow is in progressThis endpoint returns
404while the user is still going through the Widget. This is expected - only poll after you receive the success callback.
Error handling
The nrich API uses standard HTTP status codes and returns a structured error object in the response body.
Error response structure
{
"error": {
"code": 1000,
"group": "client",
"description": "Request body doesn't match input schema.",
"data": {
"redirect_uri": ["Not a valid URL."]
}
}
}| Field | Description |
|---|---|
code | nrich-specific numeric error code. |
group | Error category: client, user, bank, general, or connectivity. |
description | Short human-readable summary. |
data | Field-level validation details (on 400 errors). |
HTTP status codes
| Code | Meaning | What to do |
|---|---|---|
200 OK | Success. | Parse the response body. |
400 Bad Request | Invalid or missing parameters. | Check error.data for the specific field. |
401 Unauthorized | Token missing or expired. | Refresh using your refresh_token and retry. |
403 Forbidden | Valid token, insufficient scope. | Verify your credentials have the required scopes. |
404 Not Found | Resource not found or not yet created. | Confirm the ID is correct; some resources only exist after the user completes the flow. |
423 Resource Locked | Resource temporarily locked during migration. | Retry with exponential backoff (seconds → minutes). |
500 Internal Server Error | Unexpected server error. | Retry with backoff; contact support if it persists. |
Implement 423 retry logic
423can occur after system updates. Your application must handle it with incremental backoff - do not surface it directly to users.
Common nrich error codes
| Code | Group | Description |
|---|---|---|
1000 | client | Invalid request - check data for field details |
1002 | client | Entity not found |
1008 | client | Resource busy - implement retry with backoff |
10000 | user | Login credentials are invalid |
10001 | user | PIN is invalid |
10004 | user | TAN is invalid |
10007 | user | PIN change required at the bank |
20000 | bank | Processing at the bank not possible |
20003 | bank | Bank under maintenance |
30000 | general | Processing at nrich not possible |
30005 | general | Task has expired |
40000 | connectivity | Bank not supported |
