Transactions

Overview

A transaction, in the Nium One platform, is a record of a debit or credit event that impacts the wallet balance. The platform supports a number of transaction types.

Transaction types

Cards

Refer to the Card transactions guide to learn more about transaction types and examples.
Refer to Client transactions to learn more about client transactions and examples.

Payout

Type	Description
`Remittance_Debit`	The debit from the wallet for remittance to one's own account.
`Remittance_Debit_External`	The debit from the wallet for remittance to another account.
`Remittance_Reversal`	The reversal of a remittance transaction.

Payin

Type	Description
`Wallet_Credit_Mode_Card`	The fund credit to a wallet using a card.
`Wallet_Credit_Mode_Prefund`	The fund credit to a wallet using a client prefund.
`Wallet_Credit_Mode_Prefund_Cross_Currency`	The cross-currency fund credit to a wallet using a client prefund.
`Wallet_Credit_Mode_Offline`	The fund credit to a wallet using an offline mode, such as a bank transfer, from the customer’s own account.
`Wallet_Credit_Mode_Offline_Cross_Currency`	The cross-currency fund credit to a wallet using an offline mode, such as a bank transfer, from the customer’s own account.
`Wallet_Credit_Mode_Offline_ThirdParty`	The fund credit to a wallet, in the same currency, using an offline mode, such as a bank transfer from a third party.

Foreign exchange (FX) conversion

When the balance transfer within the wallet API is triggered, the system creates one record and captures the details about the from-account or the to-amount.

Type	Description
`Wallet_Fund_Transfer`	The fund transfer within a wallet, from one currency pool to another.

Wallet-to-wallet transfers

When a wallet-to-wallet transfer is executed using the Fund Transfer API, the system creates two records.

Debit in the sender's wallet
Credit in the receiver's wallet

Type	Description
`Customer_Wallet_Credit_Fund_Transfer`	The funds received in the wallet from another customer’s wallet of the same client.
`Customer_Wallet_Debit_Fund_Transfer`	The funds sent from a wallet to another customer’s wallet of the same client.
`Customer_Wallet_Debit_Intra_Region`	The funds sent from a wallet to another customer’s wallet of a different client but of the same regulatory region.
`Customer_Wallet_Credit_Intra_Region`	The funds received from a wallet to another customer’s wallet of a different client but of the same regulatory region.
`Customer_Wallet_Debit_Cross_Region`	The funds sent from a wallet to another customer’s wallet of a different client and of a different regulatory region.
`Customer_Wallet_Credit_Cross_Region`	The funds received from a wallet to another customer’s wallet of a different client and of a different regulatory region.

Client funding

Type	Description
`Client_Prefund`	The credit to the client-pool balance.
`Client_Refund`	The deduction from the client-pool balance which transfers to the client.
`Wallet_Refund`	The refund money from the wallet back to the client.

Fees

Type	Description
`Fee_Debit`	The fee that's deducted for a transaction.
`Fee_Reversal`	The reversal of a fee debit transaction.
`Fee_Waiver`	The fee that's waived for a transaction.

Open banking

Type	Description
`Transfer_Local`	The local payments are debited from the wallet through the Payment Initiation Service (PIS) open banking.
`Transfer_Local_Reversal`	The local payments are credited or reversed from the wallet through the PIS open banking.

PLAIS (EU)

Type	Description
`Regulator_Auto_Sweep`	For European Economic Area (EEA) regulatory requirements, this transaction includes the amount moved from any other currency to the European Monetary Unit (EUR). This is the requested block currency by the regulator, in case of a block instruction. In addition, this is valid if there's insufficient balance in EUR for blocking.
`Regulatory_Block`	For EEA regulatory requirements, this transaction includes the amount moved to the blocked amount from EUR. This is the requested block currency by the regulator, in case of a block instruction.
`Regulatory_Debit`	For EEA regulatory requirements, this transaction includes the amount debited from the block amount or wallet balance of EUR. This is the requested block currency by the regulator. This is valid when the regulator asks to send the blocked amount to a beneficiary.
`Regulatory_Debit_Reversal`	For EEA regulatory requirements, this transaction includes the amount returned in case of a `failed Regulatory_Debit` remittance.

Examples

Payout transactions

Scenario Transaction record created by the platform

The account holder submits a payout instruction. The Nium One platform validates and processes the payout instruction. If the instruction can be accepted for processing, the platform creates a Remittance_Debit, if purposeCode is a transfer-to-own account. The platform can also create a Remittance_Debit_External, if the purposeCode isn't a transfer-to-own account transaction. If fees are configured and can be applied, the -latform also creates the necessary Fee_Debit transaction.

The payout instruction is returned. This could be for various reasons, including rejected or returned-by-the- beneficiary's bank. The platform creates a new transaction such as a Remittance_Reversal record or a credit record with the settlement status set to Released. The original remittance transaction record, Remittance_Debit or Remittance_Debit_External, is retained, and the settlement status, in the original transaction, is set to Released`.

Scenario	Transaction record created by the platform
The account holder submits a payout instruction.	The Nium One platform validates and processes the payout instruction. If the instruction can be accepted for processing, the platform creates a `Remittance_Debit`, if `purposeCode` is a transfer-to-own account. The platform can also create a `Remittance_Debit_External`, if the `purposeCode` isn't a transfer-to-own account transaction. If fees are configured and can be applied, the -latform also creates the necessary `Fee_Debit` transaction.
The payout instruction is returned. This could be for various reasons, including rejected or returned-by-the- beneficiary's bank.	The platform creates a new transaction such as a `Remittance_Reversal` record or a credit record with the settlement status set to `Released`. The original remittance transaction record, `Remittance_Debit or Remittance_Debit_External, is retained, and the settlement status, in the original transaction, is set to` Released`.

Payin transactions

Scenario	Transaction record created by the platform
When the account holder receives money using a Virtual Account Number (VAN) assigned to the account holder's wallet	The platform creates a `Wallet_Credit_Mode_Offline` transaction record, where the account holder is the sender and the platform is able to match or a `Wallet_Credit_Mode_Offline_ThirdParty` transaction record, where the sender isn't the account holder or the platform is unable to match. If fees are configured and can be applied, the platform also creates the `necessary Fee_Debit` transaction.

Transaction status and settlement status attributes

Every transaction in the platform has two status data elements.

Transaction status
Settlement status

Transaction status

These are the possible values of the transaction status:

Status	Description
`Approved`	The transaction authorization is successful.
`Declined`	The transaction authorization is unsuccessful. The `declined` transaction status applies to these situations: Card transactions are declined due to insufficient wallet balance. The velocity limits are getting exceeded. The declined response is received from the client under the remote-host authorization model. The received transaction is declined due to funding limits getting exceeded. The received transaction is declined under the transaction monitoring checks. The payout transactions are declined under the transaction monitoring checks. A P2P transaction is declined due to the transaction monitoring checks.
`Pending`	The Transaction is on hold. The pending transaction status applies to these situations: For Receive, Payout, or Wallet-to-Wallet Transfer transactions awaiting clearance from internal transaction monitoring checks Receive transactions where customers are trying to fund their wallet by charging their credit/debit card (`Wallet_Credit_Mode_Card`) wherever allowed and where the transaction is awaiting a response from the respective credit/debit card issuer subject to the customer completing the necessary authentication leg required by the issuer Spend transactions captured as part of settlement posting (`Settlement_Direct_Debit` / `Settlement_Reversal` / `Settlement_Direct_Reversal` / `Settlement_Debit` / `Settlement_Credit`) awaiting manual review and clearance
`Rejected`	A payin or payout transaction that's rejected based on the rules set by Nium One. The `Rejected` status doesn't apply to card transactions.
`Blocked`	The transaction is blocked based on a rule or risk policy. Blocked typically only applies to card transactions that are declined due to certain restrictions maintained as part of a rule or internal risk policy.
`Awaiting Funds`	The transaction is waiting for funding.
`Expired`	The transaction is expired due to insufficient funds or the expiration of the FX rate.
`Cancelled`	The transaction is cancelled by the customer.
`Scheduled`	The transaction is scheduled and is going to be processed on the scheduled date.

Settlement status

These are the possible values of the settlement status:

Status	Description
`Disputed`	Only in the case a dispute is raised for a transaction.
`Dispute Closed`	A dispute is raised on a transaction that's now closed.
`Released`	The transaction is released, such as after a reversal.
`Settled`	The transaction is settled with the scheme.
`Unsettled`	The transaction is yet to be settled with the scheme.
`Waived`	The card operations have waived a fee. The corresponding `Fee_Debit` transaction is waived.

Non-card transaction types

P2P transfers: When a P2P transfer is executed, using the P2P Transfer API, the system creates two records, one for the debit leg and one for the credit leg:

A Customer_Wallet_Debit_Fund_Transfer transaction record is created in the sender’s wallet.
A Customer_Wallet_Credit_Fund_Transfer transaction record is created in the receiver’s wallet.

Currency exchange within wallet: When the balance transfer within the wallet API is triggered, the system creates one record and captures the details about the from-to account or the to-amount.

A Wallet_Fund_Transfer transaction record is created in the account holder’s wallet.

Payout, remittance, transfer money: When a transfer operation is executed using the Transfer Money API.

The system creates either a Remittance_Debit or Remittance_Debit_External transaction record. The system also creates a Fee_Debit transaction record, if any fee is applicable for processing the remittance transaction. These transactions have debit impacts on the account holder’s wallet.

Pay in, Receive, Collect: When the account holder receives money using a VAN assigned to the account holder's wallet.

The system creates a Wallet_Credit_Mode_Offline transaction record. The account holder is the sender and the system matches. The Wallet_Credit_Mode_Offline_ThirdParty transaction record is where the sender isn't the account holder or the system is unable to match.

Moving funds between the client prefund and the account holder’s wallet and vice versa

When, by using the Fund Wallet API fundingchannel prefund, the funds are moved from the client-prefund account to the account holder’s wallet. The system then creates a Wallet_Credit_Mode_Prefund transaction record.
When, by using the Withdraw Funds From Wallet API refundMode: CASH, the funds are removed from the account holder's wallet and returned to the client prefund. The system then creates a Wallet_Refund transaction record.