# Submit a refund instruction to a device, poll it to completion, and retrieve the refund.

Submit a refund instruction to a device, poll it to completion, and retrieve the refund.

1. Required — submit the refund instruction to the device via POST /devices/{serialNumber}/refund-instructions. The device then prompts the cardholder, who is present at the device, to authorize the return of funds. Returns HTTP 202 (Accepted) with a `refundInstructionId` and `status: inProgress` — the refund is not yet complete. Requires a UUID v4 Idempotency-Key header.
 [sendRefundInstruction](/api/send-refund-instruction)
2. Required — poll GET /refund-instructions/{refundInstructionId} until `status` becomes `completed`. The gateway holds each poll open for up to a minute waiting for a status change; wait for a response before polling again. When complete, the response includes a HATEOAS `link` to the refund — parse the refundId from `link.href` for the optional getRefund step (there is no top-level refundId field on the instruction).
 [getRefundInstruction](/api/get-refund-instruction)
3. OPTIONAL — retrieve the resulting refund via GET /refunds/{refundId} to confirm the processor approved it and to read the refund details. Supply the refundId parsed from the completed instruction's link.href.
 [getRefund](/api/get-refund)

## Workflow diagram

```mermaid
flowchart TD
  step0["1. refund instruction · API"]
  step1["2. instruction status poll · API"]
  step0 --> step1
  step2["3. refund retrieval · API"]
  step1 --> step2
```