Refund an order

curl -X PUT "https://test-api.kashier.io/v3/payment/refund/string" \  -H "Content-Type: application/json" \  -d '{    "apiOperation": "REFUND",    "reason": "Customer returned one item",    "transaction": {      "amount": 3    }  }'

{  "response": {},  "transactionId": "string",  "messages": {    "en": "string",    "ar": "string"  },  "status": "string",  "provider": {    "type": "string",    "version": "string"  }}

Repays your customer, in part or in full, from your available Kashier balance.

This is the same operation as PUT /v3/orders/{orderId} with apiOperation: REFUND, one hop closer. The checkout host (test-fep.kashier.io) applies no authentication of its own — it reads apiOperation, rewrites the path to this one, and forwards your request here unchanged, credential and all. So both routes end at the same enforcement point and behave identically; pick whichever fits your integration. If you already talk to the checkout host for payments, keep using PUT /v3/orders/{orderId} and let it route. If your refunds are issued from a back-office service that only knows the dashboard host, call this directly and skip the hop.

Send your secret key in the Authorization header. The key's role must carry the refund permission — a role that can read transactions but not refund them fails here with a 401, not a 403.

Refund outcomes: SUCCESS (the processor took it), PENDING (initiated, waiting on the processor), FAILURE (it could not be processed, and your account is credited back the refund amount). A refund cannot exceed the original transaction amount, and it draws on your available balance — pending balance does not count.

Path Parameters

The same body the checkout host forwards for a refund.

Response Body