Skip to main content
Every movement of funds in TagPay is recorded as a transaction. Whether you credit a customer wallet, process a bank transfer, or run a batch payout, each operation produces a transaction record with a unique reference, a type, and a state that reflects its progress.

Transaction types

When querying transaction lists, filter by type using type=CREDIT, type=DEBIT, or type=ALL (default).

Transaction states

A transaction moves through states as it is processed:
Not all transaction types go through every state. Wallet-to-wallet transfers typically settle immediately and skip the pending/approved flow.

Pending transactions

Transactions that require explicit approval queue up as pending. Retrieve them with:

Approving a pending transaction

Removing a pending transaction

Discard a pending transaction that should not be processed:

Transaction references

Every transaction is identified by a reference — a unique string that you provide or that TagPay generates. References let you:
  • Look up a specific transaction by its reference
  • Safely retry a request without double-processing (idempotency)
  • Correlate TagPay records with your own internal order or payment IDs
Always supply your own reference when creating transactions. References must be at least 10 characters. Using the same reference for two different transactions will cause the second request to be rejected.

Looking up a transaction by reference

Or via the merchant-scoped endpoint:

Batch transactions

Batch operations group multiple credits or debits into a single API call, each identified by a shared batchReference. This is efficient for payroll runs, bulk disbursements, and mass collections.

Creating a batch credit

Retrieving batch status

Retrieve the details of a specific batch by its reference:

Uploading batches via CSV

For very large disbursements, upload a CSV file directly:
After upload, process the batch:
Check the status of an uploaded batch:

Transaction limits

Transaction limits control the maximum amount a customer can transact in a given period. Limits are applied at the customer tier level (TIER_1, TIER_2, TIER_3) and are configured per merchant. If a transaction exceeds a customer’s tier limit, it is rejected at the point of creation. To allow higher volumes, upgrade the customer’s KYC tier. See Customers for details on tier upgrades. Retrieve your merchant’s current limit settings:
Check how much of each limit has been consumed today:

Reversals

A reversal returns funds to the originating wallet after a transaction has completed. Reversals are appropriate when a transaction was processed in error or a customer dispute requires a refund.
Not all transaction types are reversible. Reversals must be authorised by an administrator or a merchant with reversal permissions enabled.

Reversing a batch transaction

Viewing your reversal history

Retrieve a specific reversal record:
Review reversal statistics (totals by status):

Configuring reversal settings

Control which reversal scenarios are permitted for your merchant:

Downloading transaction history

Merchant transactions (CSV)

Export all transactions for your merchant account as a CSV file:
Apply filters using query parameters: type, category, startDate, endDate, status.

Customer transactions (CSV)

Export the full transaction history for a specific customer:

Batch transactions (CSV)

Export your batch transaction list:

Pending transactions (CSV)

Export the current pending transaction queue:

Viewing customer transactions

As a merchant, retrieve the transaction history for any customer under your account:
Customers can also view their own transactions when authenticated:

Wallets

Credit, debit, and manage customer wallet balances

Funds transfer

Send funds to banks and between wallets

Webhooks

Receive real-time notifications for transaction events

API reference

Full endpoint reference for transaction operations