Skip to main content
GET
Searches the movements of a card, reporting one item per operation instead of one per lifecycle event. A purchase made of an authorization, partial clearings, reversals or refunds is a single PURCHASE item carrying the amount currently charged to the card. This is version 2 of Search card transactions, selected with the X-API-Version header. See API Versioning. Enterprise cards only. Requires an API key with access level 1 or higher. Results are always ordered by date, newest first, by when the operation started.

Headers

string
required
Must be 2. Any other value — including omitting the header — serves version 1, which reports one item per event. On 1 October 2026 version 1 is removed: this becomes the only shape and the header is ignored, so sending it stays harmless.

Path parameters

string
required
Card identifier.

Query parameters

array
required
Movement types to include. At least one is required. Possible values: PURCHASE, WARRANTY_WITHDRAWAL, WARRANTY_DEPOSIT, WALLET_WITHDRAWAL, WALLET_DEPOSIT, OVERRIDE_VIRTUAL_BALANCE, VISA_DIRECT_DEPOSIT. Internal event names such as TRANSACTION_APPROVED return 412: PURCHASE already covers them.
string
Start date (ISO-8601 YYYY-MM-DD). Defaults to 7 days ago.
string
End date (ISO-8601 YYYY-MM-DD). Defaults to today.
integer
Page size. Maximum 100. Defaults to 10.
integer
Page number, starting at 1. Defaults to 1.

Response

integer
Number of movements in the current page.
integer
Next page number. null on the last page.
integer
Total number of pages.
integer
Total number of operations across all pages — not events. Expect a smaller number than version 1 reports for the same range.
array
The movements in the current page.
A movement carries these eight fields and no more: there is no status, no decline_reason and no fee breakdown. A declined purchase is reported as a PURCHASE with the amount that was attempted, so summing bill_amount counts declines as spend. To tell purchases apart, read the detail of the ones you care about.