Knowledge Center
You can find more knowledge about fintech and payment products on this site.
- Verestro's Products Overview
- Trends on the Fintech Market
- Why to use Verestro?
- Verestro architecture and choice of products
- Verestro's products for various regions
- What are the Advantages of the Verestro Fintech-as-a-Service Platform?
- Own Payment License or Dependence on a BAAS provider - how does Verestro solve it?
- White-label App vs. In-house App Development
- Mobile App Development Languages Used by Verestro
- Business Control for new or existing portfolios
- What employee benefits can be offered via the Verestro Business Control
- Tokenization and Contactless Payments - Verestro's competitive advantages
- Cashback - Boost Customer Loyalty and Spending
- Understanding White Label Applications: A Beginner's Guide
- How does Verestro differ from standard software companies?
- Card Issuing & Bank Accounts
- Payment schemes
- Ranking of card issuing companies
- Card issuing - financial details
- Example of Profit & Loss calculation in card issuing
- Regulatory and license impact on card issuing
- KYC and KYB requirements in card issuing
- PCI DSS & other security requirements
- Master balance and collateral in card issuing projects
- Pay with Rewards, Pay with Points
- Multicurrency cards - 3 implementation options
- Customer service and user claims in card issuing
- How to prepare for a card issuing project?
- How can I reload a payment account or card?
- Card Lifecycle Management
- VISA or Mastercard?
- Card Benefits in card issuing projects
- Prepaid, debit or credit cards - the main differences
- Tips to avoid problems when implementing card issuing
- Know Your Customer – in-house or outsourcing
- Reverse solicitation – marketing & promotion of card issuing in multiple countries
- Interchange Fees and Service Fees - rates and rules
- BIN Range or Separate BIN in Card Issuing
- Guide to IBAN setup process
- IBANs, cards, balances - how to manage all of this?
- Issuing cards in various currencies
- Payouts to Cards & Money Transfers
- Payout to Cards
- Currency Management in Payouts to Cards
- KYC requirements in Payout and Money Transfer projects
- Various forms of money transfers
- Payouts, eCom Transactions or Card-to-Card Payments?
- Tokenization & Contactless
- Issuer Wallet and Apple Pay / Google Pay - Differences
- NFC on iPhone/iOS
- Pay by Account - NFC from bank account
- On-device tokenization in India
- Push Provisioning Step by Step
- Push Provisioning & Web Push Provisioning
- eCommerce Payment Gateway
Verestro's Products Overview
In this chapter we will present the CEO's view on our products and solutions.
Trends on the Fintech Market
There are various important trends that are impacting the financial technology market at the moment. We try to focus on several of them to stay competitive and propose services which improve user satisfaction, conversion and bring more revenues to our partners. In this article I would like to focus on a few of these ongoing changes:
- Embedded Finance - more and more applications, marketplaces, partners would like to include financial solutions inside their applications. It seems that flexible and not expensive payment solutions are necessary to build a new value proposition in many markets. From lending, through insurance, loyalty platforms, merchants, discount programs, employee benefits - all of them can find useful value in fintech solutions.
- Focus on revenue generation - every financial product must bring value which can be counted in dollars. It used to be expensive to set up a card issuing solution, but it is no longer the case. You can implement and test various financial technologies during 2-3 months. You can have cards with their own visuals, and send money transfers globally easily. Once it becomes easy, all partners focus on solutions that can bring direct revenues per user, per transaction. High cost is no longer a problem today.
- Multi-functionality, multi-acquiring, multi-issuing, multi-processing - there used to be specialised players focused on a particular segment. You had to choose different vendors for card issuing, accounts, money transfer, eCom payments etc. But today it is more and more important to find partners that can offer various solutions, provided by multiple banks, multiple processors under a single roof. Connections between various products bring the most value as thanks to it you can build more sophisticated use cases
- Fraud and AML management - flexible but superior approach to AML, KYC, fraud management is becoming a king. The strategy focused on declining all high risk transactions does not work any longer. Financial players and regulators learned that it is necessary to build rules that enable processing of various types of transactions in a secure way, in line with rules.
- Cryptocurrencies - it seems that after years of ups and downs cryptocurrencies became part of our world. It is difficult to imagine that there will be a hard block for this technology. It is important to start thinking about it as part of financial technologies that bring global value in different use cases.
At Verestro, we focus on those trends to ensure that we can deliver exceptional value for our customers.
Why to use Verestro?
In this article I would like to explain why it is beneficial to leverage the Verestro Fintech-as-a-Service Platform.
Keeping pace in the fintech landscape
Let's start with a description of the problem. Today's financial and payment technology world is a complicated monster. There are new technologies appearing and disappearing every year or even every month. You must invest into new APIs, new interfaces, new frameworks, new security and regulatory requirements. And on the other hand, you have growing costs of IT development. Maybe, during the last years the growth of salaries slowed down a bit but in general one of the biggest costs in your P&L is IT expenditures.
Innovation as a challenge
Let's imagine that you would like to be on top of many innovations in financial technologies. You would like to invest into QR payments, eCom, contactless etc. And you would like to do it of course in high quality. It means that for each of these functionalities you would need a few people to develop and later maintain and host these solutions. A few people means usually 50-100k USD monthly costs for 6-12 months or actually forever. Really forever, because technologies are changing, new frameworks are required, updates are needed.
We think that actually it does not make sense that everybody does it on their own. It would take a lot of time and a lot of money. It is much better and easier if we invest into these technologies and our customers will cover just part of the costs involved in development and maintenance of these platforms. Additionally, we give benefits of compliance with security, legal, regulatory requirements to simplify customers' lives. How does it work?
Verestro’s solution: All-in-One Fintech-as-a-Service Platform
The philosophy is pretty simple. We work on our own, or with Mastercard, with banks, with payment institutions on new products. We are implementing them one-by-one on our platform and thanks to this you are getting a big set of financial technologies in one place. You do not need to manage multiple vendors, you do not need to learn new technologies. You are focused on users, usually you are focused on front-end, core functionalities and your costs are much lower. Our standard fees are lower than AWS or Azure costs of hosting only... but at this price we provide not only hosting but also applications, APIs, connections, regulatory compliance, PCI DSS, business solutions, admin panels, frontend if needed etc.
So, if you want to make use of investments done by multiple parties in the world, get in touch with us!
Verestro architecture and choice of products
Below simplified example of Verestro platform architecture. Before every project please decide which functionalities are you going to use.
Please tick bullet points which are needed in your project and deliver it to our sales team:
- INTERFACE
- White-label app
- White-label web
- SDKs - android and iOS, to minimise PCI issues
- APIs
- CORE
- eKYC - are you going to register consumers? do you have own KYC solution or want to use ours?
- eKYB - are you going to register business customers? do you have own KYB solution or want to use ours?
- Data Core (any user data will be delivered to Verestro) - almost always needed
- Balance
- Card - do you want to use our issuing processing capabilities or you have another issuing processor
- Transaction History
- RECEIVE MONEY
- IBAN for receiving
- Receive to card
- eCommerce gateway - do you want to use our acquirer or you have another acquirer? which ways of payments?
- Other partner assets - do you want to reload cards with points, digital assets etc.
- SEND MONEY
- Payout to Card - sending money to any VISA or Mastercard card?
- SEPA transfers
- Internal transfers between our accounts
- QR payments
- Other ways of sending money?
- PAY TO MERCHANT
- Apple Pay
- Google Pay
- Own wallet
- eCommerce payments
- inApp payments
- Payments from own wallet
- ATM
- CARD BENEFITS
- Point-based loyalty
- Fee management
- Donations
- Cash back
- Vouchers
- Carbon Calculator
- Invoice management
- User groups
We are constantly adding new value added functionalities. Check if we have not added something new in the meantime :) Contact us.
Verestro's products for various regions
Our mission at Verestro is to provide cutting-edge fintech technologies and make them affordable to everyone. We work with banks, fintech providers, payment schemes, payment gateways, merchants, corporations and small businesses and develop a BAAS / FAAS platform. However, as "payments" is a regulated business, we are not able to provide all our services globally at the moment. Below we describe key products we distribute in particular regions.
- The European Union
- Key customers: banks, fintech, payment providers, merchants, businesses, insurances, lendtech etc.
- Key products: all products described in our Developer Zone, including technology and regulated payments solutions.
- Taking into account market dynamics, our key focus is on:
- North & South America
- Key customers: banks, processors, payment schemes, fintech.
- Key products: we are focused on selling technology platforms because we do not have a payment license at the moment; we do work with various partners like Paymentology or Girasol to provide end-to-end payment solutions; we can offer payment accounts and cards in Europe if customer has office in Europe.
- Taking into account market dynamics, our key focus is on:
- East Asia incl. India
- Key customers: banks, processors, payment schemes, fintech.
- Key products: focus on technology products around tokenization and money transfers; we can offer payment accounts and cards in Europe if customer has an office in Europe.
- Taking into account market dynamics, our key focus is on:
- Middle East & Africa
- Key customers: banks, processors, payment schemes, fintech.
- Key products: focus on technology around tokenization and white label; we can offer payment accounts and cards in Europe if customer has office in Europe:
What are the Advantages of the Verestro Fintech-as-a-Service Platform?
Each time we approach our customers, we are asked what advantages over the competitors our solution brings. In this article I would like to describe a couple of points which differentiate us among this pot of financial technologies vendors.
Advantages of the Verestro Fintech-as-a-Service Platform
1. Speed
200% faster than building everything in-house. Instead of building every fintech product yourself, You can use our platform and You will have all of those services much faster and at lower investment costs. Let’s take card issuing for example. To start issuing cards You need to cover very costly and time consuming areas. You have to:
- build Your architecture and its individual components like data core center to manage cards, '
- have all kind of backends to tokenize the cards,
- create admin panels,
- integrate with Mastercard or Visa platforms,
- create the SDKs to integrate them with Your mobile interface,
- finally find or build Your own processing facility,
- and obtain a license of an official payment institution.
It may take from 1,5 to even 3 years and cost You a fortune counted in millions of euros! Choosing a Fintech-as-a-Service model is way more efficient as You simply do it all in 3 months.
2. Cost-Effectiveness
Our services cost up to 50% less than those of the competition! Often customers complain of high costs of fintech services. The cost of implementing our fintech services is one of the lowest in the industry, due to the maintained cost discipline, the location of the software house in the relatively cheapest country in the EU in terms of personnel costs, and the accumulated experience of more than 65 completed implementation projects.
Thanks to the subscription-based Fintech-as-a-Service sales model, the cost of our services is also significantly cheaper than the cost of developing such services in-house. As in the above-mentioned example of card issuing, the cost of card issuing program may exceed 1-2 m euros where in fintech-as-a-service case You will be only charged for a setup fee not higher than 20 k euro and then You will need to pay a monthly fee for the maintenance dependent on the type of cards You issue 4-8 k euro per month. Isn’t it a good deal?
3. Long-Term Financial Stability
We are profitable, no loans, not dependent on investor money. We have Mastercard as a shareholder. You get a partner with long term financial stability which is extremely rare in our industry. Before signing any agreement with any vendor of financial technologies please make sure You double checked their financial condition usually available in the investors tabs on their official websites. You don’t want to wake up one day with Your customers cut off from their payment cards.
4. Flexibility
Direct contact and flexibility! At Verestro,You get in touch with decision makers and we are ready to listen to Your needs. As long as You are not violating financial, AML rules - we are happy to be flexible and update our rules to Your needs.
Even though we would prefer to sell our off-the-shelf products like card issuing, tokenization, money transfers or a business expense management system, we all know, sometimes, some customisations are simply unavoidable. We have wide experience in tailoring the products to our Partners' needs.
5. New Revenue Streams
Generate new revenue with our fintech products! Our clients value rapid implementation of fintech services because it allows them to start generating revenue or reduce costs faster from such services as payment card issuance and cross-border transfers, online payments.
Based on our experience and optimized processes and API/SDK ,it takes 4 times less effort to launch new products and start generating revenues on them. One of the good examples of the way You can quickly start earning on Your payment cards is a Fees module. Simply set up the fees on each issued card and start to earn from the first day of the project.
Contact
If You want to challenge some of the above-mentioned statements, feel free to book a call with one of our sales representatives at sales@verestro.com. We look forward to hearing from you!
Own Payment License or Dependence on a BAAS provider - how does Verestro solve it?
If you are a fintech provider, there is one single risk of choosing a BAAS partner - long-term dependence on a regulatory license of the partner. We will focus on this topic in this article and explain how Verestro's proposal differs from all other BAAS providers.
At the beginning of your fintech journey, there is usually not enough time to cover all the topics and build every single payment license yourself. In fact, it does not even make sense. Therefore, fintech start-ups and scale-ups usually choose BAAS partners and develop their business with them.
Such a decision is actually an important risk for every fintech because you start being dependent on BAAS partners. Your customer gets registered to accounts and payment services of your partner and in the long run you are building a serious risk for yourself. Maybe you do not care about this problem at this stage but think of it. It is a super important risk. What can happen:
- Your BAAS partner may increase prices and you will have to pay
- Your BAAS partner has problems with a regulatory institution and you must follow new rules that regulator is pushing to the payment provider
- Your BAAS partner has AML issues and your BIN, your cards are blocked because of other customers
There are many risks. At Verestro, we solve this problem in various ways:
- We are not only BAAS but also technology provider - a lot of our projects are performed in cooperation with banks, payment institutions where we act as a technology provider only. We can also do it for you which means that once you get your own payment license, we can use the same technical infrastructure to issue your cards and open your accounts.
- We are not dependent on a single payment institution - we work on multi-issuing, multi-bank, and multi-acquiring solutions, so that you can have a choice of payment institutions that you work with. It is a unique functionality of our platform. It enables you to work globally with multiple payment institutions or to switch payment partners once it is necessary for your business.
- We work with multiple banks - we have cooperation with many financial institutions and banks all over the world and our core strategy is to bring you accounts and payments in all countries. You can choose IBANs and BINs from various countries. You can choose currencies, local payment solutions etc.
In conclusion, when you choose Verestro, you get long-term stability and a solution to this important risk. Contact us for more details.
White-label App vs. In-house App Development
In the world of growing IT development costs, our customers are asking more and more questions regarding white label frontend and mobile app development. In this article we will focus on the most important advantages and disadvantages of using white label frontend products.
Introduction to app development
Let's start with an introduction. As a company willing to launch new fintech products or willing to implement a mobile application for your users or employees, you need to make a business decision on how to implement it:
- Your own development (in-house) - in this case you will hire developers, choose a front-end technical framework and will work with your team to implement a mobile app fully dedicated to your business.
- Choosing a white label product - in this case you have to choose a vendor of a white label application, learn how to customise this application and eventually hire a team that will work on customisations necessary for your business use cases.
This choice is actually a super important decision that many business people underestimate. Let's focus on the key advantages and disadvantages of working in both models.
Scenario 1 - In-house app development
This is a common scenario for many banks, new fintechs, corporations, etc. It seems to be very easy. You will hire one or two developers for a few months and after this period of time you will have a perfect product that will include multiple functionalities. You can then resign from developers and have great business use cases for your customers. To hire developers you will usually try to hire an external IT outsourcing company that will promise to you that it is easy, fast and inexpensive.
Nothing in the above sentences is true! :) Really nothing. Many business people, especially company managers, think that front-end development is easy. That everything works great on any type of phone and that integrating backend APIs is super easy and fast.
Disadvantages
In reality, it takes time. A lot of time. To have a very good front-end product built from scratch, without bugs, you usually have to plan 12-24 months of constant development, tests, changes etc. And after this period you cannot resign from the development team. You need to have people that will work on changes, updates, will implement technical updates required by Apple, Google, security rules etc. Let's do a quick calculation. The smallest IT team today consists of 4-5 people: backend developer, frontend developer (one or two depending on chosen technology), tester, product owner / scrum master / project manager / UX person. If you want to have fast development, this team should be bigger (8-10 people). Additionally you need hosting services - AWS or Azzure can quickly become a large part of your cost structure. You need additional software and systems connected with development work, such as Slack, Jenkins, Kubernetes, etc. All of this costs money. In short, you should expect the following costs:
- 5 people * min. 6.000 EUR average cost = 30.000 EUR monthly
- 5.000 EUR hosting monthly
- 1.000 EUR additional costs
- not including office costs, bonuses etc.
TOTAL: 36.000 EUR monthly cost -> FOR THE SMALLEST POSSIBLE TEAM!
And let's imagine that you have to spend 10 months for MVP development -> 360.0000 EUR one-time fee.
It is the cost you have to cover just to implement your MVP. Without any marketing, without any customer reactions, no sales during the period. In reality I think that you should assume that this cost of doing the implementation in such a way is 2-3 times higher than this minimum cost - almost 1 mln EUR.
Additionally, you should take into account that development done by a very small team requires technical compromises. Most likely you will not use Native iOS and Android technologies that are the best from UX perspective. IT companies will recommend to you various hybrid technologies which is always a compromise in the UX area. You will also not gather experience from other projects done in similar areas. Your mistakes will usually be first mistakes, your developer mistakes will require updates, etc.
What's even more important, you need to think about long-term development, hosting and maintenance costs. Maybe you can limit the team by 50% but costs of hosting will grow for sure with new users coming to your system. I would assume that you will have a monthly cost of 10-20.000 EUR to cover to keep the application running.
Advantages
Apologies for describing so many disadvantages but I think it is true. However, there are big advantages. If you can afford those costs and time spending, you will have full freedom. You can do with your app whatever you want to do. You can implement new features, change everything, implement new technology quickly. The dependency is only on your budget. I fully admit that this is a super important advantage that can be strategic for many start-ups and companies. I am just not sure that you must get this advantage at the very beginning of your project. Sometimes cost and time is much more important than full freedom of development. Go-to-market time may be decisive for getting new investors, growing revenues will be critical to proving that there is a problem you are solving.
Scenario 2 - White label application
Using a white label application is another strategy you can choose. In such a situation the majority of components of your application are already developed. You use an already existing product that can be customised to your requirements and you hire your developers just in case you want to make various non-standard changes in the app.
The following rules for choosing a white label application vendor are very important:
- Carefully choose technology - please remember that native iOS and Android solutions are just better from the UX and performance behaviour. This is what Apple and Google use for their apps.
- Check the possibility of customisations - make sure you understand flexibility of the product, if you can add new features, if your developers can work on the code, if you can change just colours and logo or the entire look and feel in the long run.
- Verify experience - check examples of other customers using this product. See how they look like, test them.
- Prices - obviously important. Remember to check both one-time and on-going maintenance prices. The 2nd ones are even more important.
- Intellectual property - very important. Is it possible that you get full IP rights to the copy of your application. Would you be able to change the development later to your own development.
- Security and financial stability - make sure you work with a partner that is financially stable and will not close your project in the middle of the development.
These are the most important issues that you need to check. Once you check them and they are acceptable for your business, you may get a result that your product can be 5 times faster on the market, costs can be 4 times lower, revenues will appear much faster etc. Today, the cost of white label applications can be as low as 40-60.000 EUR for development. The maintenance - 4-5.000 EUR. It can be critical for the business, especially during the first phases of growth.
Summary
I recommend that you do not believe that the world of front-end development is simple and inexpensive :) Do not make this mistake. Consider carefully if you have enough time and money. In fact, one of the most important aspects of project development is the comparison of revenues and costs. Costs are known for sure. Revenue is usually unknown. Make sure you do not overinvest. It is very easy to make a decision that you want to spend half of your 2 mln EUR on technical solution but actually it will be much, much better if you spend 200.000 EUR on a technical solution and the remaining 800.000 EUR will be used for promotions, marketing, user acquisition. This usually matters the most.
Anyhow, good luck. Thanks for reading.
Mobile App Development Languages Used by Verestro
This article summarizes programming languages & technologies we're utilizing to build our mobile solutions.
Why should I care?
If you want to use Verestro's SDKs in your mobile apps or you are interested in our Whitelabel Mobile Application, with intention of future maintenance by your own team, you may want to check if our products fit your technology stack well.
Native solution
Most of our solutions for mobile apps leverages technologies native for each mobile platform:
- For Android - Kotlin (seamlessly works also with java-based projects)
- For iOS - Swift
This enables best performance, security and integration of platform-specific features. You may also create your own native SDKs for your products that will work with our ecosystem. More details available here.
Compatibility with web-based solutions
It is possible to embed widgets or entire web-based screens inside our Whitelabel Mobile Application. We'll pass you data about the currently signed in user, so you can display relevant information. More information about it is available here.
Flutter, React Native and other cross-platform tools
While we don't provide SDKs for mobile apps written in Java Script & Dart, our native SDKs work great in such an environment. Both most popular cross-platform frameworks include relevant solutions for this:
- For Flutter you use Platform Channels
- For React Native you have Native Modules
Business Control for new or existing portfolios
One of our important products is Business Control. You can find more information about this solution under the following link - Business Control
Our customers are asking us from time to time if it is possible to use Business Control for the existing portfolio of customers and cards or if it is aimed for new customers. Let me clarify this topic in this article.
Business Control is a platform or set of functionalities targeted at business customers that should give them more control over spendings, company expenses, cost and invoice management and more. Verestro offers it to banks and fintechs as a technology platform or we also can deliver it directly to corporations in connection with our partnering payment institutions in various parts of the world.
It offers several important benefits for business customers:
- super easy issuing of virtual cards for various company expenses - imagine that your manager can issue a virtual card to you when you go to a conference in another country. Card will be valid for 2 weeks, will have various limits etc.
- invoice management - instead of collecting pictures or doing photos you just scan an invoice and it lands directly in finance or accounting department for approval and further processing
- employee benefits - you can use cards with multiply visuals to give Christmas gifts or Valentine Cards or Thank You Gifts to your employees
- all the money is held in one or a few payment accounts which means that you do not need to pre-paid every card. You keep money and deliver "limits" to your users. It is a very important benefit vs pre-paid cards.
Let's imagine that you already have a portfolio of business customers because you are a bank or fintech partner and you would like to offer such a platform to your customers. Quick answer is - of course it is possible to offer Business Control to your existing customers.
After some integration and implementation projects you will give your existing customers an opportunity to issue new virtual cards for their employees, manage invoices and expenses etc. However, take into account that if you would like to enable it for already issued cards, actually you are using just part of the functionalities. The card already exists, it is in hands of the user, so in fact it means that you will not issue a new card for this person but you can:
- manage limits of cards
- manage invoices
- have new interface for company / employee
- and additional possibility to issue new virtual cards for this company or business customer
Feel free to contact us and discuss details of such implementation.
Regards,
Krzysztof
What employee benefits can be offered via the Verestro Business Control
Our Business Control platform provides the opportunity to issue virtual cards and manage business expenses. But in fact it can be used in multiple ways for companies. Here are a few examples of such use cases:
- Business payment card - your employee going for a trip, conference, meeting with a customer can get a virtual payment card and use it for payments globally. Once the employee makes a transaction, he/she can scan an invoice and connect it with the transaction so that the finance team and accounting have an easier process of expense management. This is a usual use case.
- Salary card - you can send salaries to your employees worldwide by using Business Control. If you issue a card with a specific limit to your employee, the employee can start making purchases and use it as a normal card. Thanks to it you have an easy salary transfer mechanism to all employees globally.
- Lunch card - you can issue cards for your employees and offer them a virtual card as a lunch card to get some tax benefits (depending on the country). Thanks to Business Control you can limit the acceptance of these cards to dining so that employees could use the cards for meals.
- Gift cards, holiday gifts, Thank You Card - you can issue a virtual card via Business Control any time you want to reward a particular behaviour of your employees. It is a bonus for the employee. You can have a specific "bonus" or "holiday" related card visual, you can add a message to the employee so that he/she knows that this card is for the particular achievement.
- Limiting time for expense processing in the company - if you want to limit hours spent by your employees, administration, finance and accounting teams for expense processing, finding documents, connecting them with transactions, etc., you can use Business Control. We can integrate Business Control with your ERP system, we can transfer invoices and transaction data to your internal databases so that transactions can be processed automatically. Think how many hours you lose every month of such manual activities connected with expense management.
Please remember that we offer this product through partnering with payment or banking institutions. We can also offer it directly to companies in Europe. Contact us if you want to know more about this product.
Tokenization and Contactless Payments - Verestro's competitive advantages
The most important reason why you should use the Verestro Tokenization and Contactless Payment Solutions
There are many reasons why to use Tokenization and Contactless Payment solutions provided by Verestro but one of them is definitely the most important. We can give you access to ALL ways of NFC and contactless payments through a single platform and one vendor. There are multiple partners you will have to integrate with and certify. Some processors will enable the majority of them but very few will give you access to all. Some IT companies will tell you that they can do everything and connect to everyone but it is also not true. It takes time and money to get new integrations and certifications.
Examples of questions that you can ask your vendors
- Imagine that 10% of your users are using Huawei phones. Are you ready to provide contactless payments to their phones now?
- What if many of your users have cheap Android phones? Will your solution work on this? How many MB are used by your system (in our case below 4MB)?
- What if you are issuing cards in multiple markets? Is your current solution ready globally?
- What if you are planning to tokenize bank accounts (not cards but bank accounts) - is your platform ready for this?
Verestro's solutions
At Verestro we solve this problem by certifying and standardising integration with all possible ways of payments. We are delivering our tokenization and NFC cloud payment platform globally to multiple bank and payment institutions. Current list of certified solutions is:
- phones: Apple, Huawei, Pixel, Samsung, LG, Motorola, Xiaomi etc.
- operating systems: iOS, Android
- X-pays: Apple Pay, Google Pay, Samsung Pay, Fitbit Pay, Garmin Pay, your own wallet, your own X-Pay
- payment schemes: VISA, Mastercard, Pay-by-Account, Local scheme
- countries: global, possibility of local data hosting or transaction processing
Business benefits
Additional business benefits that make us unique are:
- possibility of registering individual card visuals
- delivering the full scope of reporting for Apple and Google inside the Verestro Token Management Platform
- possibility to organize card registration to Apple or Google with own, proprietary CVC / CVV verification method (no need for integration)
- cheap and quick - below 20k eur one-time, below 4k eur per month, 2-4 months only
Please contact us for more information.
Cashback - Boost Customer Loyalty and Spending
In today's competitive financial landscape, cashback has emerged as a game-changing strategy for businesses looking to attract and retain customers. But what exactly is cashback, and why should your company consider implementing it? Let's dive into the world of cashback and explore its benefits and versatile applications.
Why Should We Use Cashback?
Cashback is more than just a perk – it's a powerful tool that can transform your business. Here's why:
- Enhance Customer Loyalty: By offering a percentage of money back on purchases, you create a compelling reason for customers to choose your service over competitors. This incentive encourages repeat business and fosters long-term relationships.
- Boost Customer Spending: The prospect of earning cashback motivates customers to spend more. It's a win-win situation: customers feel they're getting more value, while your business sees increased revenue.
- Gain a Competitive Edge: In a crowded marketplace, cashback can be the differentiator that sets your product apart. It's an attractive benefit that can sway potential customers in your favor.
- Real-Time Gratification: With immediate calculation and allocation of cashback after transactions, customers experience instant rewards, reinforcing positive associations with your brand.
- Flexible and Customizable: Cashback programs can be tailored to suit your business model and customer preferences, allowing for targeted promotions and strategic incentives.
Cashback & fees money flow
Cashback is an internal transaction for a partner who wants to top up the user's balance as part of the loyalty program.
Our card & balances management system (Antaca) automatically debits the masterbalance with this transaction.
Cashback Rules: How to Maximize Your Rewards
The true power of cashback lies in its flexibility. Here are some innovative rules and use cases you can implement:
- Percentage-Based Rewards: Offer a consistent cashback percentage on all purchases (flat rate), such as 0.5% cashback on every transaction. Alternatively, implement tiered rates to reward bigger spenders, like 0.2% for transactions up to $100, and 0.5% for transactions over $100.
- Fixed Amount Rewards: Provide a fixed cashback amount for each qualifying transaction, regardless of the purchase amount. You can also offer different fixed cashback amounts based on transaction value ranges.
- Merchant-Specific Cashback: Boost partnerships by offering higher cashback rates for specific merchants. For example, 2% cashback on purchases from your partner stores.
- Category-Based Rewards: Encourage spending in particular sectors by offering higher cashback rates for specific transaction categories. For instance, 3% cashback on all bookstore purchases (MCC code 5942).
- Payment Method Incentives: Promote certain payment methods by offering higher cashback rates. For example, 0.5% extra cashback for transactions made with Samsung Pay.
- Geographical Targeting: Encourage local or international spending with location-based cashback rules. Offer 1% cashback on all transactions made within the EU.
- Currency-Specific Rewards: Incentivize transactions in specific currencies, such as offering 0.75% cashback on all USD transactions.
- Time-Limited Promotions: Create urgency with limited-time cashback offers. For example, double cashback rates during holiday shopping seasons.
- Cumulative Rewards: Reward loyal customers with increasing cashback rates based on their total spend over time. For instance, unlock 1% cashback after $1000 in total purchases.
Cumulative Rewards feature needs implementation.
How to implement cashback?
Please feel free to contact us and we will setup various cashback rules on Verestro platform for you.
Please make sure you build your cashback network with partners, merchants etc.
It is not part of our responsibilities at the moment.
Understanding White Label Applications: A Beginner's Guide
Our clients often search for effective ways to scale their offerings. The obvious way to do this is to create their own product through the entire production process, from identifying the market and its trends, to building a prototype and implementing the system, to continuous improvement. This approach requires a lot of resources and time. However, it is worth asking ourselves whether we are able to take such risks? What if the product is finished, once the demand for such solutions in the market starts to fade, or by the number of competing solutions it becomes difficult to achieve the desired results? Perhaps better results will come from using proven solutions created by experts who know the trends and have solutions in their portfolio that have paid off in the market. Due to the factors mentioned above, investors are increasingly using white label applications.
What is a White Label Application?
At its core, a white label application is a pre-built software product that can be rebranded and customized by businesses as their own. Think of it as a “ready-made” app that developers create, but the final product is branded with your company's logo, design, and name. The white label provider handles the coding, updates, and maintenance, while your business gets a fully functional application under your own brand. You don't have to worry about required security certifications or updates for new iOS/ANdroid versions.
How Do White Label Applications Work?
Here’s a simplified step-by-step process of how white label applications typically work:
- Purchase or License the Software: Buy the application or license for a pre-developed app.
- Customization: Customize the app by adding branding elements, such as logos, color schemes etc. and add your core product features through widgets or new screens.
- Launch and Market: Once the app is branded, it is ready for deployment. The business can now offer it to customers as a proprietary solution.
During the customization step mentioned above there could be small and complex customizations. This is usually the critical topic how deeply you can influence white label so that it fulfills customer needs. Let's go deeper on this topic.
What is considered as custom development in the context of White Label?
Custom development involves deeper, more technical modifications to the core functionality of the white label application. This goes beyond just changing the look and feel of the app; it involves altering or adding features, adjusting workflows, or integrating the app with other systems. In essence, custom development changes the app's functionality to meet specific business requirements.
Key Characteristics:
- Feature Enhancements: Adding new features or modifying existing ones to meet unique business needs (e.g., integrating custom payment gateways, modifying end-user flows, etc.).
- Technical Adjustments: Tweaking or rebuilding parts of the app's code to support new functionalities, or to change behaviour.
- Custom Integrations: Integrating the app with third-party tools like CRMs, webviews or other business platforms.
- API Integration: Developing custom APIs or integrating the app with existing APIs to communicate with other services.
- Data Handling: Modifying how the app collects, stores, or processes data.
Example: The company buys a white label app but wants to add a custom fitness tracker, integrate it with their gym's membership system, and implement push notifications. This is the custom development.
What is considered as simple customization or rebranding?
Brand change (also called rebranding) refers to the cosmetic adjustments made to the white label application to make it appear as though it was developed by your company. This process typically does not involve any modifications to the app’s core features or functionality, but focuses instead on the visual and branding aspects.
Key Characteristics:
- Logo Replacement: Changing the app’s logo to reflect your company’s brand.
- Color Scheme: Customizing the app’s design elements, like background colors, button styles, and fonts, to match your brand's style guide.
- Brand Identity: Incorporating your company’s name, slogans, or taglines within the app.
- Language changes: Implementation of new languages in the app
- Minor Content Updates: Updating in-app content (like text, images, or icons) to match your brand’s messaging, while the underlying functionality remains the same. That’s about changing the components itself - not the position of components on the screen.
Example: A new fintech provider purchases a white label delivery app. They change the app's color scheme to match their brand, update the logo, and add their business name throughout the app. However, the functionality (eKYC, payment system, transaction history, etc.) remains unchanged. This would be a brand change.
Summary:
- Custom Development: Involves altering the functionality of the app, adding or modifying features to meet specific business requirements.
- Brand Change: Involves changing the appearance of the app by applying your company's branding elements (logo, colors, etc.) without altering its core functionality.
Save time and reduce risks by choosing Verestro’s White Label solutions. With our ready-made, customizable apps, you can quickly launch your own branded product without the need for development or maintenance. Whether you need simple rebranding or more advanced custom features, Verestro’s proven solutions can help you scale faster. Contact Verestro today to explore how their expertise can elevate your business.
How does Verestro differ from standard software companies?
Verestro is not an IT software outsourcing company. Verestro is a company focused on developing, maintaining and growing multiply fintech products. Let me give some examples:
- If you are big manufacturer and you are interested in software to manage your production site - do not call us, it is not our domain of work, we do not want to focus time of our developers on such project
- If you are global web provider and you are searching for new ways of building web services incl. Artificial Intelligence - do not call us, it is not what we are interested in
- If you are a global technology company and you are interested in ERP software - do not call us, we are not interested in developing it for you
- If you are a bank, and you are planning to launch a new credit scoring system - do not call us, we are not interested in it today (however, we are planning to work on credit processes as it is close to our fintech domain).
But if you are searching for various financial or payment solutions, especially if they require multiply integrations, are connected with all accounts, card issuing, card acquiring, contactless and eCom payments - call us. This is our domain where we are very strong. We can build very difficult use cases, we can connect issuing with acquiring, we can play with technologies.
In other words we are focus on fintech products. We perform multiply certifications with VISA or Mastercard to be able to deliver those products globally in the most effective way. The best way to use our platform is actually to learn how our products work and try not to change too many things. We are implementing them in the best way possible, connecting experience from multiply projects, geographies, industries. If you use those products 'as-is' you will feel the most benefits as you will find out that implementing new payment innovation can be super quick (1-2 months) and very cost effective (10-20k eur).
Test us, partner with us, play with fintech technology in cost effective way. Build a fintech innovation pipeline with us.
Card Issuing & Bank Accounts
How does card issuing work? Check here.
Payment schemes
In this document we describe how payment schemes (Mastercard and VISA) work.
Payment card business is a large global market, which was developed in the USA in the first half of XX century and has grown globally. In this document we will describe the main business principles and in the next chapters we will go into more details. We will focus mainly on Mastercard and VISA operations, as these are the largest payment schemes in the world and the main partners we work with.
Four Party Model
Let's start with the general relationships between the parties. In the Mastercard and VISA 4-party model (which is actually 5-party model) there are the following players:
1. Cardholder - has a contract with Card Issuer, which is usually a bank, financial institution, payment institution, credit union, etc. Cardholder keeps a card in a plastic or virtual form that he/she gets from Issuer. Cardholder makes a purchase transaction at Merchant or sometimes withdraws money from an ATM. In the case of an ATM transaction, the ATM operator (usually a bank) acts as Merchant in a standard purchase transaction.
- Cardholder is happy because he/she does not need to carry cash all the time and has money all the time in their pocket or phone.
- Cardholder has to pay card fees to Issuer for getting a payment card.
2. Merchant - delivers goods to Cardholder, but does not receive cash immediately, but accepts the card transaction, which gives him/her almost 100% confidence that he/she will receive money in a few hours or days.
- Merchant is happy because he/she sold goods, usually having sold more than Cardholder could afford with cash. Imagine the situation where you have to pay cash all the time. Would you always carry enough cash with you? What if you want to buy something, but you do not have enough cash?
- Merchant has to pay the so called "Merchant Fees" to Acquirer for processing the transaction. Usually, Merchant Fees are between 0,5-3% depending on transaction value, country, merchant segment, type of card etc. Merchant fees cover most, if not all, of the transaction processing costs. They usually include all the fees charged by Acquirer, Issuer, Mastercard or VISA for the transaction.
3. Issuer - Issuer is usually a bank, credit union or any other payment institution that delivers payment cards to cardholders (consumers or businesses). Issuer signs contracts with cardholders. On the other side of business, Issuer has a franchising or licensing contract with VISA and Mastercard and connects to their network using Issuing Processors. Verestro and our partners (for example Quicko) plays the role of Issuer and Issuer Processor in our card issuing or BIN sponsorship projects. During the transaction process, Issuer usually gets authorization, clearing and settlement messages that result in transfer of money from a cardholder account to Acquirer so that Acquirer could settle the transaction with Merchant.
- Issuer is happy because they charge card fees to Cardholder (for example monthly per card) and get transaction fees called Interchange Fee from Acquirer. Interchange fee is a very important part of Merchant Fees. In the European Union for consumer cards it is usually in the value of 0,2-0,3%, but in many countries, especially for business and credit cards, it can amount to 1-2% of the transaction value.
- Issuer has to cover costs of card issuing, which include:
- Cost of payment scheme (Mastercard or VISA) incl. monthly connection, license, authorization, clearing and many many other fees. This is usually the main part of Issuer's costs.
- Cost of other processors incl. transaction authorisation, card maintenance, card tokenization, plastic card manufacturing, personalisation, delivery, etc.
- Regulatory costs incl. payment license operations, Anti-Money Laundering processes, etc.
- Various costs connected with maintaining a relationship with Cardholder incl. proper communications, SLAs, etc.
4. Acquirer - Acquirer is usually a bank or payment institution that signs contracts with merchants, settles payment transactions with merchants and has acquiring contracts with a payment scheme. Acquirer usually provides a payment terminal to merchant locations, and makes sure if it works and is ready for transactions.
- Acquirer is happy because they charge Merchant Fees that usually consist of transaction fees (0,5-3%), sometimes fixed fees per transaction (0,01-0,5 EUR) and monthly fees per terminal.
- Acquirer needs to cover various fees, including regulatory fees, payment scheme costs, cost of processors, terminal purchase and costs of operations.
5. Payment Scheme - Payment Scheme (i.e. Mastercard or VISA) are key for keeping the model running. They develop technical systems that issuers and acquirers are connected to, they process transactions, they develop the market. However, they are also the biggest beneficiaries of the market growth as every new transaction represents revenue for Mastercard and VISA.
Key Processes
There are several processes that take place during card and transaction processing, and here we will briefly describe the most important ones:
- Card issuing process - this process or set of processes consists of multiple actions that Card Issuer needs to perform to issue a payment card. They are the following:
- regulatory compliance - every card issuer in the world needs to comply with law, get license from a national bank or financial regulator, work according to their recommendations and rules,
- Mastercard integration and licensing - it consists of a formal process, providing necessary cash collaterals, doing technical integration, getting security certifications etc.,
- card creation process - after signing a contract by a user, Card Issuer needs to create a new card number (using BIN of the issuer - BIN = first 6 or 8 digits of card). When a card number (PAN = Primary Account Number) is created, the card can immediately work as a virtual card or can be sent for personalisation if it is a plastic card. Usually, after the user receives the card (virtual or plastic), the user starts the card activation process, sets the card PIN and can start using it.
- Transaction process - this process consists of several operations that result in transfer of money from Cardholder account to Merchant. They are the following:
- Authorization process is an action that ensures that Merchant can immediately get information if Cardholder has money on his/her card account and if this card is not stolen. The authorisation can happen online (a direct request to Issuer's system to check the balance and card status) or offline (in this case a chip on the card makes a decision if it can approve the transaction without asking Issuer's systems).
- Clearing process is an action of payment scheme during which clearing files are delivered by acquirers to payment scheme and payment scheme calculates how much money each Acquirer should receive from each Issuer in the world.
- Settlement process is a process of transferring money from issuers to acquirers and later to merchants so that finally Merchant receives the transaction amount, less Merchant Fees, on his/her bank account. Every Issuer and Acquirer has settlement bank accounts that are used for transferring money from or to. Payment Schemes operate those accounts using something like Direct Debit / Credit to transfer money between Settlement Accounts of various financial institutions.
- 3DS - sometimes additional authentication mechanisms are used to ensure that the person initiating the card transaction is the actual cardholder. In the case of eCommerce transactions this process is called 3DS. During an Internet transaction, the user's browser opens the bank's website, where the user can authenticate the transaction using one-time passwords or other forms of authentication developed by Issuer. After the 3DS authentication is verified, Acquirer receives a special cryptogram that is included in the authorization message and validated later by Issuer during the authorization process.
- Tokenization - tokenization is a process of exchanging a real card number into a token number (similar to a card number) to enable digital and contactless payments. Usually it is connected with transactions performed in cooperation with the so called X-Pays (i.e. Apple Pay, Google Pay, Fitbit Pay etc.). The process of tokenization requires an integration with Mastercard Digital Enablement System (MDES) or Visa Tokenization system (VTS) to enable tokenized payments.
- Refund and reversal - special type of transactions that enable reversing payment transaction either immediately (reversal) or later (refund). Once this process has been initiated, Cardholder can receive money back after successful authorisation.
- Chargeback - process of complaint management. It can be initiated by Issuer in case Cardholder informs Issuer that he/she did not do the transaction or did not authorize it, or goods were not delivered etc. The process is costly for Issuer and Acquirer but ensures security of the system for cardholders.
- Card-to-card transactions and payouts - the so called "payment" or "credit transactions". In a standard purchase transaction money is transferred from Cardholder to Merchant. In a card-to-card transaction or payout transactions, the user gets money on his/her card or on the account linked to the card.
There are other important processes associated with payment systems and card transaction processing, but let's stop here and take a short break to understand these critical processes.
Ranking of card issuing companies
How to choose a BIN sponsor and card issuing partner?
Choosing a BIN sponsor or card issuer is a difficult decision for many partners. Most of our partners do not come from the payment card business, so they learn by doing. In this chapter, we are going to describe the key decision factors of choosing a card issuer and make a simple ranking that we will be upgrading and updating in the coming months and years, as not all information is available to us immediately. On purpose, we will not compare other companies to us, it would not be fair to include Verestro - our goal is to educate in this article.
There are the following key decision factors in choosing a card issuing partner:
-
- Does the card issuer share 100% of interchange with me?
- What is the currency conversion rate that the card issuer shares with me?
- How can I impact and earn on ATM withdrawal fees?
- How can I impact and earn on various consumer fees?
- Can the partner help me with getting the Mastercard or VISA marketing and financial support in the short and long run?
2. COSTS - Obvious point.
-
- What are fixed and variable fees?
- What is the level of fees in case of low volumes and high volumes?
- Is there any opportunity to minimize costs as the business grows?
- Read this article for more info on standard card issuing costs: Card issuing - financial details
3. FUNCTIONALITY & SERVICE - a very important point. Critical in the long run.
-
- Does the partner have mandatory functionalities?
- Does the partner offer currencies that I need for my users?
- What are other products that can increase usability or profit that the partner offers?
- Maybe a loyalty program?
- Any insurance offers and additional benefits that could be sold to customers?
- Perhaps invoice scanning and expense management?
- Maybe white label solutions?
- Card reload mechanisms?
- Payouts to cards?
- etc.
- Does the partner offer quick access to a developer zone or a test environment?
- Does the partner make their APIs public?
3. SECURITY AND FINANCIAL STABILITY - a critical point. Maybe it should be the first one.
-
- Is the partner a small start-up, burning money or a payment institution generating profits? Can you imagine what would happen to your portfolio and users in case of bankruptcy or hostile takeover?
- Who are the shareholders of the partner? Are these venture funds or strategic, long term investors?
- Does the card issuer make their financial statements public?
- Does the partner offer support in solving PCI DSS issues (Payment Card Industry Data Security Standards)?
- Is the partner audited annually?
- Does the partner work with banks and other large financial institutions or focus only on small, high-risk startups?
- Is the partner a small start-up, burning money or a payment institution generating profits? Can you imagine what would happen to your portfolio and users in case of bankruptcy or hostile takeover?
Here's an initial comparison of the best known card issuers in the European Union (grades: low - high):
Name | Country | Revenue Share | Costs | Functionality & Service | Security & Financial Stability |
Treezor.com | France | Medium | High | Medium | Medium |
Swan.io | Denmark | Medium | High | Medium | Medium |
Dipocket.org | Lithuania | High | Medium | Low | Low |
Solarisgroup.com | Germany | Medium | High | Medium | Medium |
Wallester.com | Estonia | Medium | Medium | High | Medium |
Stripe | USA | Low | High | High | High |
Weavr.io | Malta | Medium | Medium | Low | Medium |
Verestro | Poland | Make your own assessment | Make your own assessment | Make your own assessment | Make your own assessment |
Source: Financial Stability results based on 2022 or 2023 results available in Internet; all other data from publicly available sources. Please make your own assessment.
Card issuing - financial details
How can I earn from card issuing? This is a common question that is asked by our customers. Let me explain the key financial areas connected with this business.
Indirect revenue or cost savings
Usually, the main reason for issuing cards in different segments is indirect revenue or cost savings. The first question that you should ask yourself is connected with your use case. What can a payment card bring to my customers or my business? The answer to this question is different for various business segments and is the most important factor in defining a financial model for such an operation:
- If you are a bank, payment cards are obviously a core payment product that lets you earn from various transactions, currency conversions, ATM withdrawals and other fees.
- If you are a fintech wallet, it is obviously an important functionality because you compete with banks. It can increase your revenue streams from the same areas as above.
- If you are a crypto wallet, you want to offer to your customers a way to use digital assets at brick-and-mortar shops and in eCommerce.
- If you are an insurance company, you may want to send insurance in the form of a virtual card with a particular transaction and geographic limit so that your customer could immediately get necessary help.
- If you are an investment wallet, where users store value in the form of shares or bonds, you can offer payment cards to them so that they could pay using their shares at standard shops.
- If you are an eCommerce merchant or marketplace, you may be interested in using payment cards as a way to send back money to your users after their claim so that they could use this card for an eCommerce payment.
- If you are a small, medium or large corporation, you may want to distribute cards to your employees so that you limit costs of invoice processing and company invoicing.
- If you are an HR agency, you can use cards as a tool to pay salaries to your employees
- If you are a loyalty program owner, you may be interested in enabling users to use your points and make purchases at any location in the world.
- etc.
There are many use cases and this is the main value for you. You can charge additional fees for this new service offered to your users, or you can limit your operating costs thanks to card issuing. However, there are direct revenue streams and costs associated with issuing cards and I will describe them below:
Direct revenues of card issuing
The following direct revenue is connected with card issuing and card transactions:
- Interchange Fee - when your user pays online or offline at any merchant, there is a fee called Interchange Fee that the issuer of cards receives for this transaction. The value of this fee depends on the country, transaction type, card product type, etc. In general, it is between 0,2% (for consumer debit cards issued in Europe) to 1-2% (for various types of cards for transactions done on other continents). Make sure you check with your card issuer or BIN sponsor how they share this fee with you - it is the most important revenue stream.
- Currency Conversion Fee - every card transaction done in another currency than currency of a card account results in currency conversion. This action usually enables charging fees. Typically, they are between 0,5% to 8% depending on card product, country, currency, etc.
- User fee - card issuers, banks, financial institutions usually charge various user fees for using their payment card. Examples of such fees are: one-time fee for issuing a card, monthly fee per card, annual fee per card.
- Transaction fees - depending on a card product and a type of transaction, card issuers charge users additional transaction fees. A very standard fee is an ATM withdrawal fee - it is almost always valid because there are direct costs of an ATM withdrawal called ATM Service Fee and these costs need to be covered. Sometimes card issuers charge POS or eCOM transaction fees - for example 0,1% fee for every transaction done with a card.
- Value added services - a card product enables you to charge additional services, i.e. insurances, VIP support, concierge etc. that increase your revenue streams.
Direct costs of card issuing
- One-time fee for card issuing - usually 0,1-1 EUR. This fee is charged at the moment of card issuing. This fee covers costs of payment processors, various costs of operations connected with issuing the first card.
- Monthly fee per card - usually you pay 0,1-1 EUR monthly per issued card. This covers both technical, regulatory and financial risk costs of card issuers.
- Transaction fees:
- per transaction (from 0,05-0,3 EUR) - depends on a type of transaction, region of transaction etc.
- per transaction value (from 0,01%-0,5%) - depends on a transaction value.
- ATM service fee - very specific fee which is part of a transaction fee in fact. For every ATM withdrawal, a card issuer needs to pay a fee which is transferred to an ATM operator. Usually, it is in the value of 0,5-3 EUR + 0-1% from the transaction value.
- 3DS operations fee - transactions in eCommerce require additional authentication. Such an operation usually results in an additional fee charged by a card issuer (0-0,04 EUR per transaction).
- Apple Pay fees - Apple charges additional fees for using Apple Wallet. Those fees are both per card quarterly and per transaction volume - different for POS transactions and inApp transactions. We are not allowed to disclose the level of these fees.
- Plastic card related fees - production, personalization and transport of plastic cards is a serious operation that involves various costs. Typically, between 2-5 EUR per card depending on customer location, type of card, etc.
These fees are usually charged by card issuers and BIN sponsors to their partners. They have to charge them because there are various costs that we need to cover (this issue also applies to Verestro and our BIN sponsors). The main card issuing costs are:
- Payment scheme fees - Mastercard, VISA or any other payment organization charge a lot of various fees for connecting with them and using their licenses and technology. This is one of the biggest components of costs for card issuers.
- Payment processors - this is our (Verestro's) role. To issue cards, you usually need to hire external, certified payment processors. They charge a lot of fees for using their technology. Examples of such processors are : Verestro :) , Paymentology, Fiserv, First Data, Marqueta etc.
- Card manufacturers and personalisation centers - if you issue or sell plastic cards, you need to produce and personalize these cards. Companies like Austriacard, Thales, Idemia charge fees for such operations.
- Regulatory compliance costs - to become a card issuer in any country, you need to have a payment license, get certification, fulfill necessary roles that are not present in another business. This is a serious cost for card issuers.
- Security costs - to work with payment cards and process them, you need to fulfill various security requirements. The most important ones are summarized in the Payment Card Industry Data Security Standards. They include not only internal actions but also annual and quarterly audits that you need to perform to be compliant and offer secure operations.
There are other possible revenue streams and costs connected with card issuing, but the ones described above are the most important ones.
Thank you for reading.
Example of Profit & Loss calculation in card issuing
Calculating profits and losses in card issuing is not easy, especially when various card issuers offer different fee and revenue models. Below I would like to show a few examples.
Let's imagine we are a fintech wallet with 10.000 users and we would like to issue cards for these users. The first step we need to take is to try to forecast key parameters of product, transaction, revenue and cost assumptions:
- Product
- Product - Debit Business Mastercard card
- Settlement currency - EUR
- Transactions
- Average number of cards in a year - 10.000
- Offline POS transactions in Europe: Number of transactions per month - 5 ; Average Transaction Value (ATV) - 30 EUR
- Online eCom transactions in Europe: Number of transactions per month - 3 ; ATV - 40 EUR
- ATM transactions in Europe: Number of transactions per month - 2 ; ATV - 100 EUR
- Share of currency conversion transactions in Europe - 10% (transactions done in Polish zloty, Czech koruna, Romanian Lei, Swedish krona etc.
- Offline POS transactions outside of Europe: Number of transactions per month - 1 ; Average Transaction Value (ATV) - 60 EUR
- Online eCom transactions outside of Europe: Number of transactions per month - 1 ; ATV - 60 EUR
- ATM transactions outside of Europe: Number of transactions per month - 0,1 ; ATV - 100 EUR
- Share of currency conversion transactions outside of Europe - 100% (transactions done in Polish zloty, Czech koruna, Romanian lei, Swedish krona etc.
- Share of registered ApplePay cards - 30%
- Share of ApplePay transactions - 20% for online and 90% for offline contactless
- Revenue
- Interchange fee for business cards (fee from POS and eCommerce transactions; we assume 100% of interchange stays with partner)
- in Europe - 1.2%
- outside Europe - 1.5%
- ATM withdrawal fee - 0.5%
- POS and eCommerce transaction fee - 0%
- Currency conversion fee - 2%
- Monthly fee per card - 1 EUR
- Interchange fee for business cards (fee from POS and eCommerce transactions; we assume 100% of interchange stays with partner)
- Costs
- One-time fee for an issued card - 0,4 EUR
- Average monthly fee per card - 0,3 EUR
- Fee for offline POS transactions in Europe - 0,10 EUR + 0,1%
- Fee for online eCom transactions in Europe - 0,10 EUR + 0,11%
- Fee for ATM transactions in Europe - 0,9 EUR + 0,3%
- Fee for offline POS transactions outside of Europe - 0,3 EUR + 0,45%
- Fee for online eCom transactions outside of Europe - 0,3 EUR + 0,5%
- Fee for ATM transactions outside of Europe - 0,3 EUR + 1.2%
- Currency conversion fee - 0,5%
- Apple Pay active card quarterly fee - 0,25 EUR
Let's do quick calculations.
Please treat it as example and make your own calculation. There will be many dependencies connected with segment, type of portfolio, detailed pricing, volume estimations etc.
Taking into account the above assumptions, you could earn 30.933 EUR monthly and 371.192 EUR annually on such a portfolio. Seems high? Interested what cost of investment is needed? Contact us.
Thanks for reading.
PS. If you are interested in receiving an Excel file related to these calculations, let us know at sales@verestro.com.
Regulatory and license impact on card issuing
Legal issues related to regulatory or payment scheme rules often arise in questions we receive from our partners and clients. In this article I would like to summarize key dependencies, limitations and rules that have a very important impact on payment accounts opening, card issuing and also acquiring or money transfer activities.
When you are launching a payment institution, you have several areas to cover. One of the most important of them is a legal and rules area. Usually this impact can be divided into three main groups of activities: legal requirements, anti-money laundering requirements (which is a specific type of legal requirements) and payment scheme rules. Let me deep dive into each of them.
Legal requirements
To operate payment activities, almost in any country you need to get a payment license. There are various types of payment licenses depending on the country, so here I would like to summarize the most important details. In many cases you can hear about EMI (Electronic Money Institution license), Bank (Banking license), Credit Institution, Acquiring Institution etc. These requirements are usually connected with operational activities that the company needs to fulfill to perform payment operations for other entities. They consist of:
- Regulatory requirements in the areas of security, Know Your Customer, AML, liquidity operations, organizational structure etc.
- Audits performed by regulator
- Risk of penalties for both the company and sometimes persons involved in payment companies
- Outsourcing activities compliance
- Local laws that forbid processing customer or transaction data outside of the country
- etc.
It is important to understand details of such requirements and to follow changes of law and rules on a regular basis.
From the business point of view those requirements force us to :
- Officially register contracts with various partners at the regulator
- Get an approval for particular actions outsourced to partners
- Perform regular monitoring of payment activities done with cards issued for users of our partners
- Follow the national and EU sanction lists
- Being ready to block any transaction, account or card at any time
For our partners - just make sure that you follow the rules we inform you about. They are critical for our activity, licenses, so in fact they are securing your business.
AML and KYC requirements
AML (Anti-Money Laundering) and KYC (Know Your Customers) are part of legal requirements but it is worth presenting them as a separate group because they usually have the biggest impact on operations. The main goal of these rules is to ensure that payment organizations are not used to launder money, support terrorist or illegal activities. They also allow governments to monitor a payment activity area which may be helpful in fighting crime activities.
Key areas of impact of those requirements can be summarized as follows:
- Payment institution is obliged to perform KYC requirements as defined by the regulator - usually consisting of collected proofs of user identity verification (documents, videos, selfie, talks, and other measures)
- In case of business customers and business accounts, not only Board Members but also Beneficiaries of the companies need to go through a KYC and sanction list screening. Beneficiary is defined usually as a person with above 25% shares
- At any moment a payment institution must be ready to present these documents to the regulator
- Persons and entities placed on sanction lists cannot use services of a payment company
- Active monitoring of payment transactions for all users is required
- Sometimes proofs of income can be required
It is interesting that AML and KYC requirements do not block us from issuing cards or opening payment accounts for partners located outside the European Union with our payment companies licensed in the European Union. We are allowed to perform payment activities for Brazil, US, China citizens, as well as the Polish, German or French ones.
Make sure that you collect user documents and provide them during the user registration to us to fulfill those requirements.
Payment Scheme requirements
Payment Schemes (Mastercard, VISA or others) have separate requirements that must be followed by their partners and licensees. These requirements are similar to the previous ones but not always the same. Key requirements that do have impact on business are:
- We are licensed for a particular country or region. In our case it is the European Union countries (in fact the European Economic Area, which is a slightly different area). It means that with our European licenses we can issue cards for people residing, having addresses or working in the European Union. In case we would like to issue cards for people or entities from outside the European Union we have to get special Mastercard approval which is not impossible but may be difficult to achieve.
- We must follow payment scheme requirements on sanction lists and scan users and beneficiaries against OFAC (US Office of Foreign Assets Control) and United Nations sanction lists.
- We must be ready to follow Mastercard technical and rules requirements that sometimes may have impact on technical setup and use cases of your users
- In case of mandates we need to be ready to implement on time necessary system updates to reach compliance with the Mastercard network
Problematic areas
Usually problems in a business discussion come in the following areas:
- Can we issue cards for non-EU citizens? Answer: generally yes, but sometimes there may be problems, the majority of your business must be in Europe, your user addresses or office should be in Europe etc.
- What documents do we need to transfer to you during registration? Answer: selfie, international passport is usually a minimum
Following regulatory, AML and payment scheme rules is critical for payment companies. We do not have a choice. This is part of the game of card issuing and we must follow requirements. However, it is good that such rules exist. They make our customers' money safer and minimize much bigger risks of running or supporting illegal activities.
Thanks for reading.
KYC and KYB requirements in card issuing
KYC (Know Your Customer) processes usually raise a lot of questions. In this article, I would like to summarize the most important decision points and requirements.
KYC regulations are directly connected with Anti-Money Laundering (AML), regulatory and sometimes with payment scheme requirements. In general, every payment or banking institution must be aware who its customers are, should know the source of its customers' funds, and should have information about the ways customers use money held by the payment institution. Regulators require that payment institutions know and monitor this in order to limit the risk of supporting terrorist or illegal actions.
The main question in every project is: "Who is the owner of the money on account?" We can have 2 situations:
1. CONSUMERS - If the consumer is an owner of the money on account, the KYC process has to happen. Usually it means that the user (consumer - not a company) needs to provide an ID document or passport and selfie, meeting or video call needs to happen to make sure that consumer is a real person signing a contract with a payment institution. There are various additional verification ways that a payment institution may require, but those are the key ones.
2. BUSINESSES - If a company is an owner of money, the KYB (Know Your Business) process has to happen. Usually it means that the user (company owner, manager etc.) not only needs to provide an ID document and make a selfie or a video call, but the payment institution needs to verify beneficiaries (the owners of more than 25% of shares in the company).
In both cases the payment institution is obliged to check whether the consumer, business manager or business owner is not present on various sanction lists, i.e. OFAC or UN sanction list.
These rules are critical and in fact all other implications are outcomes of them. In projects connected with launching Payout to Cards, the very first question that we need to answer is : "Who is the owner of the money on account?" If the consumer is an owner of the account (scenario 1) - the consumer needs to go through the KYC process. If the business is an owner of the money on account (scenario 2), the KYB process will have to happen and there will be no additional KYC.
There may be non-standard situations that will require some analysis. Let me present a few interesting scenarios:
- Lendtech - a company that provides loans to consumers. Let's imagine that this company is giving a loan of 1000 EUR to a consumer. We can have a project in two versions:
- if the consumer receives a loan on his/her personal card - then we have the KYC requirement.
- but if a card is just a part of Lendtech account and formally the consumer gets a loan at the moment he/she takes out money from the card account - we do not have any KYC requirement; we just need to do KYB for Lendtech. It can simplify user acquisition a lot.
- Insurance - an insurance company sends insurance value to users after a claim process or just after an accident:
- if the user receives a gift card with 1000 EUR, which is the value of the claim, and at the moment of receiving the card, 1000 EUR on this card becomes his/her ownership - we have the KYC requirement for the user.
- but if the user receives a card with a limit of 1000 EUR and when they pay - they use the insurer's money to cover costs of the claim, we do not have any KYC requirement. KYB will be enough for us.
- Money transfer company - let's imagine that the company sends a virtual card with 1000 EUR from Europe to the receiver in Singapore:
- if the user receives a virtual gift card, and 1000 EUR belongs immediately to this user, we have to do KYC of this user
- however, if users receive a virtual card with a limit of 1000 EUR and the money becomes theirs the moment they pay or withdraw funds from the card, KYC is sufficient. KYC is not required.
As you can see, there can be different approaches to KYC and KYB requirements, so it is worth reviewing the legal structure and thinking about how to improve the user experience in such projects.
Thanks for reading.
PCI DSS & other security requirements
Very often customers ask questions connected with security. In this article we would like to summarize key requirements connected with Payment Card Industry Data Security Standards (PCI DSS). There are other rules that we and our partners need to follow (like GDPR for example) but it will be the topic for another article.
The most important question that needs to be answered before going into details of PCI DSS requirements is - Am I actually processing payment card data?
Key PCI DSS requirements mentioned below apply only in case that the partner has access to card number (PAN - Primary Account Number), expiry data or other related card data. If the partner does not touch them, if the partner cannot see those numbers there is only one requirement - a simple Self Assessment Questionnaire (SAQ) needs to be fulfilled to confirm that the partner is compliant with PCI DSS requirements.
It is very important that you choose the correct way of integration with the card issuing platform. If you use our mobile SDKs or white label products, usually you will not have access to card data and will be able to approve your project just after fulfilling SAQ mentioned above. So please consider this way of integration to avoid additional costs and risks of PCI DSS compliance. However, if you connect via API, which is a usual way of integration, you will have to comply with security rules. Please read this section twice. This is the most important - choice of integration method will be decisive if you have to or not go through annual external audits and all hassle connected with PCI DSS.
Assuming you do process card data, depending on what your role is, different levels will be applied to you. You can be a merchant or a service provider. In simple terms, if you do the work for yourself then you are a merchant if you want to further provide the service (intermediary) you are most likely a service provider. In card issuing projects you will rather be a service provider because you offer cards to your users. Let me give some examples:
Service Provider - wallet, crypto wallet, money transfer organisation offering cards to own users etc.
Merchant - an insurance company that wants to use a card to send money to their users, a lending company that wants to send a card to users, a corporation or SME giving business payment cards to their employees etc.
Who is according to PCI DSS "Merchant"
PCI DSS, or the Payment Card Industry Data Security Standard, defines a merchant as any entity that accepts payment cards (such as credit cards and debit cards) as a form of payment. The term "merchant" can encompass a wide range of businesses and organizations, including traditional retail stores, e-commerce websites, restaurants, hotels, and service providers that handle cardholder data.
Under PCI DSS, merchants are required to comply with a set of security standards and practices to protect the payment card data they handle. These security measures are designed to ensure the confidentiality and integrity of cardholder data, reduce the risk of data breaches, and protect both customers and the payment card industry as a whole.
PCI DSS compliance requirements can vary depending on the merchant's size and the volume of card transactions they process. Merchants are typically categorized into different levels based on their transaction volume, with higher-volume merchants facing more stringent compliance requirements.
There are 4 levels of compliance and requirements depending on volumes of cards and transactions.
Level of PCI DSS |
Your business does |
What you should do |
4 |
· Less than 20 000 eCommerce transactions per year · Less than 1 million other transactions per year |
· Complete an annual Self-Assessment Questionnaire (SAQ) · Conduct quarterly network scans by an Approved Scanning Vendor (ASV) |
3 |
· 20 000 – 1 million transactions per year |
· Complete an annual Self-Assessment Questionnaire (SAQ) · Conduct quarterly network scans by an Approved Scanning Vendor (ASV) |
2 |
· 1-6 million transactions per year |
· Complete an annual Self-Assessment Questionnaire (SAQ) or ROC conducted by a QSA · Conduct quarterly network scans by an Approved Scanning Vendor (ASV) |
1 |
· 6 million + transactions per year |
· Complete an annual internal audit · Conduct quarterly network scans by an Approved Scanning Vendor (ASV) |
Who is according to PCI DSS "Service Provider"
According to the Payment Card Industry Data Security Standard (PCI DSS), a Service Provider is defined as any business or entity that is not a payment card brand (such as Visa or Mastercard) and is involved in the processing, storage, or transmission of payment card data on behalf of another organization. Service Providers play a crucial role in the payment card ecosystem, as they offer various services to help businesses accept and process card payments more effectively and securely.
Service Providers can include a wide range of businesses, such as:
- Payment processors
- Payment gateways
- Hosting providers
- Managed security service providers
- Data storage companies
- Point-of-sale (POS) system providers
- Customer relationship management (CRM) software providers
- Software-as-a-Service (SaaS) providers
Service providers are categorized based on the services they provide and their interactions with payment card data. Here are some common classifications of service providers based on PCI DSS:
Level of PCI DSS |
Your business does |
What you should do |
2 |
· < 300 000 transactions per year |
· Complete an annual Self-Assessment Questionnaire (SAQ) · Conduct quarterly network scans by an Approved Scanning Vendor (ASV) |
1 (Verestro has 1 level of PCI DSS) |
· > 300 000 transactions per year |
· Complete annual internal audit conducted by a Qualified Security Assessor (QSA) · Conduct quarterly PCI ASV scans |
Verestro has the 1st level Service Provider of PCI DSS, which means that we have to go through quarterly PCI ASV scans and an annual external audit performed by certified PCI DSS assessors. In accordance with the principles of PCI DSS, Verestro is obliged to check if the partner is working in compliance with the PCI rules, so we will be checking what the level of transactions and cards in your case is.
So let's remind our two possible scenarios:
Scenario 1 (The partner does not have any access to unencrypted PAN numbers) -> THIS IS THE BEST AND RECOMMENDED SCENARIO. In this scenario you will most likely use our SDKs and admin panel and full encryption of card data. Verestro will guide which Self-Assessment Questionnaire (SAQ A for merchants) is appropriate and ask a few questions (from SAQ). The document will have to be signed by the partner.
Scenario 2 (The partner can access unencrypted PAN numbers) -> in this scenario:
- Verestro will provide a Self-Assessment Questionnaire (SAQ), and ask a few questions. The document will have to be signed by the partner.
- The partner will perform quarterly PCI ASV (Approved Scanning Vendors) scans
(cost around 1k EUR quarterly or less) - The partner can choose any provider from the PCI Security Standards Council (PCI SSC) or Verestro can recommend a supplier. - Until the partner reaches 0,3 mln transactions/interactions annually with PAN numbers, the partner does not need to undergo an annual internal audit (in extreme situations, it is possible to require PCI internal audit from the partner).
If the partner plans to achieve 0,3 million transactions/interactions, there are two options:
- either the partner will move to a scenario that does not touch card numbers using some technology changes
- or the partner should perform an annual internal audit done by a PCI auditor (QSA)
If you would like to discuss your requirements in more detail and receive more information, please contact us.
Thanks for reading.
Master balance and collateral in card issuing projects
During the implementation of card issuing projects with Verestro and our partner payment institutions, we receive questions about liquidity management and collateral in card issuing projects. Let me summarize and explain the key dependencies.
There are two important points that need to be taken into account:
1. Collateral - this is a dedicated amount of money and account which needs to be transferred by our partner to our account to cover costs of payment risks and collateral that we need to pay to Mastercard or VISA. Usually it is between 3-5 days of transaction volume. The collateral is non-refundable until the end of the project and may grow in time together with the volume of transactions. If we do not take collateral, there is a risk that in case of growth, we will have to block the partners' transactions because we will not have enough liquidity at Mastercard or VISA accounts.
2. Master balance - it is an account (in other words cash balance) dedicated to our card issuing partners where our partner stores his own money which covers fees paid to Quicko and/or transaction settlement in case of working with external balance API. There are two possible situations that affect the amount of the master balance:
-
- Scenario 1 - In case External balance API is used which means that partner keeps information about user balance and every transaction authorisation is routed to partner for approval. In such a case we have to keep the Master balance of the partner up to the amount of transactions. Every transaction authorisation is verified by the partner but also on our Master balance account. A day later we have to settle money for this transaction with Mastercard so we must have enough cash on Master balance to cover this transaction amount. Every day or any time our partner transfers additional money to the Master balance to make sure that there is enough liquidity to cover costs of transactions of their users. This means that the amount on the Master balance is high enough to cover transactions of users during a day, week etc.
- Scenario 2 - In case internal balances are used, we have a situation where all users' money are kept at our payment institution. It means that the partner does not need to provide additional funds to cover transaction volume. In such a case the partner needs to transfer just an adequate amount to cover the amount of transaction and card fees to be paid for card issuing activities.
In all card issuing projects both collateral and masterbalance exist so please make sure you are aware of differences between those two definitions.
Thanks for reading.
Pay with Rewards, Pay with Points
There are multiple use cases where you can use virtual Mastercard payment cards. Let me explain how it works, how you can offer your users a loyalty program or another point-based program to make transactions at any merchant location.
Let's imagine you provide a loyalty program for your users. You can also have any other point-based offering that enables rewards. You are interested in launching a program in which your users will be able to pay at any merchant location with a Mastercard virtual card.
In such a case you could use our card issuing services with External Balance API. It would work in the following way:
- We launch a business card program for you. We perform Know Your Business verification with you as a company. Every card issued in the program will be in fact a payment card of your company.
- You integrate with our Lifecycle API in order to register users and request cards
- You integrate with card issuing API to manage cards and with External Balance API to be able to authorize transactions.
- We would also integrate your solution with Apple Pay and Google Pay, and the cards would have your visual. Thanks to this, your users could easily use them for any payment.
- You have to decide what the value of a single point is. You will receive from our system authorization for 20 EUR and you will have to approve or decline this transaction.
- We will ask you to open an account at our partnering payment institution - you will have a Master balance which will cover direct settlement of payment transactions. You can reload Master balance every day.
- From that moment users will be carrying your payment cards in their Apple Pay and Google Pay wallets and every transaction will be routed to your system for authorization. At the moment of transaction we will use Master balance to cover the transaction cost and you will charge point balance of the user.
- Additionally, you could limit merchants where users can make transactions and get an additional fee from the merchant for enabling transactions at a particular merchant.
In today's payment world, such a project is easily available and not difficult to implement. There is a simplified integration and after several weeks you can go live with a new functionality.
Thanks for reading.
Multicurrency cards - 3 implementation options
Multi-currency topic is an interesting and important concept of card issuing that usually requires some explanation. Because of the very big market of currency conversion and usually very high fees of universal banks connected with international transactions, it became popular to implement multi-currency cards. Actually the first Revolut use case, heavily promoted several years ago, was connected with this topic. So let's go into details.
There is actually one problem that we want to solve when thinking of implementing multi-currency cards - how to enable the best and most effective card payments in an international environment? There are various approaches to this problem:
Scenario 1 - multi-currency cards and accounts
In this example we offer users multiple payment accounts in various currencies.
- The user gets a single payment card connected with all accounts
- In case the user pays with currency X, the authorisation system recognises transaction currency and debits account of currency X
- In case there is no money on this account, system debits another (default) currency
This example is very often used, but it has a few disadvantages. The first is that the user must perform currency conversion before. It is an action before his/her travel and actually it is an unnecessary action from the logic's perspective. It should be more convenient for the user to have one account and cheap currency conversion during every transaction. But usually consumers like the solution because they can manage this currency problem in advance, see FX rate and can make decisions on how much money to convert.
Implementation of this scenario is not easy because card issuing companies either need to enable multi-currency functionality with Mastercard / VISA or to implement multiple settlement accounts with payment organizations and manage conversions accordingly based on transaction currency. There are additional fees that Mastercard and VISA charge for this service which can make this implementation costly.
Scenario 2 - currency conversion on a single account
Another way of solving the currency conversion topic is to think about how to enable the cheapest conversion during a transaction. In this example the user does not have to convert currency before his travel. He just uses his card while traveling. I personally like this approach the most because it is easier for me but in reality many customers prefer scenario 1.
In this scenario, to have dynamic rates, there is a need for online FX API integration and dynamic management of rates during authorisation. Usually card issuers use static conversion rates offered by Mastercard and VISA but this leads to some additional costs and margins. Ensuring dynamic currency conversion during authorization and proper conversion management may be difficult to achieve.
Scenario 3 - multiple cards for different currencies
The third way of managing the multi-currency topic today in the virtual card environment is issuing multiple cards to multiple accounts in various currencies. In today's world this is easily achievable as the cost of card issuing went heavily down. It works in the way that users have several cards, connected with various accounts and card visuals, visible in Apple Pay or Google Pay with the currency of a particular card. The user can choose a card which is the most convenient for him/her.
In this scenario we need to offer an inexpensive currency conversion mechanism as the user needs to manage balances on each account separately and perform conversion in advance.
This is actually the cheapest scenario of implementation.
While thinking about the multi-currency topic, please consider various scenarios and ways of solving problems. Sometimes the default plan (scenario 1) can be very costly from the transaction processing perspective because of additional fees of payment schemes.
Thanks for reading.
Customer service and user claims in card issuing
Once you start issuing cards for your users, you will experience a wide range of various problems and requests coming from your customers. In this article we will summarize the most common issues, so that you can get prepared.
These include:
- Transactions not working
- Problems with delivery or activation of plastic cards
- Transaction reversals and refund issues
- Fraudster activity
Point 1 - Transactions not working
The most common problem after starting card issuing is connected with performance of transactions. Your users will inform you about problems with transaction authorisations or merchants not accepting their card etc. There can be plenty of reasons for such problems. The most important are:
Point 2 - Problems with delivery or activation of plastic cards
Usually, when you decide to use not only virtual, but also plastic cards, you will experience various problems with personalization, delivery or activation of plastic. In different countries there may be various issues with these processes. They are usually connected with logistics or lack of easy activation methods for cards. Some of those issues can be cleaned by us during the project, but for many of them we will not have a good solution. Actually, in today's digital world, we do not recommend issuing plastic cards, but if you need to do so, get ready for such problems.
Point 3- Transaction reversals and refund issues
White paying with cards, customers will experience situations that they want to resign from a transaction after some time. Sometimes immediately - and in this case reversals will be used. Sometimes after several days - in this case refund will be used. In such situations we should receive an authorization from the merchant or acquirer that credits the transaction. We should be able to deliver this message to you, so that you can increase the user's balance on account. But sometimes this process does not work correctly. If the card issuer does not receive a message from the acquirer or payment scheme, we are unable to give you this information. User's funds may get frozen for 2-4 weeks. It is important that you understand that such things happen.
Point 4 - Fraudster activity
Any new payment activity in the world is attracting the attention of fraudsters or payment mafias. There are people in the world specialised in stealing card data or making transactions with cards while having no money on accounts. This is a very serious risk for you, as they will be testing your systems as well. This is especially visible if you have many "Do not honour" transactions or weak Know Your Customer processes. Be ready for it. Monitor your traffic. Cards will not always work for all payment transactions, some fraud rules will block suspicious activities, but your online monitoring is necessary.
Those are key points to remember about. Please do not forget about them while launching your card issuing program with us.
Thanks for reading.
How to prepare for a card issuing project?
Do you want to issue cards to your users? In this article we describe what is required on your side to implement virtual or plastic cards in your applications.
Let's imagine you are a fintech, crypto wallet, lendtech or any other company with a concrete target segment, some or thousands of users and you have a mobile application for your customers. You have decided to go live with card issuance in order to increase revenue and user loyalty. Below we describe the main decisions and steps you need to take to get ready for a card issuing program:
- Decide on a card issuing partner - check out other articles we have on this topic in the Knowledge Center. Make sure that the partner has the necessary functionalities, legal requirements and flexibility that you can accept. Check your partner's financial standing. Contact us for more details.
- Analyse and describe your use cases - describe user flows, develop some initial graphs of how key processes will work. Focus on user onboarding, Know Your Customer steps, card generation and activation, card management and transaction flows. Read the Developer Zone requirements during this step to make sure you are ready to integrate without difficult customisations.
- Check the legal environment - try to analyse and understand the regulatory environment. Check if you can fulfill KYC requirements and how you can collect data from users. It is important that you submit a user selfie and document photos to the card issuer during the verification process. If you are working with us, please make sure that you have a European entity or branch in the EU to sign a contract with us for card issuing.
- Verify API integration - go to the Developer Zone and analyse APIs or SDKs that you will have to connect to. If you want to avoid PCI DSS audits and associated costs, consider using SDKs. It is highly recommended if you have a large group of users.
- Make P&L analysis - consider the revenues from card issuing and the costs of this product. Make sure you understand unit economics. You can use articles in our Knowledge Center to start this work. Choose an affordable partner - do not think that if something is more expensive, it is better in quality. The card issuing business is a cost-based business where low level unit economics matter, especially cost per card and cost per transaction. Revenue share from interchange fees or currency conversions is even more important than costs.
If you have checked these points, you are ready to sign a contract. Contact us sooner, let's work together. We can advise you on many of these points to build the best possible program for you. We have extensive experience in more than 30 countries on 5 continents. Make use of this knowledge to get started.
Thanks for reading.
How can I reload a payment account or card?
There are many ways of transferring money to payment accounts or cards. In this article we would like to explain how it can be done with Verestro and in other cases.
Let's start with definitions so that we speak the same language. What is a payment card? What is a payment account? What is an IBAN? It seems simple, but in fact many customers use these words in a different way.
- Payment Account - it is a place in the system of a payment institution which holds information about money stored for a particular customer. Just it - a kind of a Record ID in a payment institution. It is not an IBAN, it is not a card.
- IBAN - IBAN is a payment account number in an international banking standard. This number helps sending wire transfers to a Payment Account.
- Payment Card - it is another number (PAN - Primary Account Number in the terminology of Mastercard and VISA) connected with a Payment Account and usually another payment instrument connected with a Payment Account. The Payment Card is a tool to pay using money on a Payment Account and sometimes it is a way to transfer money to a Payment Account. To be honest, I do not know situations where a Payment Card works without a Payment Account. In some countries (like USA) usually a Payment Account is not used in common discussions, but in fact there is always a Payment Account connected to a Payment Card.
Once we know those 3 definitions, let's look at the ways of transferring money to a Payment Account, which in other words could mean ways of reloading a Payment Card. There are several ways that we can use:
- Bank transfer to IBAN - in such a case the user is sending money from an external bank account to our Payment Account, using an IBAN connected with our Payment Account. Usually it is a very easy, fast and effective way of transferring money in case of domestic transfers. It could be a costly way of reloading an account if the customer is abroad.
- Payout to Card - in such a case the user is sending money from another bank or money transfer organisation using a Payment Card number issued by Verestro and our issuing partner. The customer is using Mastercard Moneysend or VISA Direct to transfer money from another account to their Payment Account at Verestro. Usually it is very fast but not cheap way of money transfers.
- Card-to-card - card-to-card transfer is used when the user provides at external service another Mastercard or VISA card and transfers money to a card issued at Verestro. In such a case a funding card (a card issued by another bank) is debited and our Payment Card is credited, which means that money will appear on the Payment Account soon.
- Reload by another card via PSP, Google Pay or Apple Pay - in any wallet of our partners we can provide functionality called Paytool which enables charging another card and sending money directly to the user's Payment Account. In this situation a funding card is charged as if it was an eCommerce transaction. The user's Payment Account can be reloaded quickly.
- Reload by partner - in many cases our partners can use their own funds to reload the user's Payment Account. Examples of such situations are lending institutions that issue a card and reload a Payment Account with a loan amount. Similar example could be issuing cards for insurance related claims - in such a situation our partner (insurance company) adds money to the user's card and sends the card to the insured person. Usually such a reload happens via MasterBalance which is an account that we hold for our partners and it contains their money. This account can be used for a reload, as is usually used for transaction processing.
- Reload by crypto assets - in some cases it is possible that our partners send crypto assets and we will convert them in cooperation with our partners into FIAT currencies to reload the user's account.
- Openbanking - our partners can use open banking PIS (Payment Initiation) messages to transfer money to the user's Payment Account. We can help with such reload tools using our Paytool product.
Those are ways of reload we use today. We are happy to work on other ways of money transfers and enable new ones.
Thanks for reading.
Card Lifecycle Management
Once launching card issuing projects, our customers usually forget that it is a long-term activity that requires constant verification and improvements. It is very important that you understand and manage your card holders and use best practices in card lifecycle management. Let me summarize key activities from a timeline perspective.
Stage 1 - choosing a card issuing partner
Obvious step. Everybody focuses on financials and technical integration. Very few people check value-added services and other products. Almost no one is aware of PCI DSS & other security requirements that will make your life easier on stage 4 and later ones. Another common mistake is that you do not check the financial stability of your card issuing partner as if it is not important for your business and users.
Stage 2 - implementation
Obviously important. No comments. Check Dev Zone and implement. Make sure your developers read specs carefully. Make sure you understand AML and KYC regulations so that you can comply with rules and the project can be built on strong fundamentals. A common mistake is not to consider Stage 4 - card lifecycle management processes are forgotten.
Stage 3 - launch
Everybody focuses on this moment, plans campaigns, distributes cards. And usually this is the last implementation step of this new product. It is a mistake.
Stage 4 - card lifecycle management
Once you are up and running, it is very important that you are able to monitor your portfolio, create reports, organise personalised campaigns and manage your portfolio in a very active way. There are several rules to follow in order to maximise your portfolio's earnings and performance. The most important ones are summarised below:
- Portfolio Manager - have people that will be responsible for the management of your portfolio. 1 person is enough at the beginning. Make sure these people understand goals and work to make your cardholders active
- Reporting system- make sure you have a flexible reporting system that gives you information not only about the number of issued cards and transactions, but more importantly on the behaviour of various customer groups:
- have reports how many customers used the card after 1-2 days, be able to find the user IDs
- have reports with customers that used the card after 5 days, 15 days, 30 days
- have reports on inactive customer groups
- Actions - be ready to act basing on the user behaviour
- once you see that your customer is not using the card after 1-2 days - send him/her a notification or an educational reminder
- once you see that the customer is not using the card for 15 days - maybe you should send a small digital gift to the customer and deliver it if he/she starts using card
- if you see an inactive customer after 30 days - ask them why they are not using the card; maybe you will get a correct feedback
- Reporting - again and again check if your actions work correctly. What is their success rate? How are your customers changing their behaviour?
- P&L analysis - make a detailed analysis from a financial perspective, incentivise users to do transactions that are bringing more revenue, think of increasing monthly fees for non-active users
- Quality reporting - check the quality of your services, ask users for feedback regularly, collect information, analyse it, make actions to improve
- Value-added services - think of launching new services that can improve performance of your portfolio. Maybe a voucher-based ending, card-to-card money transfers, loyalty programs etc. Ask us for best practices and tools that are easy to use.
- Education (super important) - never underestimate the importance of educational messages. You can teach customers how to use the card on the internet, tell them how to tokenise the card in Apple or Google Pay, show them how to pay at ATMs. Card issuers tend to forget how cheap and profitable it is to work on user education. Do not assume that everyone everywhere uses payment cards the way you use them today. People sometimes do not know how to use 3DS, they are afraid to use it, etc. Work on that.
- Learn, change, improve...
Card issuing is a long-term activity. Please do not think that you will launch it and everything will work properly. You should be constantly working to attract more users and teach existing users how to use the cards so that they add real value to your business. Good luck!
Thanks for reading.
VISA or Mastercard?
Sometimes our customers ask if it is better to issue VISA or Mastercard cards. In this article we would like to answer this question.
Main payment schemes
There are two main payment schemes in the card area that have almost monopolized global card business - VISA and Mastercard. Next to them there are several local schemes, sometimes going global that are also worth thinking of in more sophisticated global projects (like UnionPay China, JCB Japan, EC Karte Germany etc.) but in general in majority of projects you will do the business decision if you prefer to issue VISA or Mastercard cards.
In one sentence the answer is - usually it does not matter. But if you go into details, depending on the country or type of the program there may be some important differences worth considering.
Key decision points
Below we present some important decision points:
- Financial and marketing support - depending on the country and type of program VISA or Mastercard can decide to support your program financially or from some marketing assets. If so, it makes sense to consider this as an important factor in the decision making process. Check with your card issuing partner if there are such possibilities.
- Interchange differences - in some countries (outside of the European Union) there are slight but important differences in Interchange Fees which in the end means that you can earn more from every transaction. Check with your card issuer if such a situation exists on your market. If you are going to offer cards globally, it may also be possible that inter-regional (inter-continental) transactions will be more profitable in one payment scheme. So it is worth checking.
- Cost factors - usually fees connected with a card issuing program will be dictated by your card issuer or BIN Sponsor but in some cases a card issuer may have different fees depending on the cost of VISA or Mastercard transaction fees.
- Special local or global card benefits programs - both Mastercard and VISA are developing various loyalty, discount, value added services that can make your program more interesting for users. In Poland, for example, Mastercard is running a very attractive card benefit and loyalty program called "Priceless Specials". It is worth checking as it may be an important value added for your portfolio and users that may be much more important than any financial details.
- Brand and acceptance - in 95% of countries there is no visible difference in acceptance and brand between VISA and Mastercard. But in some cases it exists. For example if you are going to issue cards in Hungary - Mastercard is much more popular and customers are used to it. It is worth checking before making a decision.
- Educational and consulting support - it can be valuable help. In various projects, countries or regions payment schemes can have services or people that can help you a lot in defining a good value proposition and important details of a card issuing program. This may be very valuable as very often employees of Mastercard and VISA are very professional, have a lot of knowledge and can help you in developing your portfolio. If you have such support, try to use it.
- Shareholding connections - in some cases (like Verestro) one of the payment organizations (in our case - Mastercard) will be a shareholder of your partner. It may be very valuable as you will have in-depth support of the payment scheme and card issuer. It may be useful in various situations, difficult cases connected with rules etc. Make use of such cases, if you can.
Conclusion
Those are the main differences. It is worth considering. In the majority of cases your partner in card issuing will have some preferences and sometimes there will be no choice. But it is certainly worth considering when deciding which card issuer and payment scheme to choose.
Thanks for reading.
Card Benefits in card issuing projects
Once you are launching your card program it is important to think about additional benefits that you can deliver for your users or products that can increase the value of your program. In this article we will show a few ideas and examples that you can use to enhance your card issuing project.
How to strenghten your card issuing program?
- Education and messaging - the most important but very often forgotten. No cost benefit. Just start teaching your users how to use cards, how to behave in a secure way, how to pay on the internet, how to connect to Apple Pay or Google Pay etc. Build ways or use our white label ways of communication. It will pay back for sure.
- Enable new ways of payments - enable new ways of payments for your users. Teach them how to use their card in a friendly, secure, internal environment. Maybe they can buy something on your platform, maybe you can enable money transfer from cards etc. Thanks to such activities you will teach them how the card works and what they can experience. You will lower the level of fear and risks they may fear at Point-of-Sale.
- Insurances - think of launching a program with insurances. This became very popular 10-20 years ago in the card business. Many banks give users additional insurances that they can buy in their apps. Insurance is an ideal product and card benefit because it increases security feeling among your users. Examples of such insurances are eCommerce payment extended insurance, lost & theft insurance, travel insurance etc.
- Point based loyalty program - think of launching a point based loyalty program or join an existing one. We are using the Priceless Specials program done by Mastercard. This can be a strong added value that you can communicate. You can also increase revenues thanks to it and increase cross-selling if you start giving points to users for using non-card based services that you are selling. It may seem difficult to implement but actually it is not.
- Voucher based loyalty program - once you have a growing number of users you can start arranging special promos with eCommerce or offline merchants. We can help with it as we are building a network of such partners. Thanks to such activities your users will get additional margin or cash back and it will increase retention and happiness of your customers.
- Premium cards - maybe it is worth thinking of launching new gold, platinum or World Elite cards for your users. Maybe you could offer much better VIP service, together with a concierge for much higher fees. It is very popular among banks and it is one of the easiest ways to increase profitability of the portfolio.
There may be more activities but these are the ones that you can implement relatively quickly in order to offer better service and increase revenue.
Prepaid, debit or credit cards - the main differences
Before launching a card issuing program, our customers consider which card product to use. In this article we will summarize the key differences and considerations.
There are three main groups of payment cards: pre-paid, debit and credit cards. Below we summarize the most important differences.
Prepaid cards
- user has to reload a card account to use a card (like in debit cards by the way)
- you can issue anonymous, non-reloadable gift cards
- in some cases merchants block BINs of prepaid cards more often than for debit or credit cards
- you can have consumer and business prepaid cards
- in many countries, from legal perspective, there is no difference between prepaid and debit cards
Debit cards
This is the biggest group of cards in the world:
- user has to have a payment account or current account connected with a card
- user has to go through a KYC (Know Your Customer) process
- user has to reload a payment account to use card
- usually you cannot issue anonymous cards, because in general they are always reloadable
- sometimes, if you give a loan to your customer, a debit card can work like a credit card
- you can have consumer or business debit cards
- you can have Gold or Platinum debit cards
Credit cards
- user applies for credit and gets it in the form of a card
- usually connected with a revolving credit (something like credit line) and a grace period (no interest for 40-50 days)
- because of the credit, the user needs to go through KYC and credit scoring, so it is more difficult to issue than prepaid or debit cards
- you can have Gold, Platinum or World Elite credit cards
- you can have consumer or business credit cards
- usually an interchange fee is a bit higher than in case of debit cards
- sometimes approval rates for transactions are higher, some merchants (car rental) require credit cards from their customers
- because credit line is connected with this product, usually it is more profitable than a prepaid or debit portfolio
These are the main differences between the above mentioned products. In most cases, you should be thinking about debit cards because they give you the same benefits as prepaid ones, and you can convert them into credit cards by giving loans to your customers.
Tips to avoid problems when implementing card issuing
So you have a good business case for issuing cards for your customers and you found a perfect vendor who can provide formal and technical services in this area. Right after signing the contract you’re ready to implement. What now?
Now it’s time to make sure that the implementation will be as smooth as possible and you and your team won’t get stuck on some of the common problems that may happen in the project. Of course each vendor has his own approach, but let us explain how to avoid some of them based on Verestro’s experience.
Preparing everything for you takes a moment
Depending on your particular setup we will need 4-8 weeks to prepare everything for you. From dedicated environments so that your customers and their cards will always be safe and secure, to ensuring that you will be able to use the cards in Apple and Google wallets and that your proper logo will appear in the 3DS confirmation screen when customers will be paying online. In the meantime you can focus on understanding all the APIs using Sandbox environment and make sure that your team is ready for the work in front of them – for example by analyzing the documentation carefully. Our services will be available for you one by one, so you don’t need to wait full 8 weeks to start implementation – usually first work on your side starts after 2-3 weeks from the kickoff meeting.
Test and adapt
Everyone is always eager to launch the product to final customers – that’s obvious. But it’s good to plan an extensive testing phase that will limit the potential volume of incidents that may happen once you’re live. A simple successful transaction done in ecommerce and brick and mortar POS is a very good prognosis, but should not be the end of testing phase. Take into account different scenarios and edge cases (like reversals and refunds – or even partial reversals). Take into account that there are many players in the world of payments and that a simple transaction is actually a connection of several backend systems (acquirer, issuer, payment network, additional vendors). The more you test, the less surprises will be there in the end.
Knowledge and understanding is key
Issuing cards and processing transactions is unfortunately not like riding a bike – it’s easy to forget. During the project with Verestro you’ll learn a lot about the world of payments and cards. Make sure this knowledge is gathered on your side and distributed between team members.
Plan your MVP
Rome wasn’t built in a day. Best banks did not simply appear in a moment. Issuing cards is a vast topic that requires a lot of iterations to make sure the basics are solid. It’s always good to start with essentials:
- Create user
- Create their balance
- Issue first card
- Digitize the card in Apple/Google Wallet
- Make first eCommerce transaction (with 3DS)
- Make first POS transaction
- Run ‘friends&family’ phase within your company
- Then start adding features and more functionalities
If you’ll start focusing on ‘nice-to-have’ features too early in the process, you may loose sight of more basic processes what may cause delays in the whole project.
Having all of that in mind should make your project more streamlined and effective.
Know Your Customer – in-house or outsourcing
From time to time, our customers ask us whether it is better to perform Know Your Customer activities in-house or to hire a company to do it for them. In this article we would like to answer this question.
KYC activities are very important. On-boarding your customer is actually the first process that the customer uses, so smooth processes are critical for our future relationship with a particular customer. If the process does not work correctly, the customer can block and all our marketing and acquisition efforts will be useless. But how to do it right?
You can have 2 general scenarios:
Scenario 1 – build KYC in-house
You can start building this process yourself using your IT team. Actually, it is not so difficult. The process consists of a few obligatory steps that have to be performed by user:
- Get user data
- Get user photo or video
- Get pictures of user’s document or documents
- Check sanction lists
- Approve / decline / get into interaction
It seems to be easy 😊 but actually it is not so easy. There are some security and legal regulations that need to be fulfilled. There are specific requirements of payment institutions that will have to be fulfilled. You need to collect this knowledge, be ready to update your systems. Additionally, you have to think of automatizing this process on your side so that the user does not wait too long for approval of their application. From a financial perspective it sometimes can be much cheaper than automated KYC. Let’s do a quick calculation. If you hire a person and pay 10 EUR per hour to this person for performing KYC activities you can imagine that such a KYC employee will perform simple consumer KYC actions (verification of data, photos etc.) for one customer during 1 minute. It means that the cost of processing a single application is 10 EUR divided by 60 minutes = 0,16 eur per user!!!
Additionally, if you need to perform regular scanning of sanction lists, avoiding per user costs becomes more critical because there may be requirements that users are scanned against sanction lists once per month… If you have 0,1 eur cost per such scanning it means that you have variable cost of your operations. Very important disadvantage.
Advantages:
- Full control over the process
- Possibility of changing process in-house after product launch
- Full control over costs
- Possibility to avoid variable costs per user
- Possibility to avoid recurring costs per user
- Quicker responses to regulatory complaints as everything is in your system
- No dependency on external partners
Disadvantages:
- You need to spend time and energy on this process
- Time consuming process
- High fixed costs (team to develop and update the system)
Scenario 2 – outsource KYC
In this scenario you perform a tender and choose the best KYC provider for you. You can be quick with this process, you will get all technology this partner has but you will have to pay per user and maybe for some development and customizations. You will have an outsourcing company that most likely will have to be officially registered at your regulator as you are outsourcing anti-money laundering processes to this partner. It is definitely an easier process at the beginning of your journey but think about dependencies and cost.
In the long term you may also encounter problems with your partner that some specific requirements or unhappy path for your users does not work correctly. You should not think that you can automatize 100% of your on-boarding processes and you do not need to hire anyone. You must have some manual process, possibility to check application yourself and you must hold data yourself for future use.
From a financial perspective – you will have to pay per user or sometimes recurring fees per verification additionally. This may be a heavy cost for your business model. I think that this long term dependency is the critical disadvantage and you need to be careful.
Advantages:
- Quick time-to-market
- Professional processes achieved quickly
Disadvantages:
- High variable costs – clicks per user, monthly per user etc.
- Dependency on particular vendor
- Tendency to forget that you must have manual processes built together with such partner
- Risk of regulatory incompliance in case you do not monitor partner correctly
Summary
It is a difficult choice. In our opinion, in the short-term, it may be better to involve a 3rd party. However, in the long term, risk of dependencies, partner stability and variable fees seem important and you need to carefully consider if you do not want to have those capabilities in-house. Please also remember that while implementing 3rd party automatic solutions, you must have a manual process ready to process unusual customers.
Our services in this area are focused on this strategy. We use both 3rd party vendors and an internal system for managing KYC processes for ourselves and for our customers.
Reverse solicitation – marketing & promotion of card issuing in multiple countries
One of the limitations in global card issuing and account opening activities is connected with licenses and regulations for particular countries. Payment institutions have Mastercard or VISA licenses for particular countries as this is the way Mastercard and VISA systems work. In the European Union it is possible to get a license for the whole region but in other countries and regions you must get a license per country.
This makes the process of card issuing difficult in today’s digital economy because you usually do promotional and marketing activities in multiple countries. You have users from Europe, Asia, Africa, Americas and other continents. It would not be smart to limit your payment services only to users from particular countries.
This is a critical point and you should be discussing this point with your card issuer at the beginning of your cooperation with them. The answer to this problem is not easy or white-black. There are some important considerations that we present below:
- Multi card issuing and multi card processing – we believe that integrations with multiple card issuers that have licenses in multiple countries is critical for the success of global programs. Verestro works with payment organizations in multiple countries and solves this problem globally. In such cases, those problems disappear.
- Regulatory compliance – your payment institution must check if it is legally possible to open a payment account and provide payment cards to users from many countries. In case of Quicko (our BIN sponsor) we are allowed to open payment instruments and accounts to users from multiple countries assuming we fulfill AML requirements
- Mastercard and VISA rules – Mastercard and VISA give licenses for particular countries. It is impossible to get a license for all countries. There are some specific processes to get approval for program in other countries than you have payment scheme license but it is not clear in fact and there are some risks for every program
There are some general rules that you should follow as our partner so let us describe it:
- You should be able to prove that the main focus of your marketing actions is in Europe if your card issuer is based in the EU. We may ask some additional questions. Mastercard can have a look at places where transactions are happening etc. Try to focus on Europe.
- You should be able to provide proof that even if we are distributing cards to consumers living abroad there is an economic interest of those people in Europe. Maybe they travel to Europe, maybe they have employees in Europe etc.
- If you are distributing cards to companies, make sure they have headquarters or offices located and registered in Europe.
- The best would be that your users have resident addresses in the European Union that they are registering during card on-boarding. This solves all the problems.
- We would like to be aware of your marketing activities in countries outside of Europe. It is important that we are aware, maybe we inform local Mastercard so that they are aware.
Our intention in the long run is to solve this problem by working with multiple partners globally and grow with licenses to other countries together with our customers. Don’t hesitate to contact us if you want to do global card issuing business.
Interchange Fees and Service Fees - rates and rules
Disclaimer. This article shows in some detail the topic of Interchange Fees. It is presented in the best way to make business decisions, but unfortunately this topic is very complex, so it does not cover 100% of information. If you need 100% of information, please check the Mastercard and VISA interchange manuals. Please take into account that this article is written in May 2024, we will try to update information regularly, but make sure you get up-to-date information before making final business decisions.
Introduction
Interchange Fees and Service fees are fees that the issuer of cards gets or pays from/to an acquiring institution to cover cost of payment transaction or payment instrument. Those are fees connected with using Mastercard or VISA cards that are dependent on the decision of payment schemes and they improve or decrease P&L from card issuing activities. In Mastercard manuals they have the following definitions:
- Interchange Fee —The fee that passes between the acquirer and the issuer with respect to the interchange of a transaction conducted at a merchant, the “purchase” part of a “purchase with cash back” transaction or a merchandise transaction conducted at an ATM terminal, including a chargeback, second presentment and reversal of such a transaction.
- Service Fee —The fee that passes between the acquirer and the issuer with respect to the interchange of any other type of transaction, including a manual cash disbursement transaction, ATM transaction, PIN-based in-branch cash withdrawal, “cash-back” part of a “purchase with cash back” transaction, refund, or payment transaction (such as MoneySend or Gaming Payment Transaction), including a chargeback, second presentment and reversal of such a transaction.
This is quite a complicated topic and we will not be able to cover all details in this chapter but let us try to answer 90% of questions coming from this area. There are several factors impacting the level of interchange. The most important are:
- geography - in which the country transaction was performed. Usually Interchange is higher for transaction performed in other countries, especially other continents
- type of card - consumer vs business, debit vs credit. Consumer cards usually have lower interchange than business cards. Debit cards usually have lower interchange than credit cards.
- type of transaction - there may be different interchange for transactions performed online or offline, face2face POS or eCom merchant, bill payment or government, contactless vs chip&pin etc.
Let's start with information about types of interchange from geography point of view. There are 3 important groups of transactions:
- domestic transaction - transaction performed at Polish merchant, Polish acquirer with card issued in Poland
- intra-EEA transaction - transaction performed in one of EEA countries (see below), EEA merchant, EEA acquirer, Polish or EEA card issuer
- intra-European transaction - transaction performed in one of Eastern European countries (see below), Eastern European merchant, Eastern-European acquirer, Polish or EEA card issuer
- inter-Regional transaction - transaction performed in any other country, usually another continent, with card issued by EEA issuer
The Mastercard EEA subregion where we are located today for purposes of the application of intra-EEA interchange fees includes the following:
- the Member States of the European Union: Austria, Belgium, Bulgaria, Croatia, Czech Republic, Cyprus, Denmark, Estonia, Finland (including Aland Islands), France (including French Guiana, Guadeloupe, Martinique, Réunion, Saint Martin [French Part], and Mayotte), Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal (including Azores and Madeira), Romania, Slovakia, Slovenia, Spain (including Canary Islands, Ceuta, Melilla), and Sweden
- and Iceland, Liechtenstein, and Norway (including Svalbard and Jan Mayen), Andorra (for transactions with above mentioned countries).
The Mastercard Western subregion includes the following: • All EEA subregion countries/territories previously stated • Switzerland, Andorra, Monaco, San Marino, and Holy See (Vatican City State), Antarctica, Greenland, Faroe Islands, Saint Barthelemy, Falkland Islands, Guernsey, Isle of Man, Jersey, Saint Helena, Ascension and Tristan Da Cunha Helena, South Georgia and the South Sandwich Islands
The Mastercard Eastern subregion includes the following: Albania, Armenia, Azerbaijan, Belarus, Bosnia and Herzegovina, Georgia, Israel, Kazakhstan, Kosovo (United Nations Mission in Kosovo), Kyrgyzstan, Macedonia, Moldova, Montenegro, Russian Federation, Serbia, Tajikistan, Turkey, Turkmenistan, Ukraine, and Uzbekistan.
Additional complexity comes from types of cards. There is different interchange for :
- debit consumer cards
- credit consumer cards
- business debit cards
- business credit cards
- Premium cards (usually credit)
- etc.
Let us simplify this topic by creating a few tables with the most important Interchange Fee examples that we recommend to use for your business calculations.
Consumer standard Mastercard debit cards for cards issued in Poland (Polish BIN)
Domestic transaction |
0.2% some local interchange levels apply for government, bill payment - usually max fee level is defined in those programs. |
Intra-EEA transaction | 0.2% |
Intra-EEA ATM Service Fee | 0.5 EUR + 0.12% |
Intra-European POS transaction | 0.59% |
Intra-European full 3DS transaction | 1.19% |
Intra-European ATM Service Fee | 1.3 EUR + 0.2% |
Inter-regional transaction POS | 1.6% |
Inter-regional transaction full 3DS | 1.54% |
Inter-regional ATM Service Fee | 0.3 USD + 0.6% |
Consumer Premium Mastercard debit cards for cards issued in Poland (Polish BIN)
Domestic transaction |
0.2% some local interchange levels apply for government, bill payment - usually max fee level is defined in those programs. |
Intra-EEA transaction | 0.2% |
Intra-EEA ATM Service Fee | 0.5 EUR + 0.12% |
Intra-European Premium POS and 3DS transaction | 1.55% for Platinum |
Intra-European ATM Service Fee | 1.3 EUR + 0.2% |
Inter-regional transaction POS and full 3DS | 1.85% |
Inter-regional ATM Service Fee | 0.3 USD + 0.6% |
Consumer Super Premium Mastercard debit cards for cards issued in Poland (Polish BIN)
Domestic transaction |
0.2% some local interchange levels apply for government, bill payment - usually max fee level is defined in those programs. |
Intra-EEA transaction | 0.2% |
Intra-EEA ATM Service Fee | 0.5 EUR + 0.12% |
Intra-European World Elite transaction | 1.8% |
Intra-European ATM Service Fee | 1.3 EUR + 0.2% |
Inter-regional transaction POS and full 3DS | 1.98% |
Inter-regional ATM Service Fee | 0.3 USD + 0.6% |
Consumer Mastercard credit cards for cards issued in Poland (Polish BIN)
Domestic transaction |
0.3% some local interchange levels apply for government, bill payment - usually max fee level is defined in those programs. |
Intra-EEA POS transaction | 0.3% |
Intra-EEA ATM Service Fee | 0.5 EUR + 0.12% |
Intra-European POS transaction | 0.59% for Platinum |
Intra-European full 3DS transaction | 1.19% |
Intra-European ATM Service Fee | 1.3 EUR + 0.2% |
Inter-regional transaction POS | 1.1-1.6% |
Inter-regional full 3DS transaction | 1.54% |
Inter-regional ATM Service Fee | 0.3 USD + 0.6% |
Business Mastercard debit cards for cards issued in Poland (Polish BIN)
Domestic transaction |
0.2% some local interchange levels apply for government, bill payment - usually max fee level is defined in those programs. |
Intra-EEA POS transaction | 1.5% (minus 0.3% if acquirer meets some criteria) |
Intra-EEA full 3DS transaction | 1.75% (minus 0.3% if acquirer meets some criteria) |
Intra-EEA contactless transaction below EUR 25 | 0.8% |
Intra-EEA ATM Service Fee | 0.5 EUR + 0.12% |
Intra-European POS chip&pin transaction | 1.7% (minus 0.3% if acquirer meets some criteria) |
Intra-EEA contactless transaction below EUR 25 | 1.15% |
Intra-European full 3DS transaction | 1.95% (minus 0.3% if acquirer meets some criteria) |
Intra-European ATM Service Fee | 1.3 EUR + 0.2% |
Inter-regional transaction POS and full 3DS | 2.0% |
BIN Range or Separate BIN in Card Issuing
Our customers usually ask if it makes sense to issue cards on a separate BIN fully dedicated for a particular project or just use BIN range and share it with other partners. Let me focus on this topic in this short article.
BIN range
There are not so many disadvantages of dedicating a BIN range for your project. In many cases this decision will be much better. Key reasons:
- The project is cheaper as we do not need to implement a new BIN with Mastercard or VISA for you. It is a saving of around 20.000 EUR and monthly maintenance costs are cheaper as well (500-1000 EUR monthly).
- The project is faster for the same reason. It is a saving of around 3-4 months.
- The setup of the BIN range is easier from an operational perspective, so you and we do not consume more mandays for the project.
The only slight disadvantage in such an approach is that there may be a situation when this BIN gets compromised because of some user behavior. It is a very rare situation but it could happen. If you share the BIN with other customers, there is a risk that you will have to change the BIN and cards for customers because of the actions of other customers. We believe that this risk is very small - it has never happened in our history.
Separate BIN
Some people believe that if they have "own" or "dedicated" BIN, the project will be much better. In reality it is not so. It is only more expensive and slower (see above). There is more work and some additional risks connected with the new BIN setup. However, the advantage of a separate BIN is the same as mentioned above - you do not share the BIN with other partners, so in case of BIN compromise, you will know that it happens because of your actions.
I do not see any additional big differences, disadvantages or benefits of using a separate BIN.
Thanks for reading.
Guide to IBAN setup process
In this article we would like to focus on IBAN, bank accounts delivery to your customers. This topic is raising a lot of questions and requires attention.
Let's assume that you would like to offer IBANs for your customers. If you are a fintech provider, money transfer organization, lending company, eCom marketplace, it could make a lot of sense as a value added product. In such a case Verestro, together with partnering payment institutions and banks can provide you IBANs via API or inside our SDKs or white label products and your customers will be able to transfer money to and from those bank accounts in the same way they do it in normal mobile or internet banking.
But what happens in the background? How does it work?
There are a few dimensions that we need to remember about once enabling the IBAN product - technology, money movement, money holding, liquidity management etc.
Technology
From a technology perspective it is not very difficult. You just go to section IBAN management in our Developer Zone and can find APIs. Please remember that you must create a user first in our database, perform KYC in majority of cases, create a balance or account for this user and once it is done you will use this IBAN API to create an account number (IBAN) for this payment account.
In the background, during project setup and operations, Verestro and our partnering payment institutions create for you a set of IBANs from one or more banks that will be used in case you request IBANs or transfers via API. Once transactions come to this IBAN, technically you are receiving information from our system that the balance of the account changed and you can display this information to the user.
Money Movement
By Money Movement we mean a process of transferring real money from sender to receiver. Because we are using various payment institutions and banks behind our system, it is worth discussing. There are the following steps in this transaction:
- Sender sends money to IBAN of your user generated at Verestro platform
- Our partnering payment institution or bank receives information about incoming transfer to this IBAN
- Verestro platform informs you about the incoming transfer and optionally initiates movement of money to another bank which acts as settlement bank for your transactions. This happens in case IBAN is generated in another payment institution than Settlement Bank
- Money gets available on user or your account or for settlements of card transactions at the moment it arrives at Settlement Bank (usually you do not experience any problems as it is at D+1 time)
Money Holding
In all cases money is held by banks cooperating with Verestro so they are secure in the same way as any other banking account in those banks. We cooperate only with strong and reliable banks in various countries (usually based in Poland).
Liquidity Management
In some cases once you are receiving and sending money from and to IBANs, in order to avoid delays of money transfers between various payment institutions and banks, it is necessary to place and manage additional liquidity benefits so that your users could send money faster. We will inform you about such situations during the project depending on the requirements and use case we are going to implement together.
Thank you for reading.
IBANs, cards, balances - how to manage all of this?
Once you are starting a payment account and/or card issuing project you need to learn key definitions and relations between those various parameters.
Balance ID - this is a real "account" in the Verestro system. This number is connected with User ID and means that the user has an account and balance in our system. The user can keep money on this Balance ID. Of course, one user can have multiple balances but a single balance can belong to one user only
IBAN - this number is often mixed with Balance ID. IBAN is a number through which the user can receive money to his balance via wire transfer. IBAN is not a balance ID. Generally it does not make sense to have more than one IBAN for one balance. Normally you issue one IBAN for one balance. Usually a user can have more IBANs and balances if he wants to keep money on separate accounts, in various currencies etc.
Card number - easier to understand, just a card number issued to a particular balance ID (not to IBAN!). A user can have multiple cards connected to one balance ID.
Once preparing to project with Verestro, please learn the above definitions. More info here: https://developer.verestro.com/shelves/card-issuing-ibans
Issuing cards in various currencies
Verestro and its partners can issue cards in multiply currencies. Depending on the currency it is easier or more difficult but it is possible to issue cards in multiply currencies. Let me explain how to do it in this article.
Firstly, let's discuss that to issuing cards in particular currency (let's say CZK) means that user has an account in CZK and when he is paying 100 CZK his account gets debited with 100 CZK. To achieve this situation normally the card issuer needs to implement Settlement Service with Mastercard or VISA in CZK. This means that card issuer will have to send 100 CZK to Mastercard after the transaction so that Mastercard could transfer it to acquiring institution and later to merchant. Once this Settlement Service is enabled everything works well but the problem exists if issuer does not have Settlement Service in particular currency or sometimes such Settlement Service does not even exist and issuer must settle money in USD or EUR. Sometimes it is not worth spending money and time on new Settlement Service implementation as it can cost 25-40k euros.
In such situation we can implement Internal Settlement with partner in particular currency. It means that users will keep money in CZK, users will be charged 100 CZK if they pay 100 CZK but all money transfers between Verestro payment institutions and our partners will be happening in EUR. There will be some FX risks connected with this approach but they can be covered through a bit higher fees for users.
There is only one exception to this rule - it is necessary that we can hold money in this new currency in the banks where we hold accounts. It is necessary that accounts are stored in this particular currency to avoid difficult fluctuations.
Ask us for Internal Settlement if you are interested in card issuing in multiply currencies.
Payouts to Cards & Money Transfers
Here you can find information about money transfers to Mastercard and VISA cards.
Payout to Cards
How does Payout to Cards work? Payout to Cards is a relatively new area of payment business that is not very common, so this article brings more information about it.
What is Payout to Cards? Actually, the answer is simple. It is nothing more than a normal bank transfer, but made to a card number instead of a bank account number.
Transfers to bank accounts are pretty common and I guess we understand how they work. A bank or another financial institution connects to Automated Clearing House (usually National Clearing Center or National Bank or inter-bank organization), implements the solution on both frontend (internet banking, mobile banking, internal systems) and backend (integration with core-banking system and ACH), and once Customer wants to send money and enters IBAN (bank account) of the receiver, the transfer is performed. In such a case the bank sends technical information to ACH and sends money or performs settlement either with another bank or National Bank, or any other payment organization responsible for this transfer.
Payouts to cards work completely in the same way, but the money transfer is done to Mastercard or VISA cards. At Mastercard, this solution is called "MoneySend" (sometimes Mastercard Send or Cross-Border Send), while at VISA it is called "VISA Direct". In case of such a transaction Customer of the bank or any other money transfer organization initiates payment via the Internet or mobile application and sends money to the Primary Account Number (card number) of the receiver. The settlement of money happens via the Mastercard and VISA networks - actually through settlement bank accounts registered at Mastercard and VISA to perform a card transaction. Money is taken from the settlement account of Originating Institution (sending institution) to the settlement account of Receiving Institution.
We present this on the chart below.
In fact, there are not many differences between a standard bank transfer and Payout to Cards. Real differences are a natural result of using payment cards to process transactions. The main differences are:
- Pricing - obviously pricing of such a Payout to Cards is different than a standard banking transfer - usually more expensive. This is the outcome of the pricing policy of VISA and Mastercard. Nothing else. On average, Payout to Card costs around 0,5-1% + 0,1-0,8 EUR per transaction.
- Speed of the transfer delivery - Receiver of a Payout to Cards transaction usually receives money (globally) within 30 minutes. It is a big game changer compared to SWIFT or SEPA transfers. It really works globally. Imagine that you can send money from Brazil to Germany in 30 minutes! From Singapore to Pakistan in 30 minutes!
- Using a card number - Receiver needs to share his/her card number (only 16 digits) with Sender. This is a significant problem because we do not like sharing card numbers with other people. Actually we are taught that it is risky. This can impact a user conversion in many use cases.
- Issues with a receiving network - Sometimes it is difficult or impossible to send transactions to particular countries. For example Germany or the USA are countries where such transactions are blocked - banks usually do not accept receiving Payouts to Cards. This may be a problem for some use cases and some transaction corridors.
- Maximum transaction value - VISA and Mastercard decided that there are some maximum transaction values. Usually it is around 5-10k EUR or USD per transaction. There are also some monthly limits per user. It does affect the user experience but this value is growing over time.
In general, it is a great functionality that works well for banks around the world as competitive to SWIFT and ACH. It gives added value to the user who wants to transfer money quickly, especially internationally. Worth considering for all money transfer organizations and banks. The implementation of Payout to Cards can be greatly simplified by Verestro and our partner payment organization Fenige. Please check us out!
Currency Management in Payouts to Cards
There are many questions about how to manage currencies in payout products. Let me briefly describe several possible scenarios.
Let's start with dependencies that have an impact on choosing various scenarios.
- Sender's card account currency - first you have a user with a payment account in a particular currency, for example USD, EUR, CHF, RON etc.
- Transaction currency - transaction that sending user can choose
- Acquirer settlement currency - there are settlement currencies that an acquiring institution (Originating Institution) cooperating with VISA or Mastercard uses to settle money with them, for example USD, EUR, PLN. Of course, it can differ from the user account currency.
- Receiver's card issuer settlement currency - a bank, which issues a card for the receiver, can have various settlement currencies with Mastercard or VISA.
- Receiving card settlement currency - additionally, there is a settlement currency of the receiver's card, issued by another bank. It can be any currency, for example UAH, CZK.
That's why it is complex. At various levels of transactions there are various currencies and of course in case of currency conversion at any step various additional FX fees apply. That's why the choice of currency management strategy is not an easy one.
Additional decision factors are related to particular use cases I want to present. There are a few possible ways of offering Payouts to the user. Let's have a look at 3 scenarios:
- User chooses how much money in their currency they want to transfer - example: User has an account in USD and wants to send 100 USD to a friend. User does not know if the friend has an account in USD, EUR or PLN. He/she does not care.
- A. In such a case there is no problem if Sender and Receiver, Acquirer and Issuer have an account in the same currency as available settlement accounts of Acquirer. Transactions will be processed and settled in the same currency through the chain. This almost always applies for USD, EUR transactions.
- B. If Sender has an account in USD, Acquirer has a settlement currency in USD, Issuer has a settlement currency in EUR, Receiver has a card account in EUR, there will be currency conversion that will happen on Receiver's side. His/her bank (card issuer) will convert the incoming USD to EUR and charge currency conversion fees.
- C. If Sender has an account in CZK, but Acquirer does not have a settlement currency in CZK, but only USD and Receiver has an account in USD, there will be conversion happening on Sender's (acquirer) side. The sending institution will convert 1000 CZK of User to USD, will charge currency conversion fees and Receiver will receive USD after conversion. Receiver's bank will not get any currency conversion fees.
- User chooses currency of Receiver - Example: User has an account in USD but needs to pay 100 EUR to Receiver because he/she knows that Receiver wants to get 100 EUR.
- D. It is possible to recognise the settlement currency of Receiver thanks to BIN tables shared through payment schemes. Thanks to it Sender will know that Receiver's card is issued in USD, so only USD will be allowed for this transaction. In such a case currency conversion will always happen on Sender's side. In case User has an account with EUR, their Acquirer (Originating Institution) will convert 100 EUR to USD and will initiate a transaction in USD. In case User account is in a different currency than the settlement account of Acquirer, additional currency conversion fees will apply and will be charged by Acquirer.
- User does not have a choice - in such a case we offer only a payment in currency defined by the payment provider, for example always the same currency as the User account.
- E. In such a case User can send only one currency. Usually the same as his/her account currency. If User's account currency is the same as the settlement account of Acquirer, the transaction will be processed as in point 1B, which means that currency conversion can happen on Receiver's side if Receiver's card currency is different from the settlement currency.
- F. In case User can send money in the currency which is not the settlement account of Acquirer in, some additional conversion fees will apply on Acquirer's side (like in scenario 1C).
It may look complicated, but if you look at it from the point of view of currency conversion points (5 places where conversion can happen) it is easier to understand.
Our recommendation is to use Scenario 1 and focus on implementing Scenario 1A (we can enable currencies which will be the most popular for your payment corridors). In some cases our partners use Scenario 2. It is important that calculation of commissions and spread is always dynamic, so Sender knows in advance the cost of these transactions.
I hope this article can help you understand currency conversion details. Thank you for reading.
KYC requirements in Payout and Money Transfer projects
Know Your Customer (KYC) processes usually generate many questions. Key requirements and decision points are summarized in this article.
The KYC regulations are directly related to AML (Anti-Money Laundering), regulatory and payment scheme requirements. In general, any payment or banking institution has to know who their customers are, what the source of their customers' money is and how the customers use the money held by the payment institution. To limit the risk of supporting terrorist or illegal activities, regulators require payment institutions to be aware of and monitor them.
The key question in every project is: "Who is the owner of the money on the account?" There may be the following situations:
- CONSUMERS - If consumers own the money on account, the KYC process has to happen. It usually means that the user (consumer - not a company) needs to provide his/her ID document or passport and selfie, a meeting or video call needs to happen to make sure that the consumer is a real person who signs a contract with the payment institution. There are many additional verification ways that the payment institution may require, but these are the main ones.
- BUSINESSES - If a company owns the money, the KYB (Know Your Business) process has to happen. It usually means that the user (company owner, manager etc.) needs to provide not only his/her ID document and make a selfie or a video call, but the payment institution needs to check beneficiaries (owners of more than 25% of shares in the company).
In both cases, the payment institution is obliged to check whether the consumer, company director or company owner is on various sanctions lists, e.g. OFAC or UN sanctions lists.
The above rules are critical and in fact all other implications are results of them. In projects related to the implementation of Payout to Cards, the first question we need to answer is: "Who is the owner of the money on the account?" If the consumer is the owner of the account (scenario 1) - the consumer must go through the KYC process. If the business is an owner of the money on the account (scenario 2), the KYB process will have to happen and there will be no additional KYC.
In the majority of Payout to Cards projects we are in Scenario 2. It means that the KYB process needs to happen and there will be no additional verification of consumers. The reason for that is that we usually talk with payment institutions, wallets, fintechs that have registered users, the users have their accounts (already after KYC) and our money transfer institution will work directly with this business customer to enable Payouts from accounts of this payment institution to the receiver. The account owner will be a payment institution or a business that we work with. From a legal point of view, our customer (B2B customer) will take money from the user's account, place it on their own account and initiate a payment to the receiver from their own account. In such a situation we will do KYB, we will verify if our partner has a legal right to perform such activities and it will be enough. We will request our partners to send us some customer (Sender) data including the first name, last name, but nothing else.
In some situations there will be a need to initiate direct payments from the consumer account to the receiver - Scenario 1. In this scenario we will require that either the partner does a professional KYC process according to requirements (see above) and sends results of KYC to us, including a selfie, ID documents etc. Or in specific cases we can perform KYC on behalf of the partner.
I hope I clarified the topic. Please make sure that you define quickly if you are in scenario 1 (consumer KYC) or scenario 2 (business KYB) and you can quickly enable Payouts with us.
Thanks for reading.
Various forms of money transfers
There are multiple forms of money transfers. In this article we would like to summarize the most important pros and cons of every solution:
- SWIFT (Society for Worldwide Interbank Financial Telecommunication) - inter-banking payment scheme enabling global transfer, International standard
- Pros - almost any currency; global network, unlimited amount of transfer
- Cons - time of transaction (sometimes a week); cost of transaction (example: 0,3%+10 usd or more); available to banks only
- Payouts to Cards - using Mastercard and VISA network, global transfers, international standard
- Pros - almost any currency; global network; speed (even 30 minutes to transfer money between continents
- Cons - Cost of transaction (example: 1% + 0,5 usd), limited amount of transfer (10.000 USD)
- Crypto - using cryptography to transfer value, global transfer, international standard but sometimes forbidden by law
- Pros - multiple but virtual currencies; global network; speed (even 5 minutes)
- Cons - high costs (example: 1-2%), very often forbidden by regulators, risk of losing money, needs crypto exchange involvement
- SEPA (Single Euro Payment Area) - European standard or euro currency standard
- Pros - speed (immediately or 1 day), price (below 1 EUR)
- Cons - works only from EUR to EUR, works only in the European Union
- Payouts to wallets - various providers offer various payouts mechanisms to multiply local wallet providers or cash-out networks
- Pros - localization
- Cons - no global standard in speed and price, usually more expensive
- Virtual cards - you can issue a virtual card, send card data to the receiver and the receiver can use the card globally
- Pros - global standard, very quick and very cheap, receiver can use card for ATM withdrawal, POS and eCommerce payments
- Cons - non-standard way of sending money, receiver reluctance
- Local ACH (Automated Clearing House or local scheme) - there are multiple local or national payment schemes globally that you can use once you integrate with them. Usually requires a bank license to integrate.
- Pros - quick and cheap, standard in the country
- Cons - no global standard, works only locally
If you are asking yourself which solution you should use for your user it is actually a wrong question. We recommend using all. Give choice to your users, apply various fees on various methods of transfer, let users choose the best way of payments for them. It is actually very important strategy because:
- for users in Poland SEPA transfer or local ACH are the most common ways of payments nowadays
- for users in Ukraine Payouts to cards are the most common mechanism they have been using for years
- for users in USA SWIFT or local payment schemes are the most common mechanism
If you are building an international service, you really need multiple ways of sending money for your users.
Thanks for reading.
Payouts, eCom Transactions or Card-to-Card Payments?
While thinking about card-based money transfer solutions, our partners usually ask for three products - payouts to cards, eCom transactions or card-to-card payments. In this article we will describe differences between those 3 ways of money transfers.
Let me start with a chart.
There are three use cases that you may be interested in. The choice of product depends on a use case decision.
Use Case 1. Top-up user account - in this case our starting point is the user's account kept somewhere in your systems. Your users need to reload this account with money. You can use various forms of transfers to your account, but if you want to reload an account from Mastercard or VISA card, we should enable eCom transactions to you. You will be registered as a merchant with our partnering acquirers and we will enable payments using cards, Apple Pay, Google Pay or other means of payment.
Use Case 2. Payout to card - in this case we assume that your user has an account and money on this account. We need to enable payments from this account to any card in the world. This money transfer will be very quick - less than 30 minutes. In this case you should be using our product called "Payouts to cards". This will enable your user to transfer money to any Mastercard or VISA card.
Use Case 3. Card-2-Card - in this case our assumption is that you do not have a user's account. You do not store the money of your users. You just want to enable a money transfer service from one card to another card. From Mastercard to VISA, VISA to Mastercard or Mastercard to Mastercard or VISA to VISA card. In such a case we recommend that you use our card-2-card product.
It is important not to mix those use cases and choose the correct product. All three products have different fees, AML requirements so please think of your use case and let's decide what to use.
Thanks for reading.
Tokenization & Contactless
More knowledge on ApplePay, GooglePay, HCE and other ways of NFC and eCommerce payment using tokenization (MDES and VTS)
Issuer Wallet and Apple Pay / Google Pay - Differences
As we have implemented more than 50 contactless and tokenization projects for banks, fintechs and other payment institutions, let me share a quick view on key differences between various types of contactless payment technologies.
X-Pays
If you are a card issuer in today's world, you usually need to implement Apple Pay and Google Pay to let your users benefit from various payment activities on mobile phones. We think it is obligatory in today's world for standard card use cases. The power of Apple and Google is so strong that avoiding these platforms really impacts your customers.
In general, implementation of these technologies is not difficult. If you use our Token Management Platform, implementation time can be reduced to weeks. Additionally, you have to sign contracts with Apple and Google. In the case of Apple, they charge additional fees for registering a card at Apple Pay. In the case of Google, they collect all transactions of your users to earn money on advertisement and data management. These are key disadvantages. In both cases you have to follow their requirements and changes, but if you cooperate with certified providers, you do not have problems with this, as a processor can solve these problems on your behalf.
Both Google and Apple solutions enable contactless, inApp and eCommerce payments on their browsers. The non-contactless payment transactions are an important part of these projects. You should focus not only on contactless payments.
It is worth mentioning that implementation of tokenization usually gives you access to other X-Pays like Fitbit Pay, Garmin Pay or others. They are much smaller companies and we treat them as nice-to-have in card issuing projects today.
Issuer Wallet SDK
Before Apple Pay and Google Pay appeared, both Mastercard and VISA invented other ways of contactless payments on mobile phones. They were called differently, but today they are mainly called Issuer Wallets. In such cases you do not sign contracts with Apple or Google, but you implement technology (both mobile SDKs and backend) that allows you to go live with contactless payments on mobile without signing contracts with Apple or Google. Actually it was possible for Android only, but recently (2023/2024) Apple allowed non-Apple Pay contactless payments on iPhones in the European Union.
In such cases you need to get and certify SDKs and backend components to go live with contactless payments. Such developments usually take 12-24 months and the software must be kept updated all the time, so it is actually better that you try to use a certified partner for this activity to avoid on-going development costs just for your project. From a contactless use case perspective, transactions work in a very similar way to X-Pays, but you have more flexibility. On Android, for example, you can implement a contactless payment just after unlocking the phone screen. You can - but do not have to - ask for additional authentication. You are also sure that data of your users and their transactions will not be shared with external entities (Apple and Google) for their benefit.
A big advantage of the Issuer Wallet SDK is that it can work not only on Android phones - for example, we have live implementations on Huawei devices. This detail has an important business impact on your users.
In today's world, working with Apple or Google is obligatory in our opinion, but we strongly recommend implementing Issuer Wallets at the same time, as it will give you more flexibility and business security in the long run. The costs and processes do not differ a lot, but the additional benefits of an issuer wallet such as flexibility, more devices, lower transaction costs make it worth implementing.
Read more: Push Provisioning to Google Pay and Apple Pay
Thanks for reading.
NFC on iPhone/iOS
What happened?
As part of an agreement between the European Union and Apple, Apple has decided to open access to its NFC module to 3rd party developers. It allows the creation of solutions for contactless payments (HCE), an alternative to Apple Pay.
This article aims to explain the challenges and opportunities related to this technology.
How it works?
- NFC payments. Users of participating third-party banking or wallet apps can initiate NFC transactions from within the app with compatible NFC terminals.
- Default app settings. Users can choose any eligible app as their default contactless payments app which will enable the app to support Field detect and Double-click features.
- Field detect. The default contactless payments app automatically launches when the user places the device in the presence of a compatible NFC terminal and after user authentication (if the iPhone is locked).
- Double-click. The default contactless payments app automatically launches when the user double-clicks the side button (for Face ID devices) or the Home button (for Touch ID) and after user authentication (if the iPhone is locked).
- Payment support for non-default apps. Eligible apps running in the foreground can prevent the system default contactless app from launching and interfering with the payment.
What are the differences compared to Android?
Since 2013 Android allows implementing alternatives to Google's own Google Pay, and there are already a few mature solutions on the market. Apple's NFC API offers very similar capabilities from both a technical and user experience perspective. However, there are a few differences:
- Not possible to directly ask a user to set your application as the default NFC payment app - on Android, when users open your app, they can be presented with a dialog window that asks them if they want to use your app, as the default NFC payment app. Apple's documentation doesn't seem to hint at such a functionality.
- Apple needs to give you special entitlement to access the NFC module - without Apple's approval, it's not possible to include NFC payments into your app. This entitlement can be requested here: https://developer.apple.com/contact/request/hce-payments-entitlement/
- Security certification - every app enabling NFC payments needs the EMVCo certification. As NFC on the Apple platform is a new thing, it's still not clear how exactly security certification will look like, however due to fundamental differences between Android and iOS we can expect slight differences.
What are the differences compared to Apple Pay?
Apple's API allows 3dr party developers to implement most of the functionality offered by Apple Pay. Two slight differences are:
- Power Reserve Mode - Apple Pay allows payments with the default card for some time after the iPhone battery is depleted.
- Express Transit Mode - allows to pay for public transport tickets in a few areas with compatible cards, without unlocking the iPhone. Full list of locations is available here.
Will it work outside the EU?
Companies registered in the European Economic Area can offer this functionality to customers based in EEA. The table below shows various combinations of companies wanting to offer HCE payments in their App and customers, and the expected outcome according to Apple's requirements.
Company developing App established & licensed for payments in EEA |
Company developing App not present in EEA or not licensed for payments in EEA |
|
EEA citizen, transacting in EEA country |
✅HCE available |
❌HCE not Available |
EEA citizen, transacting outside EEA (traveling) |
✅HCE available | ❌HCE not Available |
non-EEA citizen, transacting in EEA country (traveling) |
❌HCE not Available | ❌HCE not Available |
non-EEA citizen, transacting outside EEA country | ❌HCE not Available | ❌HCE not Available |
Pay by Account - NFC from bank account
As we have done several Pay by Account projects, I would like to share some information on what is the best way to implement such a solution.
Pay by Account or - in other words - mobile NFC payments directly from a bank account is an important product development step for many local schemes. Usually it is not enough to enable money transfers, QR payments or bill payments, and it would be beneficial to make use of the global authorisation and clearing network of Mastercard and VISA. In such a case, users of local schemes like BLIK in Poland or PIX in Brazil could be using or are using mobile phones to pay globally.
The solution is not difficult to implement using virtual cards and some local settlement ideas. There are the following architectural components:
The key implementation steps are as follows:
- Every user interested in using contactless, eCommerce, or inApp payments will get a hidden virtual payment token
- The token will be tokenised at a mobile phone of the user (usually Issuer Wallet SDK) and will be used for payments on the standard Mastercard or VISA acceptance network
- In case the token is used to do domestic transactions at acquirers and terminals integrated with a local scheme, the authorisation and clearing will be routed to a local scheme
- In case the token is used for international transactions, globally, at any terminal in the world, the authorisation and clearing will happen via the standard Mastercard or VISA settlement network
To enable this project you need to have a virtual card issuer or card issuing processor with super low fees per card - test us :) You will also need some support from Mastercard or VISA to agree on such a processing mechanism. Additionally, certified SDKs and backend components for contactless payments will be necessary (we can provide as well).
There have already been several implementations of similar schemes in the world. We are happy to discuss this setup in more detail.
Thanks for reading.
On-device tokenization in India
Payment law in India required a few years ago that server based card-on-file systems are not allowed. Instead, there is a necessity to store user data on-device to perform transactions.
This is an interesting topic that impacted a lot of local players like big merchants, Cred, Phonepe or Amazon so let me describe it in some details because maybe it will be implemented in a few years in other countries as well.
Requirement for storing tokens in a secure way on customer devices forces us to implement and certify secure SDK in which payment token data will be saved. It is a similar concept to standard HCE (Host Card Emulation) implementation for mobile NFC payments. While registering to a merchant or wallet system, the user adds a payment card, performs tokenization with approval (One-Time-Passwords) of the issuing bank and the token connected with his card is stored in this wallet / SDK.
Once we have a secure place of storing the user's token on his mobile phone we can use this token for multiple purposes:
- NFC / contactless payments - the user uses his phone to perform transactions on a contactless acceptance network. Token and payment keys are transferred through the contactless interface to the payment terminal and acquirer for authorization.
- inApp - the user chooses products and adds them to the basket in the merchant app, clicks that he wants to pay with a particular wallet or payment brand and confirms the transaction in a wallet app. The token is taken from an SDK, transferred to the cooperating acquirer in the form of a DSRP message (Dynamic Secured Remote Payment) and processed in standard way
- web purchase - the user chooses products and adds them to the basket on the merchant website, clicks that he/she wants to pay with a particular wallet or payment brand and receives a push notification in his/her mobile app to finalize the transaction. As above, the token is taken from an SDK, transferred to the cooperating acquirer in the form of a DSRP message (Dynamic Secured Remote Payment) and processed in standard way. There could be a possibility to store the token inside the browser of the user on his laptop / PC but this requires more discussion with Mastercard and VISA.
To enable these use cases, several implementation points needs to be considered:
- types of devices - an inApp and web purchase can work on all devices (iOS and Android) but NFC is enabled on Android only. Apple is blocking the NFC access outside of the European Union today.
- VISA vs Mastercard - do you need a solution working for both schemes? Are there any local certification requirements?
- Issuers - are banks ready to connect to your new X-Pay wallet? Which banks are enabled on local markets?
- local on-soil requirements - is there a need to store data in the country? What are the legal impacts?
This is an interesting development and area of work. We are live with a few partners and are happy to work with new ones. Please contact us if you are interested.
Thanks for reading.
Push Provisioning Step by Step
Android - Push Provisioning to Google Pay
1. Request Access
Before enabling Push Provisioning in the Android application, you'll need to be whitelisted by Google. To initiate this process:
-
Visit the Google Pay Push Provisioning launch page: https://developers.google.com/pay/issuers/apis/push-provisioning/android/launch-process
-
Click "Request access" and complete the provided form.
2. Provide Application Details (Upon Approval)
Once your access request is approved, Google will contact you to gather additional information about your application:
-
Screenshots: Submit screenshots that showcase the placement and functionality of the "Google Pay" button within your app.
-
User Flow Recording: Provide a screen recording demonstrating the user experience for adding a card to Google Pay.
Important Note: Google Pay integration does not require any additional paid certifications.
3. SDK Configuration
-
Verestro Application Ownership: If Verestro develops the application, our development team will handle the internal configuration of the Push Provisioning SDK.
-
Customer Application Ownership: If the customer owns the application, Verestro will provide the SDK and necessary configuration instructions.
iOS - Push Provisioning to Apple Pay
1. Contact Apple
To begin enabling Push Provisioning for Apple Pay, initiate contact with Apple directly. Use the following email addresses:
-
apple-pay-provisioning@apple.com
2. Application Information and Testing
Provide Apple with the details of your App Store application. Verestro will conduct integration testing using the same application (including the same ADAM ID) within the TestFlight platform.
3. FIME Certification (Optional)
While not mandatory, FIME can provide an optional certification process for Apple Pay Push Provisioning. Contact FIME directly for current pricing and instructions. This cost was approximately €3125 at the time of writing.
4. SDK Configuration
-
Verestro Application Ownership: If Verestro develops the application, our development team will handle the internal configuration of the Push Provisioning SDK.
-
Customer Application Ownership: If the customer owns the application, Verestro will provide the SDK and necessary configuration instructions.
Additional Notes
These instructions provide a high-level overview.
For detailed technical guidance and code implementation, please refer to the official Google Pay and Apple Pay developer documentation.
It will be necessary to implement the SDK and APIs provided by Verestro and used to encrypt card data and support additional processes in xPay's.
Push Provisioning & Web Push Provisioning
In this article we will focus on the process of pushing card data to X-Pays (like Apple Pay or Google Pay) – a process called Push Provisioning.
In many innovative card issuing use cases it is important to launch tokenization of cards to enable better customer experience and contactless payments with mobile. There are actually a few ways of registering card data at Apple or Google Pay from a user's perspective:
1. Manual provisioning – which means that the user provides card data one by one. After that the user accepts T&C, confirms this action with One Time Password received from the issuer / bank and gets the card tokenized.
2. Scanning card – the above mentioned process can be improved if the user can scan their payment card with their phone, so that the card data and expiry date appear automatically in the wallet. Not a difficult thing to do nowadays. This process is also very useful if a card visual can appear on the website and the user scans the card visual and data directly from their laptop.
3. Push Provisioning – in this case, the process starts with opening a mobile banking application. The user can click the “Add to wallet” or “Register to wallet” button and can be redirected to Apple or Google Pay to finalize registrations. Various SDKs enable quick registration of the user and card data. It is a very user-friendly process.
However, in some cases it is necessary that the process of Push Provisioning starts from the website – not from the mobile app. This is called Web Push Provisioning and it is a very innovative way of starting tokenization. There are available APIs that streamline such a process and it can be used in many cases. However, to make it happen special approvals of Google or Apple are needed, which is not easy to receive.
This use case can be interesting in multiple projects, for example:
- Gift cards delivery – the user opens a gift card on the website widget on their phone and can immediately add this gift card to the wallet.
- Expense management cards – the user opens a card generated by their employer on their phone and can immediately tokenize the card in ApplePay.
- Emergency cards – the user gets a card from their insurance or bank and can use it immediately on their phone for emergency transactions.
Please contact us if you are interested in testing those use cases.
eCommerce Payment Gateway
More information about eCommerce payments, transaction processing, 3DS etc.
Multi-acquiring in eCommerce Payments
Acceptance of eCommerce payments
When you are thinking of starting acceptance of eCommerce payments via cards or other payment methods, you should definitely consider a long term strategy and a multi-acquiring scenario.
The starting point for any merchant, marketplace or other digital platform is the way you are going to charge users on the Internet. Normally, you are thinking of choosing an acquirer like Stripe, Adyen or local providers from your country. Let’s think of strategic implications.
Strategic implications
Assuming you have one acquiring partner at a time and you customize your platform to their requirement you are actually building a very strong dependency on this partner. Very often you will ask this acquirer to provide Card-on-File functionalities, cards of your users will be stored by this acquiring partner. Sometimes the acquirer will have features that support easier transaction conversion but they will be hosted on the partner side to avoid PCI DSS requirements and costs. By implementing such functionalities that will be good for your users and UX, you are actually becoming more and more dependent on your acquiring partner. It means that your negotiating power is going down and the cost of transaction processing will grow.
The bigger your business is, the bigger the problem is. What is the solution to such a situation?
Multi-acquiring
It is called multi-acquiring. You should choose a technology platform, compliant with PCI DSS requirements that can integrate with multiple acquirers globally so that you are not dependent on a single acquirer but have a technical platform which enables switching transactions from one acquirer to another one.
Such a platform should enable tokenization of cards and transactions, should take all PCI DSS problems from your shoulders, and should be integrated with multiple acquirers from the moment of start. Thanks to it, you can switch VISA transactions through one acquirer, Mastercard through another one. You can use one acquirer on Mondays and another one on Fridays. You can switch transactions done in Europe with one acquirer and performed by users from America with another acquirer.
It gives you flexibility. It improves conversion rates. It gives you the opportunity to negotiate transaction fees regularly. It does not increase costs on your side as you have multiple partners integrated to the platform which means that you do not need to cover all costs of integration yourself.
Multi-acquiring is a very powerful tool for developing your eCommerce business.
Thanks for reading.
How to increase approval rates in eCommerce?
Many merchants, especially in high risk area, face the problem of low approval rates. There are situations where 20-40% of transactions are declined. This is a real issue as it means a concrete loss of sales opportunity. In this article we will explain how it is possible to increase approval rates by using a multi-acquiring approach.
A standard eCommerce merchant signs a contract with one acquirer and enables users to use various ways of payment with this acquirer or payment gateway. This leads to the situation that the merchant is dependent on this acquirer and the choice of choosing payment methods is usually on the customer's side. It also means that there is no way to use active management of a payment method depending on transaction and user behavior.
Main reasons of declines are the following:
- 05 - Generic decline (do not honor, transaction not allowed ...) - around 30-40% of cases. It is possible to optimize acceptance by using another acquirer, changing payment methods etc.
- 51 - Insufficient funds - around 20-30% of declines. In such case the only way to improve approval rate is offering loan to customer, kind of Buy Now Pay Later solution
- 14, N7 - Incorrect number/account, wrong CVC - 10% of declines - requires good UX for data improvement
- 41 - Lost/Stolen card - 10% of declines
- 54 - Expired card - possibility to use automatic upgrade of card data in database
- and a few other reasons
Improvements in approval rates will appear once you start managing this situation by storing user and payment data, learning user and transactional behavior, and proposing to users such methods which are best suited for him. It requires that you build or use a card-on-file system or even "payment-on-file system" that is independent from your main acquirer and you start actively proposing and testing payment methods to your customers.
When you learn that a particular payment method does not work, your gateway should propose an additional method of payment, especially using tokens and local payment methods which can improve approval rates a lot.
Once you (or your partner like Verestro) store payment methods, you can automatically update the user payment method data to avoid reasons of an incorrect number, wrong CVC, expired card. By using tokenization and wallet solutions you can also improve approval rates substantially.
Contact us if you want to go into details of this process.
Tokenization in eCommerce Payments
Sometimes our customers ask questions connected with tokenization of eCommerce transactions. Let me focus on this topic below.
There are multiple meanings of tokenization in case of eCommerce payments.
Payment Scheme Tokenization
I think that nowadays term tokenization is the most commonly used in the context of VISA or Mastercard card tokenization. Both payment schemes implemented tokenization systems (MDES and VTS) which were first used on mobile phones but today are also used for eCommerce transactions. In such situations, tokenization means that a regular Mastercard or VISA payment card gets connected to a token which is a kind of virtual card number and once this mapping happens, the user is using the token to initiate payment transactions from those cards. An example of such a use case could be Netflix which enables their users to add cards to the service and in many geographies they map cards with tokens and for all transactions a token is used rather than a regular card. In case of a security breach, a thief will steal token numbers and not card numbers.
Card on File Tokenization
Very often term tokenization is used in the context of regular Card on File projects. Card on File is a solution that enables merchants or acquirers to enable card payments without asking all the time for card number entry by the user. A card is held "on file" which means that it is saved in the system of merchant, acquirer, processor and can be used any time the user confirms a transaction. In such a context, tokenization can be enabled without VISA or Mastercard and tokens are owned by the processor or acquirer and shared with the merchant. In case of security breach to the merchant, real card numbers are not exposed because they are safely kept by a PCI DSS compliant processor.
Apple or Google Pay Tokenization
Sometimes tokenization in eCommerce is used in the context of Apple Pay and Google Pay transactions. In those projects the system works very similarly to the standard Payment Scheme Tokenization described above, but iOS and Android devices are used to authenticate the user and the transaction. Apple and Google enable various endpoints that merchants or acquirers can connect to and allow tokenization. Transactions are processed in a similar way to regular Mastercard or VISA transactions.
Advantages of Using Tokenization
Usually, main advantages or using tokenization are connected with security and minimising PCI DSS requirements that merchant must fulfill. PCI DSS (Payment Card Industry Data Security Standards) require that each entity, which holds and processes card data, performs a set of actions to make sure that cards are securely processed. Very often tokenization brings additional benefits like cost optimisation and user experience improvements.
However, once you think about such a project, take seriously all potential long term impacts. If you do a project directly with your acquiring institution you may get seriously impacted in case you want to change provider. The last thing you want as an eCommerce merchant is to have a monopoly of your payment provider. You should choose providers that work with multiple acquirers, can provide tokenization or card on file solutions for users cards and tokens without being limited to a single acquirer. In such cases you can get acquiring offers from multiple acquiring partners and enable competition to lower prices of payment processing.
Please contact us if you consider such projects.
Payment service providers as an eCommerce payment aggregators
In the digital age, where online shopping has become everyday life for millions of consumers around the world, eCommerce payments play a key role in shaping the shopping experience. Convenience and security are factors that influence purchasing decisions, and technological innovations make the payment process more and more complex and diverse.
ECommerce payment - what is it?
ECommerce payments are financial transactions carried out over the Internet that allow users to purchase for their shopping online. They include various payment methods such as:
- Credit and debit cards - the most popular payment method. It involves providing your payment card (e.g. Visa or Mastercard) details in the payment form issued by the payment gateway.
- Electronic wallets - services such as Apple Pay or Google Pay where card tokens generated for a specific card are returned to make a payment.
- Openbanking - direct transfers from your bank account.
- Crypto - an increasingly popular method, although less common. This is a way of making transactions in which digital currencies based on blockchain technology are used instead of traditional fiat currency (such as dollars, euros or zlotys) e.g. Bitcoin, Ethereum, Litecoin or Ripple
ECommerce payments place a strong emphasis on security and convenience to meet the needs of both sellers and consumers. Additionally, they often involve various security systems, such as SSL, to protect users' personal and financial information and to
prevent from frauds.
As this field develops, more and more eCommerce payment methods are being created, and therefore there is a need for entities that aggregate available payment options in one place and allow to manage sensitive card data in the name of the merchants which are not PCI DSS compilent. Such an entity is Verestro Paytool, a payment gateway and a payment service provider that supports above mentioned payment methods such as credit and debit cards, payment with Google Pay and Apple Pay wallets and payment using the BLIK code.
How does it work?
- Selection of goods or services
- The customer selects the products or services he or she wants to buy and adds them to a shopping cart on the online store's website.
- Moving to checkout
- After completing the purchase, the customer goes to the “checkout” section, where he enters his contact information, shipping address and chooses a payment method.
- Choosing a payment method
- Online stores offer various payment methods, such as: Credit or debit card payments (Visa, MasterCard, etc.).
- Credit and debit cards - the most popular payment method. It involves providing your payment card details in the payment form issued by the payment gateway.
- Electronic wallets - services such as Apple Pay or Google Pay where card tokens generated for a specific card are returned to make a payment.
- Openbanking - direct transfers from your bank account.
- Crypto - an increasingly popular method, although less common.
- Online stores offer various payment methods, such as: Credit or debit card payments (Visa, MasterCard, etc.).
- Payment authorization
- Depending on the payment method selected, the authorization process can be carried out in different ways:
- Card payment: the customer enters the card data (number, expiration date, CVV code) and approves the transaction. The payment system (e.g. Stripe, PayPal) then sends the data to the bank for authorization.
- Online transfer: the system redirects the customer to his bank's website, where he logs into his account and approves the transfer.
- Electronic wallet: after selecting a payment method, the customer logs into his wallet (e.g. PayPal), where he approves the payment.
- Depending on the payment method selected, the authorization process can be carried out in different ways:
- Transaction security
- Transactions are usually secured with encryption protocols, such as SSL (Secure Socket Layer), to prevent third parties from intercepting payment data.
- In addition, some payment methods (such as card payments) require identity verification, such as through 3D Secure, which is an additional verification step (such as an SMS code or approval in a bank app).
- Transfer of funds
- After successful payment, the funds are transferred to the seller's account. Transaction processing time may vary depending on the payment method selected.
ECommerce payment flow using Paytool payment service provider
The first step of the each transaction always takes place in merchant's application. Such application usually is integrated with the various payment gateways (payment service providers) such as Verestro Paytool. Choosing to pay using a particular payment service provider redirects the payer to the PSP's web view, where all payment methods offered by the PSP are listed. The view of such use case from the end user's perspective has been shown below.
At the level of the view of the list of available payment methods, the payment service provider - in this case Verestro Paytool - is already responsible for the entire transaction. Regardless of which eCommerce payment method the payer chooses, the payment service provider must enable the payer to write out the card data or retrieve it from the mobile wallet (e.g. Google Pay, Apple Pay or Click to Pay), check the correctness of the data, perform payer and his card authentication (e.g. 3D Secure) or finally perform the transaction itself and inform the merchant and the payer about transaction final status.
Direct Debit Payments from eWallet in eCommerce Environment
There is a new payment scenario appearing in the eCommerce landscape – payments directly from a wallet account. Let me describe this use case in this article.
Let’s imagine you are a merchant or a marketplace where multiple users are using cards or various local payment methods for payments. It is obvious that Merchant Fee becomes an important cost factor in your business. Sometimes you pay 1%, but sometimes it can go up to 2-3-5%. There are several ways of limiting this cost – like multi-acquiring described in another article, but one of the interesting ways of doing so is to create a wallet account with an IBAN for the user at the moment of transaction and enable him/her to make a banking transfer in order to charge this account later.
This process can work in the following way:
1. User chooses a product to purchase
2. Merchant informs the user that they will receive a 0.5% discount if they pay by banking transfer
3. User confirms payment and gets an IBAN
4. User transfers money to the IBAN
5. Merchant charges this account
This process can be very useful as after making this transaction it is more likely that the user will repeat this payment process in the next transaction. Thanks to this the merchant can limit their acquiring fees because eventual transaction costs are moved to the user who is initiating a banking transfer in this case. In many countries, a local banking transfer or SEPA transfers are for free, so the users do not have obstacles and can use this payment method any time they come back to the merchant.
In the case of marketplaces, this IBAN can also be used for merchants registered at a marketplace to process a transaction in and out in an effective way.
Please contact us if you are interested in similar use cases.