Card transactions

Overview

A transaction is a record of a debit or credit event that impacts the wallet balance.

Transaction types

Transaction type	Description
`Auto_Sweep`	Automatically sweep from one currency to another within a wallet to authorize a transaction if multicurrency auto-sweep is set up.
`Balance_Inquiry`	Balance inquiry transaction responds with a cumulative balance for single as well as multicurrency wallets in the base currency.
`Chargeback_Credit`	Credit transaction in the case of a chargeback.
`Debit`	Card transactions such as point-of-sale (POS), ATM, and e-commerce (ECOM).
`Decline_Advice`	Declined transactions. Visa or Mastercard can decline any transaction if the Integrated Chip Card Card Verification Value (iCVV), Card Verification Value (CVV), or Dynamic Card Verification Value Card (dCVV) is invalid or if it's suspected of fraud. These declined transactions are reported and logged with the transaction type set as `Decline_Advice`.
`Incremental_Auth _Reversal`	Online reversal of an incremental authorized transaction.
`Original_Credit`	Received incoming Original Credit Transfer (OCT) and credited to the wallet linked to the cardholder's card.
`Original_Credit _Reversal`	Online reversal of a direct transfer to a card, for example, reversal of an original credit transaction.
`Partial_Reversal`	Online reversal of the partial amount of an earlier card transaction.
`Reversal`	Online reversal of a transaction.
`Reversal_Advice`	Reversal is initiated when a timeout scenario happens. If Visa or Mastercard time out a card transaction, they generate a reversal advice to roll back the transaction. In the case of wallet clients, Nium applies the reversal advice and provides the credit back to the customer. In the case of Delegated Model authorization clients, Nium reverses funds on the client prefund account and also forwards the reversal advice to the Delegated Model client for crediting funds back to the customer.
`Settlement_Credit`	Funds are credited to the cardholder's wallet when the settlement amount, processed during clearing, is less than the transaction amount, processed during the authorization.
`Settlement_Debit`	Funds are debited from the cardholder's wallet when the settlement amount, processed during clearing, is more than the transaction amount, processed during the authorization.
`Settlement_Direct _Debit`	Funds are debited from the cardholder's wallet for transactions based on the settlement file, for example, force posting.
`Settlement_Direct _Reversal`	Funds are credited to the cardholder's wallet for the reversal of a debited transaction based on the settlement file.
`Settlement_Reversal`	Funds are credited to the cardholder's wallet for the reversal of a debited transaction.

Examples

Wallet client

#	Scenario	The platform creates the transaction record
1	The account holder uses the card to shop at a merchant location. The merchant’s acquirer bank submits the transaction in real time for authorization.	The system creates a debit transaction record and captures details about the merchant, transaction amount, currency, and other relevant details.
2	The account holder uses the card to shop at a merchant location. The merchant’s acquirer bank submits the transaction directly through clearing or forced posting.	The system creates a settlement direct debit transaction record and captures details about the merchant and the transaction amount.
3	The account holder returns the previously purchased product to the merchant. The merchant triggers a full refund through its acquirer bank. Nium relates the refund to the original purchase transaction.	The system creates a new settlement reversal transaction record or credit amount. The system retains the original debit transaction record and there's no change to it.

Delegated Model client

#	Scenario	The platform creates the transaction record
1	The account holder uses the card to shop at a merchant location. The merchant’s acquirer bank submits the transaction in real time for authorization.	The system forwards the request to the client for authorization. On approval from the client, the system creates a debit transaction record and captures details about the merchant, transaction amount, currency, and other relevant details.
2	The account holder uses the card to shop at a merchant location. The merchant’s acquirer bank submits the transaction directly through clearing or forced posting.	The system creates a settlement direct debit transaction record and captures details about the merchant and the transaction amount.
3	The account holder returns the previously purchased product to the merchant. The merchant triggers a full refund through its acquirer bank. Nium relates the refund to the original purchase transaction.	The system creates a new settlement reversal transaction record or credit amount. The system retains the original debit transaction record and there's no change to it.

Card transaction life cycle

In the Nium ecosystem, the card transaction life cycle consists of two parts:

Transaction authorization
Transaction settlement

Transaction authorization

When a customer uses a card at a merchant location, the card middleware from the network receives an authorization request.

For a wallet client

If the authorization request passes all the limits and restrictions set for the client, customer, or card—and if there's sufficient balance—the transaction is approved. If not, the transaction is declined.

For a Delegated Model client

If the authorization request passes all the limits and restrictions set for the client, customer, or card, the card middleware forwards an authorization request to the client. The client needs to respond to the card middleware within a default hard limit of 2 seconds. If this fails, the authorization is declined.

Transaction settlement

Nium has a settlement cycle with the schemes where it receives a settlement file, for example, once a day for Visa. The card middleware processes the file and, if any adjustments are to be made to the transaction, they're done based on the data in the file. This file is treated as final.

For a wallet client

The settlement process is totally between Nium and the scheme. Every transaction is settled between Nium and the scheme. Any difference in the amounts, which may be credit or debit, is passed on to the customer’s wallet.

For a Delegated Model client

The settlement process is still between Nium and the scheme but Nium shares a settlement file with the client because the customer ledger is managed by the client. While Nium settles the transaction with the scheme and any differences are passed on to the client, it's up to the client to manage the customer ledgers.