Card Issuing

Cards

All virtual cards are issued activated. Virtual cards can be converted to physical via API. Upon conversion all card settings and PAN will be preserved the expiry date and CVV will be changed.

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.

Cards can be personalized and non-personalized.

• The personalized debit card is assigned to a particular customer being it business or consumer.

• A non-personalized debit card is not assigned to a particular customer. Such cards are often used for one-time or temporary purposes, such as gift cards, event cards, or travel cards and in most cases have a specific amount pre-loaded, and the very card is not reloadable. As we are not allowed to issue anonymous cards, such cards are always assigned to a consumer or business customer.

Shared and Dedicated ICA and BIN

BIN (Bank Identification Number) - is represented by the first 6 to 8 digits on a card. BIN can be assigned only to payment institutions which are Principal members of a card scheme. ICA is a unique identifier of the issuer of Mastercard. ICA may be connected to only one processor and may be related with one or multiple BINs.

As our partner you can select if you would like to go with a shared BIN or own one:

Shared ICA/BIN

Shared BIN is usually the preferred way to go for our partners because of its faster implementation and cost efficiency – you do not need to apply for a new BIN and implement hefty fees to onboard it on processor and on Apple and Google Pay. Some of our shared account ranges under certain BINs are Apple and Google Pay enabled.

Own ICA (only for Mastercard)

Mastercard invoicing is on ICA level. If you have your own ICA, you can have a separate billing with Mastercard.

Own BIN

Own BIN gives the same advantages for Visa cards similar with ICA for Mastercard.

For both card schemes, own BIN brings the flexibility to move to another issuer without needing to reissue all your cards. Both BIN and ICA can be moved to another processor and have separate billing. However, own ICA/BIN requires significantly more resources and time to onboard. Most of the partners are starting with shared BIN and just some of them move to their own and only when generating significant volumes.

Card currencies

We issue cards only in the currencies we can provide settlement in. Currently the set of supported currencies are EUR, GBP, BGN, USD is supported for Mastercard only.

Multi-currency cards are not supported, and you cannot link a card to a multi-currency account.

Card Design

You can choose your own bespoke card design - your logo, your colours, your card art. Paynetics branding is not seen anywhere, except in the Terms and Conditions and the back of a physical card, as a regulatory requirement. However, ordering and producing physical cards with bespoke design can take around couple of months for reasons outside of Paynetics.

Bespoke card design must comply with guidelines and to be verified by the respective scheme.

A cost efficient and fast way to start with physical cards is to use our pre-approved and pre-printed cards with our default all-black design and have your monochromatic logo printed on them.

3DS Management

You can use two types of 3DS authentication:

• OTP (One-Time-Password) by SMS. For this method you would need to have the phone number of the end-customer set.

• Biometric authentication: can be integrated within your mobile app. Your system should consume a webhook sent by us and display the authorization request to the end-customer together with all data provided in the webhook. The end-customer should be able to reject or authorize the payment using Strong Customer Authentication (SCA). Upon SCA authorization your system should notify us via an API request to verify that your customers have authorized the transaction.

You can select for which method you would like to enroll each card. If you have enrolled for both methods, the biometric one will be with higher priority.

When a card is enrolled for both methods, it does not mean those can be switched on the fly. Once a 3DS authentication request is received it needs to happen with the selected method. You cannot start an authentication with Biometrics and if it fails try and confirm payment with SMS OTP. Changes to used method will be valid for the next operation the card will do, not the ongoing.

Physical cards manufacturing, personalisation, and distribution

Paynetics is pre-integrated with Thames (Europe and the UK) and Borica (The Balkan region). We are open to considering adding a new provider for card personification upon your request.

The minimum order amount for physical cards is 1000. We can refer you to manufacturing partners who can provide a variety of options from standard physical cards to more exotic, like metal and wood. The manufacturing time usually takes about 2 months, it's important to note that this is outside of our control.

Cards personalisation takes between one and three business days depending on the capacity of the card personalization bureau.

We can help you with arranging a card delivery partner.

Shared and Separate Cards Balance

One card can be assigned to a single account only and one account can have assigned only one card to it. If you would like to have more than one cards sharing the balance with an account, you will need to create a virtual account linked to this account and assign a card to it. It’s important to note that in this case the card linked to the payment account will be set as a “main card” and the ones linked to each virtual account would be linked to the main card.

The other option is for each card to have a separate balance. In this case you create a payment account for each card and upon issuing assign the card to the account.

Cards Statuses

Active

Active cards can be executed for the allowed operations set upon configuration of your usage group.

Please be advised that active status is different from card activation. While card activation is a one-time process, card status can be changed between active/blocked at any time.

Blocked

All operations of blocked cards are restricted. A blocked card can be activated back by API or from your Partner Portal.

Voided/Terminated

Card can be deactivated/voided before it expires. In this case the status will be “add status”.

Expired

All operations of expired cards are restricted. Expired cards can be renewed with the same PAN number but with different expiry date and CVV. Reissuing will change the PAN of the card together with the expiry date and CVV.

Card Sensitive Data

Managing card data can be tricky. To have access to such data companies need to be PCI-DSS certified. Our platform enables you to display card data in your product, be it mobile or web application in a secure manner without the need to have PCI-DSS certification. You just need to integrate a PCI compliant SDK pre-integrated with our platform. You will not be able to process or store card data in any way to avoid the hefty certification process.

For card PIN you can use alternative old-school method of sending the PIN to your end-customer by SMS via a simple API call.

Apple, Google Pay and XPays

Some of our shared BINs are onboarded for Apple and Google Pay but there are some certain limitations based on countries and card schemes.

Adding other, less popular wallets may be considered upon your request.

To enable you for Apple Pay you will be required to be registered with Apple as a Program Manager and sign an NDA. Your project manager will facilitate this process with you during onboarding. If you are already live you can always request a change via your account manager.

Push Provisioning

Apple and Google pay push-provisioning was often classified as a delighter, a nice to have feature your end-customers can live without. Customers are now more demanding than ever and enabling Apple and Google Pay with a single tap of a button from your mobile app is now a necessity.

Enabling in-app provisioning, the ability to add a card in Apple and Google Pay by a single tap of a button, usually requires deep understanding of the specifics of card tokenisation. Our push-provisioning SDK eliminates this requirement. It can be implemented within any mobile app in hours, and we can provide complete support on certifying your mobile app to help you beat the competition with superior UX.

Cards Limits and Fees

Fees and limits group are assigned upon card creation. The default values are set based on the program configuration of the account the card is associated with. You can change a card’s group easily via API. Your groups will be set during onboarding.

Groups are created exclusively by Paynetics during your onboarding and by change request after going live. Template of all groups below will be shared during onboarding and your groups configuration will be available under your dedicated shared folder.

Velocity limits

Are determining the single transaction, daily, weekly, and monthly limits and support custom days range. Velocity limits can be set separately for POS, Cash and Load operations. For example: You can set a 3-day limit for POS transaction of 500, e-commerce transaction of 100 currency units daily and ATM maximum transaction limit of 800 currency units and a minimum transaction of 100 units.

Linkage group

Determines if your cards will be with shared balance or not. There is no technical limit to how many additional cards can be connected to a primary card; such will be imposed for risk purposes.

Card usage group

Card usage groups are used to enable or disable certain card operations like ATM withdraws, e-commerce and OCT transactions and can be set separately on domestic and international level. For example: You can block OCT incoming transactions and allow only ATM withdraws at the country of card issuance.

Authentication fees group

Enables flexible controls over transaction fees for all card operations like ATM withdrawals, POS payments, balance inquiries and PIN changes. You can set flat fee and fees as percentage of the transaction volumes.

Recurring fees group

You can set recurring fees which will be applied upon a fixed period (defined in number of days) and will be triggered by configurable events (e.g., card activation, first load, no activity, time after activation, etc.). For example, monthly fee to be applied every 30 days following activation.

MCC (Merchant Category Code) group

You can configure to either allow transactions on a list of MCCs (whitelist) or deny transactions from the list of MCCs (blacklist). If there is no MCC group assigned to the program, then transactions from all MCC’s are permitted.

Note: MCC 5542 AFD (Automated Fuel Dispenser) is blocked by default for all programs but upon risk approval of specific request it can be enabled for the program.

Acceptor groups

Like the MCC groups you can define whitelist and blacklist on MID/TIDs level. If you define a whitelist of MIDs for instance, every authorisation made at merchants outside of this list will be declined. For example, a card attempts to make a purchase on MID 1600010000 but this MID is not on the list – the authorisation will be declined.

Batch Card issuance

Cards can be issued one by one or in case you need to create a bunch of cards at once you can use the batch option.

There are several supported batch formats. A subset of them, depending on your model, will be available at your shared folder. Batch files can be uploaded via your Partner Portal or via an API endpoint.

Transfers

The platform exposes access to a multiple of payment networks and covers all major currencies together with some local ones.