In this section, you’ll find a comprehensive list of commonly used payment terms along with their definitions. This overview is designed to provide clear explanations to help you navigate through payment processes and concepts with confidence. If you need further assistance, please contact the Nomupay support team.
| Term | Definition |
|---|---|
| 3DS | 3D Secure is a payment authentication protocol that adds an extra layer of security to online card transactions by verifying the cardholder's identity. This verification typically involves the cardholder providing additional information, such as a one-time code from their phone or a biometric scan (like a fingerprint), to confirm they are the legitimate owner of the card before a transaction is approved. |
| 3rd Party Funding | Incoming funds that origin from a 3rd party financial institution (e.g. an acquirer). Nomupay Payout/Path customers can choose for one or more 3rd parties to fund their Nomupay funding account. In that case, Nomupay will review and approve the 3rd parties before they can start depositing funds on the customer’s funding account. |
| Acceptance | Acceptance refers to the successful authorisation and completion of an ecommerce or in-store payment transaction. |
| Acquirer |
The acquirer serves the merchant and acts as an intermediary for handling the authorisation, card scheme settlement, and deposit of funds from the consumers issuing bank into the merchant bank account. This means that the acquirer:
|
| Acquiring fee | Acquiring fees are paid to the acquirer to cover the cost of acquiring the funds from the cardholder. The acquiring fee is referred to as the MDR i.e. Merchant Discount Rate, in the associated reporting and via the Portal. |
| API | Application programming interface (API) serves as a contract between two applications and defines how the applications are to communicate with each other using requests and responses. |
| APM | An alternative payment method (APM) is a payment option which is not cash or a traditional card payment. Examples of APMs are digital wallets, bank transfers, or buy now pay later (BNPL). An APM can be both a local payment method (LPM) or global payment method. |
| Associated Nomupay Gateway | A gateway which is either part of the Nomupay group or is considered part of the Nomupay ecosystem due to an integration setup. Customers who choose to process via the Associated Nomupay Gateway will have access to Nomupay’s unified platform product offering. |
| Authentication | Authentication is the process of verifying the identity of the consumer making a payment to ensure they are the legitimate and not a fraudster. This is a critical security step in preventing unauthorised transactions by confirming the cardholder's identity through methods like PINs, biometrics (like a fingerprint), one-time passcodes, or address verification. |
| Authorisation | After a consumer initiates a payment the processing gateway sends an authorisation request with the transaction details to the acquirer. The acquirer forwards the request to the card scheme (i.e. Visa, Mastercard, etc.) which routes it to the issuing bank for verification. The issuing bank checks that the consumer holds sufficient funds or credit limit, before approving or declining the transaction by sending a response back to the processing gateway via the card scheme and the acquirer. |
| Available Balance | Funds deposited, which have passed the sanctions screening, and are directly available for disbursements. |
| BIN (Acquiring BIN) | The acquirer bank identification number (BIN) is used to clear and settle the transactions with the card schemes (e.g. Visa and Mastercard). An acquirer will have different BINs assigned per card scheme and country/region license. |
| Card Scheme Settlement | Incoming funds that origin from the successful card scheme settlement of payment transactions (ecommerce or in-store) for provided goods or services. |
| Clearing | Clearing is the process of exchanging and reconciling the payment transaction details between the cardholder's bank (issuer) and the merchant's bank (acquirer). The clearing process takes place after a transaction has been authorised, and before the final transfer of funds (settlement) between the issuer and the acquirer. Card schemes like Visa and Mastercard facilitate this process by transmitting payment information and confirming transaction authenticity and details to ensure both parties have the correct data to settle the transaction correctly. |
| Customer | Party which is contracting with Nomupay. |
| Direct Funding | Incoming funds that origin from a Payouts/Path Customer choosing to fund their funding account in order to payout Recipients. |
| Ecommerce | The buying and selling of goods and services via digital channels like websites, mobile apps, and online marketplaces. |
| Ecommerce API | The Ecommerce API is an integration method that enables Nomupay customers to access Nomupay’s Payments ecommerce product offering and process payments transactions via Nomupay’s unified platform. |
| EEA |
European Economic Area. There are 30 EEA countries: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain and Sweden. All 27 EU countries are also EEA countries. Iceland, Liechtenstein and Norway are the only contries in the EEA that are not in the EU. |
| EID |
Entity ID, which is also referred to as the Account ID. Every customer that has been onboarded to Nomupay’s unified platform, is provided a unique Account ID. The Account ID is formatted with the prefix "EID" (ex. EID-1234567). This ID is referenced whenever an action related to the customer occurs on the unified platform (e.g. in Payouts API calls). Additionally the Account ID is used to set up SFTP access (if required) and is used to identify reports. |
Funding Account |
Nomupay account, set-up for the benefit of the customer, which holds the funds that result from:
The funding account may hold a single or multiple currencies. For each currency, a balance exists (see Funding Balance). |
Funding Balance |
The funding balance reflects the balances of the funding account. The funding balance is split into three balance types:
|
In-store |
The buying and selling of goods and services at a physical location. |
In-store API |
The in-store API is an integration method that enables Nomupay Customers to access Nomupay’s Payments in-store product offering and process payments transactions via Nomupay’s unified platform. |
Interchange fee |
Interchange fees are paid to the cardholder's bank (the issuer) to cover the cost of processing the transaction. |
Issuer |
The issuer provides the card to the consumer (cardholder) and authorise (approves or declines) the cardholder transactions. |
Ledgers |
The ledger outlines all debit and credit movements, giving full transparency to the customer of all account activity and associated charged fees. Ledgers are available per currency and per EID (Account ID). |
LPM |
A local payment method (LPM) is a payment option popular in a specific country or region, such as a specific digital wallet or bank transfer, that caters to local preferences and infrastructure. LPMs fall under the category of alternative payment method (APM). |
Marketplace/ Platform |
Customer that has their own in-house payment infrastructure and wants to technically integrate with with Nomupay's unified platform to improve their capabilities. A Marketplace/Platform performs all payment acceptance services on behalf of their sellers/merchants (Payments) and is responsible for disbursing (Payout) commissions/earnings to their recipients. |
MDR |
The Merchant Discount Rate (MDR) is the acquiring fees the merchant pay to the acquirer to cover the cost of acquiring the funds from the cardholder. |
Merchant |
Customer wanting to technically integrate with with Nomupay's unified platform and offer Nomupay's product offering to their existing consumers. |
Merchant Funding |
The net payment transaction amount (gross transaction amount minus scheme fees, interchange fees, acquiring fees and any other applicable charges) which is paid out to the merchants bank account. While settlement covers the transfer of funds between the issuer bank and the acquiring bank, the merchant funding refers to the transfer of funds from the acquiring bank to the merchant bank account. |
MID |
Merchant ID (MID) is a unique identifier assigned to a merchant to facilitate payment transactions. |
Path |
Nomupay product which offers a combination of Payments and Payouts. In this solution, the customers funding balance can be fed by funds related to successfully executed payment transactions as well as by bank transfers made by the customer's organisation or 3rd parties chosen by the customer. The available funds are consequently at the customer's disposal to payout recipients of their choice in various countries using different payout methods. |
Payments |
Nomupay product which offers ecommerce and in-store acceptance processing in various countries using different payment methods. The funds related to successfully executed payment transactions are feed to the merchants funding balance and as soon as the funds are available, they are automatically paid out to the associated bank account. |
Payment Acceptance Funding |
Payment acceptance funding are funds related to successfully executed, cleared and settled payment acceptance transactions, which are made available on the merchant's funding balance. In the Payments solution these fund are automatically paid out the merchant's nominated bank account. Whereas in the Path solution the funds are made available on the merchant's funding balance and are only paid out when the customer triggers a payout instruction. |
Payouts |
Nomupay product which offers a disbursement solution where customers, and 3rd parties chosen by the customer, can feed the customers funding balance via bank transfers. The available funds are consequently at the customer’s disposal to payout recipients of their choice in various countries using different payout methods. |
Payouts API |
The payouts API is an integration method that enables Nomupay Customers to access Nomupay’s Payouts product offering and trigger payout instructions via Nomupay’s unified platform. |
Payout Instruction |
Customer triggered instruction to payout available funds to recipients. |
Pending Balance |
Funds deposited, which failed the sanctions screening, and are currently undergoing a more detailed risk assessment. These funds will remain pending until they are approved by the additional assessment. |
PID |
Partner ID. Reseller partner customer types are provided with a unique Partner ID. Partner IDs are formatted with the prefix "PID" (ex. PID-1234567). In the Payments solution, the Partner ID is used for setting up a partner's SFTP access (if required); it is also used to identify reports and to associate merchants with their reseller partner. |
PMT |
Payment ID. Every payout that is initiated on Nomupay’s unified platform is assigned a Payment ID. Payment IDs are formatted with the prefix “PMT” (PMT-123456), and is referenced in Payouts API calls. |
Portal |
Graphical User Interface (GUI) giving Customers access to their data processed via Nomupay’s unified platform. |
Recipient |
Party who has a contractual relation with Nomupay's customer, either as a vendor, supplier, seller etc., and to whom the customer on a regular basis needs to distribute funds. |
| Recipient Payout | Outgoing funds which are paid out from the available balance to the recipients bank account or wallet. The activity to transfer the funds is triggered by the customer. |
| Referral Partner |
Customer that has a network of merchants (or other customer types) that they wish to refer to Nomupay. Referral partners do not technically integrate with Nomupay's unified platform themselves, rather, they assist the Nomupay team with relationship management and defining the proper solution. This could include consultants, industry associations, etc. |
| Reseller Partner |
Customer wanting to technically integrate with Nomupay's unified platform and resell Nomupay's product offering to their existing merchant base. This could include:
|
| Reserved Balance | Balance which is reserved as a security against legal liability. Note this only applies to Payments and Path for customers with a certain risk profile. |
Scheme fee |
Scheme fees are paid to the card network (like Visa or Mastercard) for its services and network infrastructure. |
Settlement |
Settlement is the process where the issuing bank transfers the transaction related funds to the acquiring bank, via the card scheme. Settlement takes place after clearing, and before merchant funding. |
Settlement Account |
Nomupay account, set-up for the benefit of the customer, which holds the funds that result from settlement of Payments transactions. The settlement can relate to card scheme settlement or 3rd party settlement (e.g. APM providers). |
SFTP |
Secure File Transfer Protocol (SFTP) is a network protocol for securely accessing, transferring and managing large files and sensitive data. Nomupay uses SFTP, email and the Customer Portal to deliver reports to customers. |
SID |
Sub-Account ID also referred to as a Recipient ID. Every recipient that a customer plan to disburse funds to must first be onboarded to Nomupay’s unified platform. During this process, each recipient will be assigned a unique Recipient ID. Recipient IDs are formatted with a prefix “SID" (SID-123456), and is referenced in Payouts API calls. |
TRM |
Transfer Method ID. Every unique transfer method that is associated with a recipient on Nomupay’s unified platform is assigned a Transfer Method ID. Transfer Method IDs are formatted with a prefix “TRM" (TRM-123456), and is referenced in Payouts API calls. |
Unified Platform |
Covers the full Nomupay product offering of pay-in and pay-out solutions through a single contract, simple API integrations, and a unified back office. Nomupay’s unified platform can cater for different solutions:
The unified platform ensures that the processed data is aggregated and normalised across all regions, channels, payment – and payout methods, and exposes the data via reports and the Portal. |
Virtual Accounts |
Allows each customer to have their own (virtual) IBAN, per currency, per country and per EID (Account ID). |