PDV — Minhas vendas

Histórico das próprias cobranças — unifica os dois métodos (QR impresso + PIN e QR/NFC dinâmico) numa lista só, ordenada por data. Autoserviço: sempre as suas vendas, nunca de outro PDV — identificado pelo seu próprio token, sem parâmetro pra ver outro.

Endpoint	O que faz
`GET /v1/events/{eventId}/pdv/transactions`	Lista as vendas/tentativas deste PDV, paginado por cursor.

curl
JavaScript
Python

curl "http://127.0.0.1:8787/v1/events/{eventId}/pdv/transactions?limit=20" \
  -H "Authorization: Bearer <accessToken do PDV>"

const response = await fetch(
  `http://127.0.0.1:8787/v1/events/${eventId}/pdv/transactions?limit=20`,
  { headers: { Authorization: `Bearer ${pdvAccessToken}` } },
);
const { items, nextCursor } = await response.json();

import requests

response = requests.get(
    f"http://127.0.0.1:8787/v1/events/{event_id}/pdv/transactions",
    headers={"Authorization": f"Bearer {pdv_access_token}"},
    params={"limit": 20},
)
result = response.json()

Resposta
{
  "items": [
    {
      "transactionId": "018f26d7-...",
      "channel": "dynamic_qr",
      "amountMinor": 2500,
      "status": "approved",
      "declineReason": null,
      "occurredAt": "2026-09-10T18:30:00.000Z",
      "resolvedAt": "2026-09-10T18:30:12.000Z"
    },
    {
      "transactionId": "018f26d7-...",
      "channel": "printed_qr_pin",
      "amountMinor": 1200,
      "status": "declined",
      "declineReason": "CREDENTIAL_LOCKED",
      "occurredAt": "2026-09-10T18:25:00.000Z",
      "resolvedAt": "2026-09-10T18:25:00.000Z"
    }
  ],
  "nextCursor": null
}

channel diz qual dos dois métodos gerou aquela linha — dynamic_qr (QR/NFC dinâmico) ou printed_qr_pin (QR impresso + PIN). status é pending | approved | declined | expired; só dynamic_qr pode aparecer pending — uma venda de QR impresso já nasce resolvida (aprovada ou recusada), não existe um estado intermediário nesse fluxo. declineReason só vem preenchido quando status é declined, com os mesmos códigos já documentados nas páginas de cada método (INSUFFICIENT_BALANCE, CREDENTIAL_LOCKED, CREDENTIAL_EXPIRED, CREDENTIAL_NOT_ACTIVE, WALLET_NOT_ACTIVE).

resolvedAt vem null só enquanto um dynamic_qr ainda está pending (esperando o participante resolver) — em todo o resto já vem preenchido. Um intent que ninguém nunca resolveu leva até ~15 segundos depois do expiresAt pra aparecer como expired aqui — é quando um processo interno detecta o vencimento (ver Pagamento dinâmico via QR/NFC pro detalhe).

O que não aparece aqui

Um QR impresso com PIN errado que ainda não bloqueou a credencial (tentativas 1 a 4 de 5) não vira linha nenhuma — só a tentativa que efetivamente bloqueia a credencial (5ª errada) aparece, como declined / CREDENTIAL_LOCKED.
Um QR (impresso ou dinâmico) de evento errado ou desconhecido também não aparece — esse caso continua deliberadamente ambíguo por segurança (ver Pagamento via QR impresso + PIN).

Filtros e paginação

Paginado por cursor (não por página numerada): quando nextCursor vier preenchido, chame de novo com ?cursor=<valor> pra pegar a próxima leva — mantendo os mesmos sortDirection/filtros da chamada original, senão a API rejeita com PDV_TRANSACTIONS_CURSOR_SORT_MISMATCH.

Parâmetro	O que faz
`channel`	`dynamic_qr` ou `printed_qr_pin` — só um dos dois métodos.
`status`	`pending`, `approved`, `declined` ou `expired`.
`occurredAfter` / `occurredBefore`	Intervalo de datas, `ISO 8601`, inclusivo dos dois lados.
`sortDirection`	`asc` ou `desc` (padrão: `desc`, mais recente primeiro).
`limit`	1 a 100 (padrão 50).

Todos opcionais e combináveis — sem filtro nenhum, devolve tudo (dos dois métodos), mais recente primeiro.

O que não aparece aqui​

Filtros e paginação​

O que não aparece aqui

Filtros e paginação