Transaction History

Transaction history describes what happened after a cardholder attempted a payment. A transaction may be checked, authorized, completed in the ledger, settled, reversed, or charged back. These stages are separate: an approved authorization is not necessarily a final transaction.

Partner-facing surface

Three shapes of transaction endpoint are available to partners, each tailored to a different operating scope:

Shape	Path(s)	Use it when…
Partner-wide aggregation	GET /transactions, GET /balances, GET /balances/{iban}	The caller doesn't know which IBAN owns the transaction — they want every record the partner is allowed to see.
Tenant-scoped	GET /business/accounts/{b2bAccountId}/transactions, GET /business/accounts/{b2bAccountId}/balances	The caller is operating inside one of their linked B2B tenants.
Individual-scoped	GET /individual/accounts/{id}/transactions, GET /individual/accounts/{id}/balances	The caller is operating on one specific partner-owned individual.

Anti-enumeration

Every transaction and balance endpoint returns 404 (not 403) when an IBAN, cardholder, or tenant belongs to a different partner or does not exist. The body does not distinguish between the two cases. Use GET /me to confirm which resources the partner owns.

Pagination & limits

Default page=1, limit=10 for transactions; limit=50 for audit logs and card-status history. There is no enforced maximum limit value in the Partner API today — ?limit=3000 is accepted.

Transaction direction

Every transaction has a direction that describes how it affects the account:

Direction	Meaning
D - Debit	The transaction takes money from the account. A successful debit normally requires the amount to be blocked first.
C - Credit	The transaction adds money to the account or records an incoming credit. It can be recorded as pending while the final accounting step is outstanding.
N - Neutral / inquiry	The transaction only checks information, such as balance or account/card validity. It does not block funds or start a further financial action.

Authorization flow

When a cardholder makes a payment, the transaction is first authorized.

Debit transactions

1. The payment details, card, account, amount, and applicable fees are checked.
2. If sufficient funds are available, the debit amount and applicable fee are blocked.
3. The transaction is recorded as pending while it waits for settlement.
4. If the balance is insufficient, or the authorization checks fail, the transaction is declined and resolved immediately. No successful debit block is created.

The blocked amount is a reservation. It reduces the available balance, but it is not yet a final ledger transaction.

Credit transactions

Credit transactions are recorded so that their progress can be tracked. They may remain pending until the final accounting or settlement step confirms the credit. A credit does not use the debit-blocking flow described above.

Neutral or inquiry transactions

For a neutral transaction, the balance or requested information is checked only. No amount is blocked, no settlement is required, and no additional financial action is started. The transaction is resolved immediately after the check finishes.

Transaction statuses

Status	Meaning
pending	The transaction was accepted or recorded, but its final accounting outcome is still outstanding. Debit funds may be blocked.
declined	Authorization or a required validation failed. The transaction cannot proceed as requested.
completed	The transaction has reached its final successful accounting outcome.
reverted	A previously authorized transaction was undone and its blocked amount was released.

Resolved versus completed

Resolved means the system has finished processing the transaction and knows its outcome. Completed means the outcome was successful and final. For example:

• A declined transaction is resolved, but not completed.
• A neutral inquiry is resolved immediately because it has no financial follow-up.
• A debit authorization can be pending and unresolved while it waits for settlement.
• A successfully settled debit becomes completed.
• A reversed authorization becomes reverted after the blocked amount is released.

Settlement

Settlement is the step that finalizes an authorized transaction in the ledger.

1. A debit authorization blocks the requested amount.
2. The transaction remains pending while settlement information is awaited.
3. Settlement information is matched to the original transaction.
4. The blocked amount is converted into the final ledger transaction.
5. The transaction becomes completed and the settlement is recorded in its history.

Until settlement arrives and is successfully matched, a debit transaction may correctly remain pending even when authorization was approved. The final settled amount can differ from the original authorization, usually being reduced to the minimum applicable amount when the two amounts do not match. AFD or advice messages can also add information or update the transaction before it is finalized.

If settlement cannot be matched or is rejected, the transaction is not silently treated as completed. It remains available for resolution and may later be corrected, rejected, or reversed according to the outcome.

Reversals

A merchant or payment network may send a reversal before settlement. A reversal cancels all or part of the authorization:

1. The reversal is matched to the original transaction.
2. The blocked amount, or the reversed portion, is released.
3. The transaction history records the reversal.
4. A full reversal changes the transaction to reverted.

Partial reversals release only part of the authorization. The remaining amount can stay authorized and may receive a new reservation while the original transaction remains traceable in history. AFDs and other follow-up messages may update the transaction before settlement. Fees may follow separate rules and are not necessarily reversed with the payment amount.

Automatic resolution of old transactions

Some authorized transactions never receive settlement or a provider reversal. To prevent funds from remaining blocked indefinitely, an automatic background process reviews unresolved transactions after a configured number of days.

The number of days is not universal. It depends on transaction characteristics and the applicable business rule. When the threshold is reached:

• If funds were blocked, the blocked amount is released and the transaction becomes reverted.
• If no funds were blocked, the transaction is resolved without an unblock operation and can be marked completed when no further financial action is required.
• The transaction history records that it was resolved automatically.

An old pending transaction therefore does not necessarily indicate an error. It may still be inside its allowed settlement window.

Chargebacks

A chargeback is a later dispute of a card transaction. It is different from a reversal:

Reversal	Chargeback
Usually arrives before settlement and cancels an authorization.	Usually happens after a transaction has been settled or posted.
Releases a blocked amount.	Disputes or returns a completed ledger amount.
Changes the original authorization's final outcome.	Creates or updates a dispute-related financial record and may adjust the original transaction.

Chargeback files are processed by a scheduled background job. The resulting history can contain the original payment, the chargeback event, related adjustments, and the final dispute outcome. A chargeback does not mean the original authorization was declined; the original payment may have been completed before the dispute was received.

Fees

Fees can be calculated during authorization and included in the amount reserved for a debit transaction. Depending on the transaction, a fee can also be applied during a later accounting step.

The transaction history can include:

Fee information	Meaning
Fee type	The category of fee that was applied.
Fee amount	The fee in the transaction currency.
Converted fee amount	The fee amount used when currency conversion applies.
Fee description	Text suitable for displaying the fee to the customer.

Do not use the presence of a fee to determine whether a payment is complete. A fee can be recorded while the payment itself is still pending. Automatically generated recurring fees appear as their own completed transaction records.

Important transaction information

When displaying or reconciling transaction history, the most useful business fields are:

Field	Meaning
Direction	Whether the transaction is a debit, credit, or neutral inquiry.
Amount and currency	The payment or credit value and its currency.
Billing amount and currency	The amount and currency used for the cardholder billing view, when different.
Status	The current lifecycle state: pending, declined, completed, or reverted.
Authorization result	Whether the payment was accepted for processing.
Merchant	Merchant name, location, category, and terminal details when available.
Card	The card associated with the transaction. Sensitive card data is not part of transaction history.
Account	The account affected by the transaction.
Transaction reference	A stable reference used to relate authorization, settlement, reversal, and dispute events.
Transaction date	When the payment was made or received.
Created date	When the transaction record was created.
Resolved date	When the transaction reached a known final outcome.
Fee details	The applied fee and customer-facing fee description, when applicable.
Settlement details	Whether settlement was received and applied.
Reversal details	Whether all or part of the authorization was released.
Additional information	Optional merchant, device, channel, risk, product, or external reference data.

Sensitive payment data such as the full card number, PIN data, magnetic-stripe data, and chip data is not exposed in transaction history.

Reading a transaction's state

Use the following sequence when presenting a transaction to a customer:

1. Check the direction to determine whether it is a debit, credit, or neutral inquiry.
2. Check the status.
3. For pending, explain that authorization or recording succeeded but settlement or another final step is still outstanding.
4. For declined, explain that the payment did not proceed and no successful debit reservation remains.
5. For completed, show it as finalized, while checking whether a later dispute or adjustment is present.
6. For reverted, show that the authorization was undone and the reserved amount was released.
7. Use settlement, reversal, fee, and dispute information to explain any difference between the original authorization and the final amount.

The transaction history is the audit trail of these stages. It should be interpreted as a lifecycle rather than as a single instantaneous payment result.