Card issuing

Introduction

Cards are a core payment instrument within the Paynetics ecosystem, enabling customers to access funds, make payments, and interact with both physical and digital commerce channels. Paynetics supports card-based payments across multiple form factors and usage contexts, including traditional card payments and card-based digital wallets.

This article provides an overview of card functionality from a processing and integration perspective. It covers how cards are used within acquiring flows, how merchants are onboarded, which markets and currencies are supported, and how card-based transactions are executed via the Paynetics Acquiring API. Where applicable, the article also describes how cards are used through digital wallet channels such as Apple Pay and Google Pay.

The document is intended for partners integrating card acceptance using Paynetics Acquiring and should be read in conjunction with the relevant API reference documentation.

Card Types

Paynetics supports multiple card types, differentiated by customer type and physical form factor.

Card Issuance and Activation

All virtual cards are issued in an active state. Virtual cards can be converted into physical cards via API. Upon conversion, all card settings and the PAN are preserved, while the expiry date and CVV are regenerated.

All physical cards are issued inactive and must be activated once received by the customer.

Not activated - is the default state of physical cards upon issuing. Cards with this status cannot be used for purchases before activating them. You can activate a card from inactive state via API – in case you would like to enable activation of the card via your user interface.

Personalised and Non-Personalised Cards

Cards can be issued as either personalised or non-personalised.

Personalised Cards

A personalised debit card is assigned to a specific consumer or business customer.

Non-Personalised Cards

A non-personalised debit card is not assigned to a specific end customer at the time of issuance. These cards are commonly used for one-time or temporary purposes, such as gift cards, event cards, or travel cards. In most cases, they are preloaded with a fixed amount and are not reloadable.

As anonymous cards are not permitted, non-personalised cards are always legally assigned to either a consumer or business customer.

Shared and Dedicated ICA and BIN

A BIN (Bank Identification Number) is represented by the first 6 to 8 digits of a card number. BINs can only be assigned to payment institutions that are principal members of a card scheme.

An ICA (Interbank Card Association) is a unique identifier for a Mastercard issuer. An ICA may be connected to only one processor and may be associated with one or multiple BINs.

As a Paynetics partner, you can choose between using a shared or dedicated ICA/BIN setup.

Shared vs Dedicated ICA/BIN Comparison

Shared ICA/BIN

A shared BIN is typically the preferred option for partners due to faster implementation and lower cost. There is no need to apply for a new BIN or incur additional processor and wallet onboarding fees.

Some shared BIN ranges are already enabled for Apple Pay and Google Pay, subject to currency and territorial limitations.

Dedicated ICA and BIN

Own ICA (Mastercard only)

Mastercard invoicing is performed at ICA level. Having a dedicated ICA allows for separate billing directly with Mastercard.

Own BIN

For Visa, a dedicated BIN provides similar advantages to a dedicated ICA on Mastercard.

For both schemes, owning a BIN or ICA enables issuer portability, allowing migration to another issuer or processor without reissuing cards. However, this approach requires significantly more time, effort, and resources. Most partners start with a shared BIN and move to a dedicated setup only after reaching substantial transaction volumes.

Card Currencies

Cards can only be issued in currencies supported for settlement. Currently supported currencies are:

• EUR

• GBP

• BGN

• USD (Mastercard only)

Multi-currency cards are not supported, and cards cannot be linked to multi-currency accounts.

Card Design

Partners may choose a bespoke card design, including logo, colours, and artwork. Paynetics branding is not visible on the card front and appears only where required by regulation, such as in the Terms and Conditions and on the reverse of physical cards.

Bespoke card designs must comply with card scheme design guidelines and undergo scheme approval. Physical card production with custom design typically takes several months due to external manufacturing dependencies.

As a faster and more cost-effective alternative, partners may use Paynetics’ pre-approved, pre-printed cards with a default black design and a monochrome partner logo.

3D Secure Management

Paynetics supports two methods of 3D Secure authentication.

SMS One-Time Password (OTP)

Authentication is performed using an SMS-delivered OTP. This method requires a verified phone number for the end customer.

Biometric Authentication

Biometric authentication can be integrated into a partner’s mobile application. Paynetics sends an authorisation request via webhook, which the partner must present to the end customer. The customer can approve or reject the transaction using Strong Customer Authentication (SCA). Once approved, the partner must confirm authorisation via API.

Cards can be enrolled for one or both methods. When both are enabled, biometric authentication takes priority.

Authentication methods cannot be switched mid-transaction. Changes to the configured method apply only to subsequent transactions.

Physical Card Manufacturing, Personalisation, and Distribution

Paynetics is pre-integrated with Thames (Europe and the UK) and Borica (the Balkan region). Additional personalisation providers may be considered upon request.

The minimum order quantity for physical cards is 1,000 units. Manufacturing typically takes around two months and is outside Paynetics’ direct control. Card personalisation usually takes one to three business days.

Paynetics can assist with arranging delivery partners if required.

Shared and Separate Card Balances

Each card can be assigned to a single account, and each account can have only one directly linked card.

To support multiple cards sharing a balance, partners can create virtual accounts linked to a primary account. The card linked to the primary account becomes the main card, while additional cards are linked via their respective virtual accounts.

Alternatively, each card may have its own dedicated balance by issuing a separate payment account per card.

Card Statuses

Active

Active cards can perform all operations enabled in their assigned usage group. Card status is distinct from card activation and can be changed at any time.

Blocked

All operations are restricted. Blocked cards can be reactivated via API or the Partner Portal.

Voided / Terminated

Cards may be deactivated before expiry.

Expired

Expired cards cannot be used. Cards may be renewed with the same PAN but a new expiry date and CVV. Reissuing a card generates a new PAN, expiry date, and CVV.

Card Sensitive Data

Handling card data typically requires PCI DSS certification. Paynetics enables secure card data display in partner applications using a PCI-compliant SDK, eliminating the need for partners to store or process sensitive data.

Card PINs may alternatively be delivered to customers via SMS using a dedicated API.

Apple Pay, Google Pay, and Other Wallets

Some shared BINs are enabled for Apple Pay and Google Pay, subject to scheme and country limitations.

Wallet Availability by Scheme

Additional wallets may be considered upon request.

To enable Apple Pay, partners must be registered with Apple as a Program Manager and sign a non-disclosure agreement. This process is facilitated during onboarding or can be initiated later via the account manager.

Push Provisioning

Push provisioning allows cards to be added to Apple Pay or Google Pay directly from a mobile application with a single tap. While previously optional, this capability is now considered essential for competitive user experience.

Paynetics provides a push-provisioning SDK that abstracts the complexity of card tokenisation and can be integrated within hours. Full certification support is provided.

Cards Limits and Fees

Cards are assigned to limits and fees groups at creation, based on the configuration of the associated account. Groups can be changed via API.

All groups are defined by Paynetics during onboarding or via post–go-live change requests.

Velocity Limits

Velocity limits define transaction thresholds over configurable time periods, including single transaction, daily, weekly, monthly, or custom ranges. Limits can be set independently for POS, ATM, cash, and load operations.

Linkage Group

Linkage groups define whether cards share balances. There is no technical limit to the number of cards linked to a primary card, though risk-based limits may apply.

Card Usage Group

Usage groups control which operations are permitted, such as ATM withdrawals, e-commerce payments, and OCT transactions. Controls can be applied at domestic and international levels.

Authentication Fees Group

Authentication fee groups define transaction fees for operations such as ATM withdrawals, POS payments, balance inquiries, and PIN changes. Fees may be flat or percentage-based.

Recurring Fees Group

Recurring fees can be configured to apply at fixed intervals and triggered by specific events, such as activation or inactivity.

MCC Group

MCC groups allow partners to whitelist or blacklist merchant category codes. If no MCC group is assigned, all MCCs are permitted.

Note
MCC 5542 (Automated Fuel Dispensers) is blocked by default and may be enabled only after risk approval.

Acceptor Groups

Acceptor groups allow whitelisting or blacklisting of merchant IDs (MIDs) or terminal IDs (TIDs). Transactions outside the allowed set are declined.

Batch Card Issuance

Cards can be issued individually or in bulk using batch files. Multiple batch formats are supported depending on the partner model. Batch files can be uploaded via the Partner Portal or submitted through an API endpoint.