Skip to main content

Overview

A transaction is the closed record of one settled interaction: who was identified, what they bought, which offers applied, how they paid, and the amounts that moved. Two read operations are available today: list transactions and read one transaction’s full detail. Both reads authenticate with an x-api-key and are scoped to the integration in the path. Reads do not carry a request envelope. Money is always a minor-units integer paired with an explicit ISO-4217 currency (for example amount_minor: 4500, currency: QAR).
A transaction is produced by accepting a wallet payment (Payments) or running a top-up (Top-up). This page covers reading those records back.

Operations

List transactions

GET /{integrationId}/transactions. A cursor-paged feed of transaction summaries.

Get one transaction

GET /{integrationId}/transactions/{transactionId}. Full detail for a single record.

List transactions

GET /{integrationId}/transactions returns a cursor-paged feed of transaction summaries, scoped to the integration named in the path. The summary flattens the customer-identity context to top-level fields (customer_phone, customer_name, identified_method) for a cashier till view. By default the list returns only identified transactions. Pass include_unidentified=true to merge in anonymous-session rows. Redemption secrets held in transaction metadata (session code, QR nonce, reward code) are stripped server-side and never returned.

Query parameters

required
Filter by transaction status. One of pending, completed, failed, partially_refunded, refunded.
required
When true, merge in transactions from anonymous sessions (no resolved customer). Default false.
required
Filter to a single branch (UUID).
required
Inclusive lower bound on created_at, RFC3339 date-time.
required
Inclusive upper bound on created_at, RFC3339 date-time.
required
Opaque cursor from the prior page’s meta.next_cursor.
required
Page size. Default 50, maximum 200.

Response fields

Each row in data is a transaction summary.
required
The transaction id.
The stable receipt-of-record number, when minted. Nullable.
required
One of PAYMENT, DEPOSIT, WITHDRAW, TRANSFER, REWARD, BONUS_CREDIT.
One of BANK_TRANSFER, CASH, BALANCE, CRYPTO, POINTS, CARD, CASHBACK, BONUS_CREDIT, INCENTIVE_CLAWBACK. Nullable.
required
One of pending, completed, failed, partially_refunded, refunded.
required
Transaction amount in minor units. Server-authoritative.
required
ISO-4217 currency code, 3 characters.
Total discount applied to this transaction, minor units. Nullable.
E.164 phone of the identified customer. null when unidentified.
Identified customer name. Nullable.
How the payer was resolved. One of phone, qr, short_code, card_fingerprint, provider_customer_id, unidentified. Nullable.
Branch UUID. Nullable.
Branch name. Nullable.
The partner’s order reference. Nullable.
The Feddi session UUID that produced this transaction. Nullable.
required
RFC3339 date-time the transaction was created.
The meta block carries the pagination cursor.
Pass this back as the cursor query parameter to fetch the next page. Absent on the last page.
true when another page exists. Stop paging when it is false.
An opaque integer Feddi may use internally. No action required.

Get one transaction

GET /{integrationId}/transactions/{transactionId} returns the full detail for one record: the flattened customer, the related wallet, program, branch, brand, and enterprise inlined; reconstructed line_items; the applied_offers that touched the charge; and related_transactions so you can render the full money lineage of an order (refunds, the original deposit, sibling rows that share a multi-transaction group). All amounts are minor-units integers with an explicit currency. Metadata is sanitized server-side, so redemption secrets never appear in the response. The endpoint is read-only.

Path parameters

required
The calling integration’s id (UUID). Must match the integration the API key is scoped to.
required
The transaction id (UUID).

Response fields

The data object is a transaction detail. It carries the same top-level ledger fields as the summary (transaction_id, transaction_type, transaction_subtype, status, amount_minor, currency, applied_discount_minor, receipt_number, created_at, plus updated_at), with these additional structured fields.
The identified customer, flattened. Fields: wallet_user_id (string, nullable), phone (string, nullable, E.164), name (string, nullable), identified_method (string, nullable, same enum as the summary), and customer_state (string, nullable, one of verified, pending_proof).
The receiver or sender wallet id depending on transaction direction. Nullable.
The wallet program id. Nullable.
The wallet program name. Nullable.
Inlined branch with id, name, status. Nullable.
Inlined brand with id, name, status. Nullable.
Inlined enterprise with id, name. Nullable.
The partner’s order reference. Nullable.
The Feddi session UUID. Nullable.
Reconstructed order lines. Empty for thin, amount-only settlements. Each line carries quantity (integer, required) and extended_price_minor (integer, required), plus sku, name, unit_price_minor, discount_minor, tax_minor, and category (all nullable). All money fields are minor units.
Offers and promotional grants that touched this charge. Each entry carries offer_id (string, required), discount_minor (integer, required, the value applied), name (string, nullable), and source (string, nullable, one of rule, engine, merchant_note).
Sibling transactions in the same money lineage (refund, original deposit, multi-transaction sibling). Each entry carries transaction_id (string, required), transaction_type (string, required), amount_minor (integer, required), status (string, required), and created_at (string, nullable).
RFC3339 date-time of the last update. Nullable.
PENDING and REFUNDED transactions are returned with their current status rather than omitted or transformed. Read status to branch.

Errors and access scope

Both reads are tenant-scoped to the integration in the path and the x-api-key.
Malformed query on the list read (bad cursor, invalid date, limit out of range).
Missing or invalid x-api-key.
The {integrationId} in the path does not match the key’s integration, the key lacks transaction read access, or the transaction belongs to another integration.
On the detail read, no transaction with this id is visible to the calling integration.
A transaction owned by another integration resolves to FORBIDDEN (403), never NOT_FOUND. An id that is genuinely not visible to your integration is NOT_FOUND (404). Cross-tenant isolation is enforced per record. The error code is a string enum, never a bare HTTP status number. Branch on code, not on the status. See Idempotency and errors.

Where to go next

Payments

The promo-first debit that produces a wallet-payment transaction.

Top-up

The confirm and SKU-sale credits that produce DEPOSIT transactions.

Money classes

The actual and promotional split a detail row breaks out.

Idempotency and errors

The typed error model and 403 vs 404 cross-tenant rules.