Cashier — Looking up and activating the wallet on the participant's behalf

Two regional routes (wallet-api, /v1/events/{eventId}/...):

Endpoint	What it does
`GET /v1/events/{eventId}/cashier/wallets/{userId}`	Read-only lookup: this participant's wallet balance and status in this event. `404 WALLET_NOT_FOUND` if they haven't activated yet.
`POST /v1/events/{eventId}/cashier/wallets/activate`	Creates the wallet, using the `activationAuthorization` obtained in the previous step (see Find or register a participant). Idempotent. The authorization can only be used once — even if activation fails for another reason, it's consumed; request a new one on error.
`GET /v1/events/{eventId}/cashier/wallets/{userId}/statement`	Paginated statement of this wallet's movements (recharges today; sales/refunds once those exist).

curl -X POST http://127.0.0.1:8787/v1/events/{eventId}/cashier/wallets/activate \
  -H "Authorization: Bearer <cashier accessToken>" \
  -H "Content-Type: application/json" \
  -d '{ "userId": "<userId returned in the previous step>", "activationAuthorization": "<token returned in the previous step>" }'

Statement

curl "http://127.0.0.1:8787/v1/events/{eventId}/cashier/wallets/{userId}/statement?limit=20&sortDirection=desc" \
  -H "Authorization: Bearer <cashier accessToken>"

Response
{
  "items": [
    {
      "entryId": "018f26d7-...",
      "transactionId": "018f26d7-...",
      "type": "recharge",
      "accountType": "WALLET_AVAILABLE",
      "amountMinor": 5000,
      "occurredAt": "2026-09-03T16:30:29.377Z",
      "paymentMethod": "cash",
      "note": null,
      "createdByOperatorUsername": "CX-55130771",
      "createdByOperatorDescription": "Entrada Principal"
    }
  ],
  "nextCursor": null
}

createdByOperatorUsername/createdByOperatorDescription identify who performed the movement (the cashier, or the PDV in the future) — they're snapshotted onto the ledger entry at the moment it happens, so they keep showing who the operator was at the time even if the account gets renamed later. Both are null when there's no operator, or when the account has no description set.

Cursor-paginated (not numbered pages): when nextCursor comes back non-null, call again with ?cursor=<value> for the next batch — keep the same sortDirection/filters as the original call, or the API rejects with WALLET_STATEMENT_CURSOR_SORT_MISMATCH.

Available filters, all optional and combinable:

Parameter	What it does
`type`	Only one movement type (today only `recharge` exists).
`occurredAfter` / `occurredBefore`	Date range, `ISO 8601`, inclusive on both ends.
`sortDirection`	`asc` or `desc` (default: `desc`, newest first).
`limit`	1 to 100 (default 50).

amountMinor is signed — positive is a credit (money coming in), negative is a debit. paymentMethod/note only appear on recharge entries; they'll be null for other movement types in the future.

Statement​

Statement