Check Refund Availability
POST/api/v1/pbl/check-refund-availability
Check whether a transaction can be refunded (for the given amount) without actually executing the refund. Runs the same validations as the refund endpoint (transaction state, balance, refund window, available refund amount).
Checksum
Same mechanism as the refund endpoint: the server concatenates the values of all fields sent in the request body, in the order they appear in the JSON (excluding checksum), joined with |, with your Secret Hash appended at the end. Any optional field you send (e.g. value, reason) must be included in the checksum, otherwise the request is rejected with HTTP 401 Unauthorized request.
Business refusal codes
Besides 400, business refusals reuse the same body envelope (status/refund/message) with dedicated HTTP codes: 402 transaction not paid, 404 transaction does not exist, 406 insufficient balance to cover the refund, 409 a refund request has already been submitted, 410 transaction already refunded, 411 charge transactions cannot be refunded, and a business 401 for channels that do not support refunds. The authentication failure 401 is distinguishable by its exact message Unauthorized request. Treat any response carrying the refund key as an availability answer.
Request
Responses
- 200
- 400
- 401
- 402
- 410
Refund is available
Refund is not available (e.g. amount exceeds available refund amount)
Invalid checksum
Business refusal - transaction not paid. Same body envelope as 400: an availability answer, not an auth error.
Business refusal - transaction already refunded. Same body envelope as 400.