Refund Flow

This page explains how a POS system can trigger a refund through the UEAT Open API.
This capability is optional and not required for certification, but may be used by partners who want to issue refunds directly from their POS.

Refund permissions and authorization are fully managed within the POS itself.
UEAT will process a refund request only when it is initiated and authorized by the POS.

---

Overview

• Action: Send a refund request for an existing order
• Outcome: UEAT processes the refund using its internal refund workflow

Key properties:

• Refunds triggered by the POS maintain full parity with past refund behavior.
• The endpoint performs basic validation only.
• The endpoint does not return a response body but will return an error if applicable.

---

Refund Flow Summary

1. The POS sends a POST /order/refund request.
2. UEAT validates the request (authentication + required fields).
3. UEAT processes the refund internally.
4. No response payload is returned to the POS.

The POS does not need to take further action after sending the request.

---

Endpoint

Method & Path

POST /order/refund

---

Authentication & Headers

Authorization: Bearer <JWT_TOKEN>
x-ueat-locationid: <LOCATION_ID>
Content-Type: application/json

• The JWT is provided during onboarding.
• x-ueat-locationid identifies the merchant location.

---

Request Body

{
  "ExternalId": "string"
}

Field Details

Field	Type	Required	Description
ExternalId	string	Yes	The POS order identifier used when the order was originally created. This is the ID of the order returned by the POS.

Example

{
  "ExternalId": "8E8C159BBD4F"
}

---

Response

• Status: 200 OK or 400 Bad request
• Body: "error content if applicable"

Example error

{
  "errors": [
    {
      "code": "INVALID_PAYLOAD",
      "message": "ExternalId is required."
    }
  ]
}

---

When to Use the Refund Flow

Your POS should send a refund request when:

• A user‑initiated refund occurs at the POS
• The POS is configured to manage refund permissions internally
• You want UEAT to mirror the refund events triggered in your system

---

Example (Postman or HTTP Client)

POST https://<openapi-environment-url>/order/refund
Headers:
  Authorization: Bearer <JWT_TOKEN>
  x-ueat-locationid: 019a9794-ea27-71a8-bc7a-ecffd058546c

Body:
{
  "ExternalId": "8E8C159BBD4F"
}

---

Validation Rules

UEAT validates the following:

• Authentication is valid
• Location ID is provided
• ExternalId is present and not empty

If validation passes, UEAT accepts the request for processing.

---

Logs & Monitoring (Partner Guidance)

Your POS should:

• Log all refund attempts and the ExternalId sent
• Log the HTTP status returned by UEAT
• Monitor internal POS‑side refund permissions and flows

No additional UEAT‑side configuration is required.

---

FAQ

Is the refund synchronous?
No — the request is accepted, then processed internally.

Does the POS need to handle a refund response?
POS must handle if the response is an error.

Is this required for certification?
No, it is optional.

---