Reporting Guides Appendices

Appendix A: Definitions

The authorization and settlement process

When a card is used for a purchase at a merchant, the purchase is processed as described here.

  1. At the point of purchase, the merchant submits an authorization request to their payment gateway and the acquiring bank.
  2. Nium receives the authorization request. If card details match and there is sufficient balance on the card, the balance is reduced, and the authorization request is authorized.
  3. The card processor submits a file to Nium containing a list of all authorization requests.
  4. Nium subsequently receives a settlement record that specifies the amount that Nium has to settle with its issuing bank for that transaction. There could be minor differences between the purchase amount submitted in the authorization request and the settlement request if the transaction is being carried out in a currency different than the card currency (the card scheme would have applied different Forex fees).
  5. It can take up to three days for a settlement record to be received by Nium after a purchase has been completed.

Single-use and Multispend cards

During the initial account configuration, Nium and the client defined the card type to be issued to the client. Nium supports two types of virtual cards:

  • Single-use cards: these are cards to be loaded and used for a single transaction. Upon receiving the first authorization request from the card scheme, any remaining funds on the card become unavailable (the term used for this is frozen, preventing further authorization requests from being processed). The card is deleted upon receipt of the settlement record, and frozen funds are returned to the funding account.
  • Multispend cards: These can be loaded and reloaded for multiple purchases. When a card reaches its expiry date, any outstanding balance on the card is returned automatically to the funding account.

Refunds

If the merchant cancels a transaction, Nium receives a refund record with the settlement records.

Typically a single-use card would have been deleted when a refund is received. In this case, funds for the refund are returned immediately and directly to the funding account.

Refunds on a multispend card are added to the existing card balance if the card is active or directly to the funding account in case multispend card is deleted.

Expired authorizations

Authorization requests can be automatically expired.
Sometimes, a merchant submits an initial authorization request (affecting the available balance on a card) but does not follow up with a settlement request. After a pre-set period, Nium automatically expires the authorization request.

  • If the card is a single-use card, all funds (equal to the amount loaded on the card) are returned to the funding account.
  • The authorized but unsettled funds are added to the card balance if the card is reloadable.

Manual adjustments

If issues occur, manual adjustments are possible. Theoretically, manual interventions would not be needed if there were no technical or manual issues in the system. All transaction entries recorded in the system would correspond to real-life transactions. In practice, however, there are situations when transactions are not processed correctly due to system issues or manual errors.
For instance, a purchase request could erroneously be processed twice because there are two transaction records when there should have only been one. In such a scenario, a manual adjustment is made to compensate for the action because executed and completed transactions cannot be reversed or cancelled. An administrator can only perform a compensating action to cancel the effect of the transaction.x
When a discrepancy is identified, the adjustment can be credited or debited in the same or subsequent months.

Authorisation reasons

The following authorization reasons are available.

NORMAL_TAKERepresents an approved, successful debit authorization.
NORMAL_TAKE_PRE_AUTHRepresents an approved, successful debit pre-authorization.
NORMAL_PUTRepresents a reversal of an approved, successful debit authorization. See NORMAL_TAKE.
REVERSE_PUTRepresents a merchant's approved, successful credit authorization (an authorization for a merchant refund).
REVERSE_TAKERepresents a reversal of an approved, successful credit authorization by a merchant. See REVERSE_PUT.
EXPIRY_TAKERepresents an approved, successful authorization release when a settlement is not received within the stipulated days. This could also be a partial authorization release because the authorization was more significant than the settled amount.
EXPIRY_PUTRepresents a reversal of an approved, successful authorization release. See EXPIRY_TAKE.
DECLINED_TAKE: provider reasonRepresents a declined debit authorization.
CLOSE_TAKERepresents manual closure of an approved, successful debit authorization.
CLOSE_PUTRepresents a reversal of a manually closed authorization. See CLOSE_TAKE.

Appendix B: Cases

You can receive the following sample reports:

  • Card_Activity_daily_2014-06-25-04-31-21_0000001
  • Funding_Account_Activity_daily_2014-06-03-05-34-55_0000001

These reports depict how the following cases are presented

  • Single cases
  • Other scenarios cases

To receive sample reports, contact the Nium support team ([email protected]).

πŸ“˜

Note:

  • Although named 2014-06-25, sample reports contain data with numerous dates from captured live data scenarios. These have been grouped in a sample file containing a majority of cases.
  • Sample reports include two additional columns highlighting the cases. Real reports do not include these columns.
  • Columns externalID and customField1 to customField20 have been left empty because these are usually populated by the client when creating a card in Nium.

Single cases

This section contains a list of single cases.

CASETRANSACTION TYPECASE DESCRIPTION
0100TRANSFERSuccessful normal transfer.
0101TRANSFERSuccessful Forex transfer.
0102TRANSFERSuccessful transfer initiated by Nium (more information in the note entered by Nium operators).
0103TRANSFERTransfer of funds stuck in a suspended state. It was then resumed to successful completion.
0200FEE REVERSALFee reversal by the Nium finance team (refunding a transaction fee previously taken).
Note: The Transaction info field column contains the original transactionId that this fee relates to (original transactionId is when the original fee was taken).
0300BANK DEPOSITSuccessful bank deposit transfer.
0400BANK DEPOSIT REVERSALThe reversal of a successful bank deposit transfer was reversed as the bank service provider initially reversed it.
0500CARD DEPOSITSuccessful card deposit transfer via a credit/debit card.
0501CARD DEPOSITFailed attempt card deposit transfer via a credit/debit card.
Note: No balance movements have happened on the participant balance.
0600CARD RETURNSuccessful card return of funds to a credit/debit card.
0601CARD RETURNFailed card return of funds to a credit/debit card.
0700BANK RETURNSuccessful bank transfer return to a bank account.
0701BANK RETURNThe Bank return failed; however, an adjustment initially happened and reversed it immediately.
0702BANK RETURNSuccessful bank transfer returned to a bank account requested by the client and initiated manually by Nium officers.
0800BANK RETURN REVERSALBank transfer out reversed by the bank. Funds are returned to the funding account.
0900REVENUE SHARESuccessful revenue share credit/debit.
1000MANUAL CREDITSuccessful manual credit.
1100MANUAL DEBITSuccessful manual debit.
1200CARD CREATEDSuccessful card creation with funds transfer.
1201CARD CREATEDCard creation with funds transfer stuck in a suspended state. It was then resumed to successful completion.
1202CARD CREATEDCard creation with funds transfer stuck in a suspended state. It was then resumed to reversal/failed completion.
Note: Since the card was not created, the card's first six and last four digits are not present.
1203CARD CREATEDCard creation with funds transfer stuck in a suspended state. The transaction has not been resumed. These cases need to be monitored and reported
1204CARD CREATEDSuccessful card creation with Forex funds transfer.
1205CARD CREATEDSuccessful card creation with no funds transfer.
1300CARD DELETEDThe card was deleted successfully with a funds transfer.
1301CARD DELETEDCard deletion failed; however, an adjustment happened and was reversed immediately. Note that the Non-Forex fee column shows the reversal of the fee.
1302CARD DELETEDThe card was deleted successfully with no funds transfer.
1400AUTHORIZATIONNormal successful authorization.
1401AUTHORIZATIONRegular successful Forex authorization.
1500AUTHORIZATION RELEASEThe merchant cancelled the successful authorization, and an authorization release was received. In this case, the virtual card is thawed and is available
for use (unless another spend transaction is settled on the card). The authorization release can be matched against the original authorization using the authorization code.
1600PURCHASENormal successful purchase.
1601PURCHASEStandard successful Forex purchase.
1602PURCHASEStandard successful purchase with a fee.
1700MERCHANT REFUNDA successful merchant refund transaction. Nothing comparable between the settlement (purchase) and refund apart from the merchant name.
1701MERCHANT REFUNDA successful merchant Forex refund transaction.
1800CARD DEPOSIT REVERSALA successful card deposit transfer via a credit/debit card gets reversed. Note that in the transaction info, the related original transactionId is available.
1900FREEZEThe card state was successfully changed to Restricted. This happens when the first authorisation is processed on a single-spend card.
2000THAWThe card state was successfully changed to active. This typically happens when an authorization has been released, and no settlements/purchases are on the card.
2100LOSS RECOVERYA successful loss recovery transaction is to recover any virtual card's negative balance.
2200DISPUTE OPENEDA dispute was opened. This is the first step in a dispute process. No fund movements take place with this type of transaction
2300DISPUTE REVERSEDA dispute was reversed. No fund movements take place with this type of transaction.
2400DISPUTE WONA dispute was won, and funds, less a fee, were transferred to the card.
2401DISPUTE WONA dispute was partially won, and funds, less a fee, were transferred to the card. The transactionInfo column contains WON_PARTIAL.
2500DISPUTE LOSTA dispute was lost, and a fee was deducted.
2600DEDUCT FEEThe dispute was invalid. A fee was deducted, and transactionInfo column contains INVALID_DISPUTE_FEE.

Other scenario cases

This section contains a list of other scenario cases:

CASETRANSACTION TYPECASE DESCRIPTION
5000MANUAL DEBIT / MANUAL CREDITManual adjustments for testing card transactions.
5100TRANSFER / MANUAL DEBIT / MANUAL CREDITManual adjustments for reversing a Forex transfer as it was executed in error.
5200CARD CREATED / AUTHORIZATION / PURCHASE / CARD DELETEDMultiple purchases for a single authorization. The authorization code is the point of reference to match the purchases against the authorization. An initial card creation with a funds transfer is also shown.
5300CARD CREATED / AUTHORIZATION / PURCHASE / MERCHANT REFUND / CARD DELETEDOne purchase and one authorization, and a split merchant refund. The refunds cannot be matched against the original purchase; however, the system must be able to accept multiple refunds.
5400CARD CREATED / TRANSFER / AUTHORIZATION / CARD DELETED / TRANSFER / PURCHASEInsufficient funds to cover a Forex purchase. This card required an adjustment from the funding account to cover the Forex discrepancy. Also note Forex authorization and original currency, and Forex settlement details and original currency.
5500CARD CREATED / AUTHORIZATION / PURCHASE / CARD DELETEDMultiple authorizations and purchases (all with different authorization codes) on a single-fund/single-spend virtual card. This is rare but may happen if the merchant splits the authorization into several more minor authorizations, and they were all processed instantly so that a freeze did not occur on time. However, the authorization limit works accordingly, and authorizations of this sort are only approved if sufficient funds are available for all authorizations
5600AUTHORIZATION / FREEZEOn single-spend cards, the card state is changed to restricted when authorization is processed.
5700AUTHORIZATION RELEASE / THAWOn single-use cards, when an authorization is released (or expired), and no settlements have been processed on the card, the card state is changed to active, and another authorization can be processed.
5800CARD CREATED / AUTHORIZATION / PURCHASE / LOSS RECOVERYA card that ended up with a negative balance after the purchase. Loss recovery is a transaction that is used to recover any negative balance that may be present on a virtual card.
5900DISPUTE OPENED / DISPUTE REVERSEDA dispute was opened, then reversed.
6000DISPUTE OPENED / DISPUTE WONA dispute was opened and won.
6100DISPUTE OPENED / DISPUTE WONA dispute was opened and partially won.
6200DISPUTE OPENED / DISPUTE LOSTA dispute was opened, but the dispute was lost.