# Find a device, push a sale instruction, poll for the result, and retrieve the payment.

Find a device, push a sale instruction, poll for the result, and retrieve the payment.

1. OPTIONAL — confirm the target device by filtering the device list on its serial number. Skip this step if you already have a known-good serial number. Returns a paginated list; the matching device is the first entry in `data`.
 [searchDevices](/api/search-devices)
2. Push the sale to the device. POST the instruction to /devices/{serialNumber}/payment-instructions. The default `autoCapture: true` (and `processAsSale: false`, its default) produce a normal sale that stays adjustable in the open batch; `entryMethod: deviceRead` prompts the cardholder to tap, insert, or swipe. The immediate 202 response is the INSTRUCTION (status `inProgress`), not the payment.
 [sendPaymentInstruction](/api/send-payment-instruction)
3. Long-poll the instruction until its status leaves `inProgress` while the cardholder taps, inserts, or swipes on the device. Each GET blocks up to ~1 minute for a status change; at runtime repeat this step until the status is `completed` (or `canceled` / `failure`). On completion the response includes a HATEOAS `link` whose `href` points at the created payment (rel `payment`); extract the paymentId from that href for the next step. (MiFare closed-loop cards instead return a `closed-loop-read` link.)
 [getPaymentInstruction](/api/get-payment-instruction)
4. OPTIONAL — retrieve the resulting payment to see whether the processor approved or declined the sale. Use the paymentId extracted from the completed instruction's HATEOAS `link.href` (supplied via inputs, since it is not a standalone response field).
 [getPayment](/api/get-payment)

## Workflow diagram

```mermaid
flowchart TD
  step0["1. device lookup · API"]
  step1["2. payment instruction · API"]
  step0 --> step1
  step2["3. instruction status poll · API"]
  step1 --> step2
  step3["4. payment retrieval · API"]
  step2 --> step3
```