1. System
  2. Compatibility with other systems
  3. GUI
  4. Performances
  5. Modularity / Scalability
  6. Security and access control
  7. Clients
  8. Cards
  9. Risk management
  10. Merchant
  11. Terminals
  12. data restore and backups
  13. Transactions

1. System

what kind of hardware does the server side require ?

it will depend on the server load and the business, but generally as a standard configuration we propose:
- 16GB RAM
- quad core 2.4
- 2*500 GB hard drives running in parallel

what kind of OS does the server require?

All Unix-like, Linux-like or Windows-like OS', all releases.

what kind of Database does Card24 require?

Card24 is base on JDBC, it could communicate with all known databses

what kind of application server does Card24 require?

Card24 is compatible with all J2EE application servers, including Tomcate, JBOSS, WebSphare etc..

what are the user side requirements ?

a simple PC, with whatever webbrowser (Internet Explorer, FireFox, Google chrome, Opera etc…). The system could be also accessible form the smarthones.

is the system accessible from smartphones ?

yes, it could be accessed from the web using smartphone, espcially for customers where the display will be different and adapted to the mobile device. Moreover there are smartphone applications available for specific and easy to use taskes.

2. Compatibility with other systems

what are the supported protocol?

- ISO8583
- WebServices
- ISO7816
- other propertary protocols
- all file formats

Integration with other systèms?

So far card24 was able to integrate to standard firms using the ISO8583:
- Finacle
- Rubikon
- Shetab
  and other systems using other protocols:
- BankMaster
- other propertary systems
  and also attacking directly the database for some systems that are not able to communicate.

how long does it take for an integration to an existing system?

if it is based on ISO8583 (whatever version) or file (whatever format), it is only matter of configuration, if the technical specification is clear enough the integration could be done in one day.

Integrated with e-mail application (Microsoft Outlook)?

Card24™ can send emails or SMS upon events

Data import/export from Microsoft Office applications ?

All data provided by Card24 could be extracted in Excell or PDF format, the report generated could also be generated in both formats.

Please indicate the main components of system architecture (for example terminals, communication server, operational center e.t.c) with the description of communication channels between the components (if it is possible attach the diagram with system architecture).

Card24™ system run under a genral SOA architecture, different modules communicate between them using the webservices. The Database that we use generally is Oracle or MySQL, the application server could be Jboss/Tomcat or other (we are also independent from the application server side and could run on any application server java based). card and transaction security (CardShield module) could be connected to a hardware security module (in general THALES HSM). Card24™ could be accessible using a simple web browser such as Firefox, Google chrome or Internet explorer. thus the only workstation requirement is to be equipped with the latest version of the above listed web browsers.

3. GUI

Ability to support browser

Internet Explorer, FireFox, Opera, etc.

Ability to support a user-friendly graphical user interface (GUI)

Card24 is user friendly web interface

Ability to support HTML

Card24 is web based.

Ability to customize screens.

Screens are made in JSP which is open

foreign language support

Card24 supports multi languages (left and right aligned)

multiple calandars support

Gregorian, Persian, and Hijri

Provision of short cut key strokes for data entry

short cut keys are configurable dynamically

ability to check the formating of fields

Card24 can check several format as standard checks:
- email address
- number
- date
- etc...
it can also be customized to check other formats such as the National ID or others

Ability to inform users of pending changes to be saved when switching to another module

Card24™ prompts the user to ask for saving the changes on any action beyond the scope of the changes.

Ability to allow suppression of appearance of menu items where function not required or not allowed to user

Menus are configurable, and not hardcoded. Furthermore, menus are accessible/visible to users according to their access rights.

concurrent access to records

Card24 detects the changes made to a record by users and inform the other users when updating

keeping working data while loged off

in the case of timeout you can still continue working on the same data you started capturing by loging in again, the user will remain at the same page while loging from a popup.

Ability to import and export information in Microsoft Office applications.

all data provided by Card24 could be extracted in Excell or PDF format, the report generated could also be generated in both formats.

System shortcuts and ‘hotkeys’ to functions are also subjected to the same access restrictions as normal menu access

4. Performances

Possibility to support 500 users

Possibility to support 1,000,000 cards

Possibility to support 10,000 terminals

Possibility to support 1,000,000 transactions a month

howlong does a transaction take?

less than 200 miliseconds

5. Modularity / Scalability

System modularity (possibility to select and implement only required functional)

Possibility for further scalability (increase of users, transactions, communication channels with regions, network bandwidth, cards, terminals)

done only by configurable

6. Security and access control

Is your system PCI compliant


Periodic Key change

Encryption mechanism:


Network access logging and network activity tracking


System events and failure activities, automatic alert (failure) sending


Ability to maintain an audit trail and time stamp for all user activities.


Audit log required for any changes to table information which is used by the system in any way--before, after, change, date, and who.

All information changed by the user are logged in XML format inside a table which doesn’t have any GUI interface for more security, those records contain the table record before change, after change, date, and user id of the user performing these updates or deletes, in addition all functional data tables have field to indicates batch id and batch time of the batch operating on them. Thus, any operation can be tracked and the system can be restored to its state prior to it.

Ability to log un-successful / successful access attempts as well as activities


Restriction of access to the system logs (no possibility to change system logs)


Ability to provide appropriate security for user creation / modification

Each user has a profile which determines its security level and configuration

Password policy


User access rights separation (access authorization)/system actions separation(access authorization)


Does the system provide per system-user limits on specific data, such as credit limit affected to a cardholder could not be set to a certain value by a user as his limit forbid him?


Four eyes principles

the system supports multiple level of approuval depending on the workflow setting (completly parametrable)

Failure access attempts to application objects reports generation


System architecture restrict access to the user and systems accounts passwords (no possibility to review user passwords within the system settings, stored passwords hashing)


Possibility to restrict access based on IP/sub network user accounts/network user groups


Possibility to block IP/sub network user accounts


7. Clients

Personalize client accountability (common client database)

Client data gathering via WEB-portal

Mobile application for customers

Client account management via Internet or mobile: reporting, limits configuration and others

Ability to automatically alert customers through SMS or email when predefined limits are exceeded


Ability to alert customers through SMS or email when cards are used


Ability to access transactions reports online


Automatic client/account numbering

Based on parameters you can configure the bank's stategy of number generation

Automatic check numbering


market advantage

Sending personnel messages to your customers or group of customers: birthday, change of address or phone numbers, requesting an appointment…

Ability to obtain and maintain the customer's statement electronically

YES, and they are accessible from the WEB


YES, complitely parameterable and could be done from the GUI or via Batch

8. Cards

instant issuing

data preparation and personalization, in the case of propertary javacard application the load of the javacard application is also done by Card24

Card personalization (formatting), cards logistic (personalization, delivery and receipt reporting)

Bulk card generation

the system can generate anonymous cards (such as gift cards)

Possibility to set restrictions on card usage:

- transaction type
- number of attempts
- time
- point of sale (geographical/certain amounts of service points)"

Card limits

we can define the limits (depending on the product) on :
- the account level
- the card level
- the client level
the limits could be also defined per type of transaction and depending acquiring interface and merchant.
limits could be also defined per day or per periode."

Possibility to use different loyalty programs with different rates depending on the card product and the transaction type

Automatic card numbering

Based on parameters you can configure the bank's stategy of number generation

PIN codes generation and printing based on cryptographic algorithms and secret amounts

Plastic types

you can define the standard type and add more types:
- Classic
- Gold
- infinite
- world
- business"

what are card types supported by the system?

- Debit
- Credit
- Prepaid
- Fuel
- Salary
- e-purse
- campus
- Gift
- loyalty
- etc


9. Risk management

Card, Client and Account status management, service conditions, risk-parameters

Client limits management

Card usage frequency limitation (minimal interval/gap between processing one card twice identification)

Transaction traffic analyses (Geographical variance/time) to prevent financial losses and fraud operations

issuer scripts management : PIN change, cards blocking, etc.

On-line and offline "Stop-list" actualization and processing

Client verification methodes

Possibility of cards analyses/searching based on defined criteria (frequency of usage, intervals between usage, statistics of usage based on geographical criteria, average values per period and others)

10. Merchant

what are the merchant level supported

- chain
- merchant
- outlet
- terminal"


what are the merchant types supported

- virtual
- transactional"

multi-currency acceptance

the system supports the multi-currency acceptance at the merchant and also allow the settlement to different accounts with different currencies of the same merchant.

merchant contract management

merchant application management

merchant customer services and helpdisk

transaction and processing management

Dispute processing and management

interchange/ commission

different types of commission for the same pos, outlet, merchant, chain ,etc, by currency, on-us cards, off-us cards, on specific prefixes, by network Visa, MC, AMEX…

fraud management


merchant payment methods

- cheque
- transfer
- cash
- swift
- etc."




11. Terminals

What are the supported channels

- Kiosk
- Mobile phone

What are the accepted card's type

- JavaCard
- Magnetic
- NFC and contactless

What are the Different communication channel supported

- Ethernet
- Bluetooth
- Serial cable

Possibility to process cards off-line in case of communication channel failure or absence of access to the processing center

Possibility to change terminal configuration (including remote change from processing center)

Possibility to download the stoplisted cards, BINs, card ranges etc.

Possibility to download limits and fees for offline processing

sending transactions' batch at the end of day

this is optional for the online transactions, but mandatory for the offline ones, in the case of connection problem the POS can retry and send only the remaining transactions.

Possibility to download the POS application remotely

12. data restore and backups

Ability to support daily purging

Ability to support scheduled purging

Ability to maintain secure logs of purging activities

Ability to maintain audit trails

Ability to perform system clean-ups

Ability to perform daily back-ups

Ability to support hot sites - real time online back-ups

Ability to perform database back-ups

13. Transactions

What are the supported online and offline transactions?

- Account selection
- Withdrawal
- Fast cash
- Purchase
- Purchase with cash back
- Fuel purchase (individual/corporate) (littre/currency) (petrol/gasoil)
- Loyalty points redemption
- Deposit
- Cash advance
- Balance download (E-purse) (online only)
- Reversal
- Adjustment
- ChargeBack
- Transfer
- pré-authorization
- Mini statement
- Balance enquiry
- Airtime purchase
- Bill Payment
- Credit Purchase
- Saving upload
- PIN change
- PIN reset
- Card activation
- Cheque book request
- Loan request
- key exchange
- reconcillation messages
- and others

What are the supported Backoffice transactions?

- Purchase
- Purchase with cash back
- Fuel purchase (individual/corporate) (littre/currency) (petrol/gasoil)
- Loyalty points redemption
- Deposit
- Cash advance
- Reversal
- Adjustment
- ChargeBack
- Transfer
- Airtime purchase
- Bill Payment
- Credit Purchase
- Saving upload
- Fees
- Standing orders
- Installment transactions
- Penalty"

what are the notifications supported by the system

- transaction upload
- terminal user update/add
- loyalty point calculation changes
- stoplisted cards attempts
- cash level
- hardware issue
- innactivity period
- echo test
- messages

Authorization/transaction matching.

the system matches the transactions based on several parameters, the system generates reports of unmatched authorization, the system also provide the possibility to manually match or purge the transactions.

transaction fees

the fees could be generated based on several criteria:
- transaction type
- card product
- account profile
- merchant profile
- etc.

standing rules

- Card ranges,
- Product,
- On Host status,
- Scheduled Off Host status,
- Unscheduled Off Host status,
- Transaction origin.
- etc.

switching rules

- Transaction type
- Card ranges,
- Product,
- Host type
- Transaction origin.
- merchant profile
- etc.

bulk transactions

the system allow to send transactions in bulk from the GUI or by uploading a batch file