Skip to main content
Transactions are served by the Incard transactions service through the Developer Gateway under /developer/transactions. Every request needs Authorization: Bearer <access_token> and X-On-Behalf-Of: <company_id> — see Authentication.

Endpoints

List transactions

Response (truncated):
Results are sorted by transaction_at descending unless you pass sort and order.

What the list includes by default

  • Every status, including pending and declined, so in-flight payments are visible.
  • Only accounts the API key’s member can access. Members without account scopes see an empty list.
  • Excluded unless you filter for them explicitly with type: the reward types loyalty_out, points_in, points_out, and trophy.
  • Excluded unless scheduled=true: payments scheduled for a future date.
  • Looking rows up by ids or source_payment_ids bypasses both exclusions.

Filters

All list filters accept comma-separated values where noted. Invalid values return 400 with { "error": "<message>" }.

Pagination

Use cursor pagination for syncs and exports. Each page of limit rows (default 50, max 200) includes next_cursor when more rows exist. Pass it back as cursor with the same filters:
The cursor encodes the sort field and order, so do not change sort or order mid-walk. next_cursor is absent on the last page. Offset pagination (offset) is available for UI-style paging and adds a total count to the response. cursor and offset cannot be combined.

Enrichment

Add user=true to include the initiating user’s name and avatar, and card=true to include the card’s name, last four digits, and type on card transactions. Recognised merchants always include enriched_merchant with a display name, category, and icon.

Get a transaction

Returns the transaction object directly (no envelope). You get 404 if the transaction belongs to another company or to an account the member cannot access.

Amounts and signs

Every amount is a { "value": "<decimal string>", "currency": "<ISO 4217>" } object. Values are signed: debit transactions are negative and credit transactions positive. Parse value as a decimal, never as a float.

Status lifecycle

pending moves to exactly one of completed, declined, or reversed, all of which are terminal. Card authorisations start pending and become completed on settlement. A completed transaction that is later refunded appears as a separate refund transaction rather than changing status. Subscribe to transaction.create and transaction.update webhooks to be notified of these changes instead of polling.

Transaction types

direction is set per transaction by the originating system, so always read it from the transaction rather than inferring it from type.