# Refund Rejection

This endpoint enables merchant to formally reject customer refund requests initiated through the Keeta platform.


1. When a customer submits a refund request on the Keeta platform, the system will send a  to the third-party system.
2. If the third-party system has implemented refund processing capabilities, merchants can review and evaluate customer refund requests directly within their own system endpoint.
3. When merchants decide to reject a refund request after careful consideration, the third-party system must explicitly call this rejection API endpoint to formally communicate the decision to Keeta's platform.
4. This API . If the refund has already been approved or rejected (e.g., via Keeta POS), subsequent calls will return an error.


Endpoint: POST /order/reject
Version: v.1.0.0

## Request fields (application/json):

  - `orderViewId` (integer, required)
    Unique identifier for orders on Keeta platform
    Example: 756823555555859

  - `shopId` (integer, required)
    Unique identifier of the Keeta store
    Example: 466663

  - `rejectCode` (integer, required)
    Reason code for refund rejection:

100000: indicates other unspecified reasons

100001: indicates meal preparation already completed

100002: indicates delivery process already initiated
    Enum: 100000, 100001, 100002

  - `rejectReason` (string)
    The rejectReason field contains the merchant's textual explanation for refusing a refund request. This provides transparency to customers about the rejection decision.

When Using Custom Rejection Code (100000), The rejectReason field becomes mandatory.

For rejectCode = 100001 (meal already prepared) or 100002 (delivery already started), The rejectReason field is optional.
    Example: "Your Reason"

## Response 200 fields (application/json):

  - `code` (integer, required)
    A numeric status identifier indicating the result of the interface call, used to determine whether the operation executed successfully.

  - `message` (string, required)
    Text description corresponding to the status code, explaining the operation result or error cause to users.
    Example: "Success"