Credit Card Processing for Startups

Online commerce, electronic payments, and credit card processing have become fundamental aspects of today’s economy. As a result, almost all startup companies need to decide, how they are going to process payments for themselves or on behalf of their clients.

People often tend to ask questions like: “What are the best payment processors?” (sometimes “What are the best online payment processors?”), “What is the best payment processor for accepting micropayments?”, “What is the best processor for honest pricing?”, “With regards to fees, what is the best payment processing service for a SaaS company with a low monthly price ($5 per user per month)?”, “What is the best Payment gateway for Java which can only validate cards without posting any charge on the card?”, “What’s the best payment gateway for an online factoring invoices marketplace?” etc. In fact, there are no universal answers to these questions, as the situation is a bit more complex and context-dependant. In our article we are going to explain why, and provide some guidelines, which startup businesses can follow to find optimal solutions for themselves.

As we wrote in “Payment Gateways” series, when you are choosing a potential solution to implement, before you look at credit card processing costs, associated with a particular gateway, you need to understand, whether it supports all the functionality you need.

Let us list the fundamental questions, which are relevant for you as a startup company.

Fundamental questions regarding credit card processing

  • Do you need to process payments for yourself only, or do you need to process payments on behalf of your clients (i.e. do you need to function as a payment facilitator)?
  • Do you need only card-not-present (CNP) solution for online recurring payments, or is card-present solution (EMV) also necessary?
  • Do you need to support multiple currencies or not?

In many cases before thinking about your pricing options, you need to verify, whether the listed functions are supported, and whether the gateway supports your MCC code. Beside that, if you are trying to get a merchant account abroad, you need to check, whether you can get it with the gateway you are planning to partner with.

For example, if you are an Indian merchant, trying to get a merchant account in the US, you need to check, that you have all the necessary documents to be underwritten in the US. In the very least you must have a tax ID in the US.

Then (as we’ve mentioned), you need to verify the MCC code and check, if the logic you need is available within the gateway.

As a result of this analysis, it may turn out, that your choice of payment gateways/processors can be reduced to one or two payment platforms.

Reality check

Before addressing a particular payment gateway or processor, you can also perform a “reality check”. Keep in mind that a processor’s revenue amounts approximately to 1% of your processing volume. So, if your processing volume is $ 5000, the processor gets $50. For such a modest reward processors will not offer you complex or customized solutions.

True, Stripe and PayPal may seem to be costly solutions for your business. However, if your processing volume is not very high yet, they may be the only solutions available in your case, because they have a well-developed infrastructure, allowing them to work with the so-called micro-merchants. Larger processing companies may not have such an infrastructure.

Card-present solution

If you need a card-present solution, it is important to analyze the technology you are planning to implement, the upcoming integration, and the cost of devices you are going to use. You should also verify, whether you have all the necessary EMV certifications.

PayFac model

If you need to function as a payment facilitator and issue merchant accounts, then you should pay attention to merchant onboarding and underwriting rules, adopted by your potential processing partner. You should also check, whether your potential partner has some API in place, which allows to simplify onboarding of new merchants.

Availability of starting capital

Being a startup, you may have the funds, allowing you to rent a payment platform for your business needs. If you have both money and time, you can even develop a processing platform using your in-house development team. Finally, you can license an existing white-label payment gateway solution, as we explained in our previous articles.

In these latter cases you can expect lower processing costs, but you will have to pay for support of the necessary infrastructure.


If you have neither the starting capital, nor processing volume, you should not try to find the “cheapest” credit card processing solution, because you are getting what you pay for. If the profit the processor gets from your transactions is low, you are going to be treated accordingly.

In these cases it might be more secure to pay slightly higher processing fees, but partner with a company, which offers robust technologies and has no funding delays. If you save 25 cents on a transaction, but then find that your account is suddenly frozen or closed, it is not a preferable option.

EMV Compliance: How to Become EMV Compliant

Nowadays, more and more merchants are becoming concerned with the problem of EMV standard implementation. These merchants are looking for the most suitable EMV solutions. The purpose of this particular article is to provide some guidelines, which will allow merchants to solve EMV compliance related problems.

The concept of EMV compliance is relevant for merchants, whose facilities are equipped with devices, needed for accepting of EMV payment cards. Depending on the size of a merchant (its transaction volume), its operations model, and industry type, several approaches can be used by the merchant to become EMV compliant.

Your EMV compliance implementation strategy will depend on particular payment terminal solutions, used by your business. Conceptually, there are three scenarios a merchant can follow to become EMV compliant.

EMV compliance for different merchant types

In this section we are going to consider several merchant types, starting from simpler ones, and moving on to more complicated models. Specific steps to be taken by the merchant on the way to EMV compliance will depend on the type of payment terminal solution this merchant uses.

Standalone terminal solution case

Let us consider a merchant business (say, a retail shop), which uses either no terminals, or a standalone terminal solution, provided by the MSP. The terminal is used as a standalone device, which accepts payments, and is not integrated with the POS system. After a payment is accepted by the terminal, it should be registered in the main POS system that is used as a primary system of record.

Consequently, the current solution can, potentially, be replaced by any similar standalone terminal of the same class, which supports EMV standard. So, in order to become EMV compliant, such a merchant should address its current MSP, and verify what EMV options are available (the simplest strategy for the merchant). If the current provider cannot offer any EMV options, the merchant can address other MSPs, which offer similar pricing conditions.

Integrated terminal solution case

Let us now consider the case, when the merchant (say, a large network) already uses some payment terminal solution, provided by the MSP, and the merchant’s POS system is already integrated with the existing payment terminal solution.

In this case it would be desirable for the merchant to resolve the issue of EMV compliance with its current MSP. However, if it is not possible, then the merchant has to search for an alternative solution, taking into account all the intricacies of potential new integration.

As the process of implementation of a new terminal solution involves integration of POS system with payment terminal(s), the merchant should devise the integration strategy in advance. As we wrote previously, the strategy involves several critical issues, such as:

  • Hardware to be used
  • Functions it should perform
  • Terminal fulfillment mechanism
  • Payment types to be handled
  • Required terminal solution types

A detailed description of EMV terminal solution implementation strategy is provided in the respective use case.

Proprietary terminal solution case

The third case concerns a merchant, which developed its own payment terminal software using its own development team. In contrast to the merchants, described in the first and second subsections, this merchant cannot use any other solutions from any MSPs, because it has its own application, supported by its own designated personnel. This application has to be certified by the merchant with the current processor.

In order to keep using its current terminal application, the business (merchant) needs to go through EMV certification process. As part of the EMV certification, the merchant will, most probably, have to perform the following steps:

  • address its current processor
  • buy the respective product
  • perform integration at server level
  • add the respective logic to the payment terminals
  • purchase EMV certification toolkit
  • go through EMV certification process, as described in the respective article


In order to achieve EMV compliance, you need to decide, which type of merchant your business belongs to. This will allow you to define the scale and the main phases of the process of becoming EMV compliant. If you follow all the necessary steps carefully, EMV compliance will open an opportunity for gaining new benefits.

Implementation of EMV Payment Terminal Solution


Many companies at the modern merchant services market are looking for an optimal card-present solution to implement. Some of these companies are expanding or re-organizing their activities (a step, which often leads to the need to choose and implement a payment terminal solution). Others are newcomers, which want to accept both card-present and card-not-present payments.


A company is looking for a universal card-present solution to implement. Either it can be a new solution, which is to replace an old one, or it can be the first card-present solution to be implemented by the company.


The problem is relevant for several categories of businesses:

  • existing companies which already have a card-present solution in place, but want to replace it with a better one (possibly, in response to EMV liability shift)
  • existing companies, which previously dealt only with card-not-present transactions
  • startups that require card-present solutions
  • Strategy

    In order to implement a card present solution in the most reasonable and adequate way, your company needs to take the following important aspects into account.

    What hardware should be used in the new payment terminal solution? Which payment terminals are to be used? What functions should they be capable of performing?

    In order to answer these questions, you should analyze your business situation, the needs of the merchants you are going to service, as well as the price these merchants are willing to pay for the new terminals.

    For example, you might need the cheapest monochrome screen terminals or high-end 7-inch touch-screen ones with the most advanced functionality for your particular case.

    Keep in mind, that payment terminal market is an oligopoly, i.e., it includes only few large vendors, so your choice may be limited. Beside that, most companies’ offers may be quite similar.

    Do you need mobile solutions?

    Some companies offer solutions for both payment terminals and mobile POS systems. Maybe, it might be advantageous for you to deal with such a universal vendor, rather than to involve different vendors for different kinds of solutions.

    Which payment types do you need to handle?

    Do you need EMV contact and EMV contactless payments or are you going to deal only with encrypted swipe payments?

    Do you need standalone or integrated payment terminal solutions?

    Remember, that a payment terminal is just a hardware unit and different kinds of software can be installed on it. While terminal manufacturers (such as Ingenico and VeriFone) offer their own terminal applications, alternative payment terminal solutions are also available from third parties. Such third-party software products may be more suitable for your particular situation, than the software, developed by the terminal vendors themselves (for which you need to pay separately anyway).

    Depending on the type of payment terminal solution that you need (standalone or integrated), you need to evaluate the available software options according to the following three criteria:

    • Quality of user interface. I.e. how the software looks, works, and performs its intended functions inside the terminal (button sizes and colors, supported languages etc.).
    • Ability of the terminal application to communicate with the payment gateway. Some vendors offer terminal applications which are “strategically tied” only to their partner gateways. The question is, thus, whether the terminal application, that you are going to use, is already (or can be) connected to the payment system you need to interact with. You should also avoid situations when in order to deal with different processors you have to use different types of payment terminals and terminal applications, as the process may become too complicated to manage. In other words, your terminal application must be able to smoothly communicate with all back-end payment systems you need.
    • Ease of integration of a payment terminal with the POS system. Many companies still offer legacy integration strategies, which require either installation of DLL libraries or Windows service on the workstation. Both these solutions present deployment challenges, especially, for web-based applications. Beside legacy strategies there are other available options, such as cloud solutions (offered, for instance, by UniPay Gateway).

    As you can see, your choice of a particular terminal solution will not depend so much on the physical hardware and its price, as on the availability of your preferred terminal application on particular terminal models, or on support of a particular payment gateway by the terminal application you want to choose. For example, if your bank or payment gateway tells you that you can only use Ingenico, it makes no difference if you find Verifone more suitable for your business.

    Fulfillment strategies

    One of the most important aspects to consider is payment terminal fulfillment. I.e., who will be loading the new terminals and shipping them to your merchants. There are several options possible.

    You can buy a batch of (say, a 1000) terminals from a vendor or manufacturer, and then use an internal team to inject the respective keys and terminal applications into them as they are shipped to merchants (in smaller quantities). This process requires a whole infrastructure. Although this option is plausible for some companies, most businesses choose to delegate terminal fulfillment to special entities. Consequently, you can partner with a fulfillment center that will install software applications on the terminals, service the terminals, and handle terminal replacement.

    When choosing a fulfillment center, you should consider the following issues:

    • what it costs to buy a new terminal or replace an existing one; what the shipping rates are
    • which software applications (custom software packages) can be loaded
    • which terminal models it supports
    • with which processors it has agreements for PIN key injection (as it needs to be able to inject respective encryption keys), and in which countries
    • if you need some particular terminal application to be installed on your terminals, you should check with the fulfillment center, if it is able to install this application for you.

    When you find a fulfillment center, which is suitable for you in terms of pricing and servicing conditions, and a terminal application, which supports the payment gateway you are (or are going to be) partnering with, your choice of payment terminal solutions may become very limited.


    You have done a market research and realized that your options include Ingenico iSC 250/480 or VeriFone MX 915/925. However, in order for your terminals to be able to interact with your payment gateway, you need a special terminal application. Only two fulfillment centers are able to install this particular application, and only one of them deals with the three processors, whose keys you need to inject. This fulfillment center supports only Ingenico terminals. In this situation there is no point in some in-depth analysis of specifications and price offerings of VeriFone, as Ingenico turns out to be your only choice.

    EMV certification (if necessary)

    If you need to support EMV standard and keep using your own payment platform, you will need to integrate your terminal solution into an existing payment ecosystem (i.e. integrate your terminals with an existing gateway). This means that you need to go through EMV certification process.

    Remember, that each EMV kernel, installed on devices, which you are using within your solution, must be separately EMV-certified. Consequently, in order to simplify EMV certification process, you need to minimize the number of EMV-kernels on your devices (including EMV-kernels provided by one and the same manufacturer/vendor).


    A company wants to work with a certain number of models of terminals and mobile devices. Some mobile devices are using the EMV kernel which is used by payment terminals, while other mobile devices are using a different EMV kernel. (For instance, Ingenico uses both its own mobile solutions and solutions, developed by ROAMpay before its acquisition by Ingenico). In this case the company has to certify two EMV kernels, i.e. go through two certifications.

    In order to minimize the number of EMV kernels and, thus, reduce time and cost of EMV certification process, you need to verify, whether all the devices you are going to use, are made by the same manufacturer, and whether one and the same EMV kernel is installed on all the models of these devices.


    Many newcomers in the merchant services industry erroneously think that selection of a card present solution starts with the analysis of available hardware options. Selection of hardware, in fact, may be the last phase of the process. You should, definitely, know the names of the key hardware brands. However, a decision, based only on hardware specifications, may result in a costly error. The key factors to be considered first and foremost often include terminal application compatibility, support of the necessary gateway integrations, number of necessary EMV certifications (if they are needed), and preferable fulfillment strategies

EMV Parameters and EMV Keys Rotation

The purpose of this article is to explain why EMV parameters and EMV keys rotation are an essential component of EMV certification process.

The general assumption is EMV certification process includes just two basic stages: host certification and terminal certification. Respective information can be found in our respective articles here and here. However, there is another process which is also required to ensure normal functioning of EMV processing logic.

Somehow this third process is often neglected and many developers realize its importance at late stages of EMV functionality implementation. This can lead to considerable shifts of implementation deadlines. In this article we are trying to explain the essence of the process and help those who need to implement it when the time comes. The issue is particularly relevant for those who want to support more than one acquirer.

In order for EMV kernel logic embedded in payment terminal software to function properly, it needs a set of EMV application parameters and certificate authority (CA) keys. The CA keys are involved in the interaction between the EMV kernel of the terminal and the chip.

Quite often (for example, in Verifone and Ingenico terminals) the EMV kernel is going to use XML configuration file. The file includes the information on application IDs (AID), which are going to be supported by the terminal, respective parameters and keys for these AIDs.

EMV parameters are not changed very often (if changed at all). Most processors provide these parameters in pdf format. Usually, a pdf file is a contextual document, where they can be found. On their basis an XML file can be assembled.

Importance of EMV keys rotation: EMV certification perspective

In contrast to parameters, CA keys have to be changed (rotated) regularly. Most processors usually provide some sort of API (as a rule, it is a part of the main processing specification), including a subset of functions, dedicated to loading of the CA keys. Some processors will provide the initial set of keys through a document and require you to load updated keys using the API. Some processors will tell you initially to get all the keys by making a respective API call. Therefore, it is important to allocate time and resources for the implementation of this logic from the very beginning of your project planning, because there is no equivalent for this in card-not-present integrations or swipe integrations.

As we can see, in addition to host integration and terminal integration (with subsequent certifications), you also have to implement the rotation procedure for CA keys. Some of the processors will leave it up to you to implement this and will not require you to formally certify the process. Some of the processors (such as Chase Paymentech) will actually require you to demonstrate (during the certification process) that you can dynamically change the keys as transactions are getting processed.

Generally, the functionality around key rotations is appropriate for payment terminal management systems (TMS), and the function will be available in the TMS that you use. However, if you are not using any TMS, or TMS is unavailable for you, you can implement the respective logic as part of payment gateway functionality. The implementation process will depend on the number of different processors that you support and on the differences between application parameters (such as floor limit) across payment terminals. Implementation can be as simple as a file download from a server over FTP, where the file gets re-generated every time you get a different set of keys from the processor. It can be as complex as an API call where terminal identifies itself and then terminal-specific configuration file is assembled based on the most up-to-date information available from the processor that this terminal uses.


It is extremely important to allocate the time and resources for implementation of EMV keys rotation logic even for the most basic EMV certification. Even if you are not required to present the logic at certification stage, you are definitely going to confront the issue during production. While expiration period for a some of the keys can be up to 24 months, you will not necessarily have all that time before the initial key rotation has to be done.