Card Payments with Smartphones in Europe in 2019 – What are In-App and Card-on-file payments or CIT and MIT payments in the era of the new PSD2

1. Paying within the mobile app is on the rise

Nowadays, many mobile merchants, meaning a merchant providing their services and products to their customers through a mobile application, charge their customers based on the payment card details (e.g. Visa, Mastercard, American Express) entered in the phone application.

This is how it works for example in EasyPark parking app, HSL mobile ticket app, VOI Scooters app and in many other apps. In the future, this convenient card payment method is expected to expand even further, for example to the electric car charging business.

Payment within a mobile application, so-called in-app payment, where an app user saves their payment card information in the app for the use of the merchant has become more common as the number of mobile apps has grown. For a merchant, this type of customer onboarding is cost effective and fast.

2. What happens in an in-app payment in practice?

In-app payment is technically a Card-on-file payment where the cardholder gives the merchant, usually in the terms of use of the application;

1) permission to store the customer's payment card information in the merchant's information system; and

2) to charge the payment card in a mutually agreed manner, either in a way that;

  • a) the customer initiates the payment through a mobile application (so-called CIT payment, cardholder initiated transaction); or
  • b) the merchant automatically charges the payment card without the active involvement of the customer (so called MIT payment, merchant initiated transaction).

It is good to know that a merchant does not store their customers' payment card numbers or other sensitive card data in their mobile application, but only a unique token generated by a payment service provider, such as Seitatech, from which the original payment card number cannot be calculated or deduced. This also means that if a customer's smartphone is stolen, the customer's payment card number or other sensitive card data will not be stolen.

Seitatech offers to mobile merchants its Card-on-file service and its card payment processing service (Payment Gateway), both services, developed, owned and maintained by Seitatech. Both services are necessary and required to mobile merchants to receive in-app payments in compliance with new PSD2 regulation.

Seitatech's Card-on-file service includes as standard Seitatech's 3D Secure service, which protects merchants from card payment frauds and limits the merchant's financial liability for payment card frauds. The Payment Gateway service of Seitatech is an essential card payment processing service for every merchant to receive card payments.

The popularity of the in-app card payment feature among mobile merchants has long been based on a positive payment experience for users. From the customer's point of view, paying in-app is easy and hassle-free when you only have to accept the payment when using the service, without having to enter a PIN code or use the payment card for each payment, for example.

3. What should every mobile merchant know about strong customer authentication (PSD2)?

PSD2, the new EU Payment Services Directive, has introduced new security regulations for mobile merchants from September 14, in the form of Strong Customer Authentication (SCA).

In practice, failure to provide strong customer authentication means a loss of revenue to the merchant when the card issuer rejects any payment that could be interpreted as contrary to the new regulations.

The major effects of PSD2 on merchants receiving card payments in the mobile app are:

  1. Payment card details are not sufficient to identify the customer. Customers cannot use in-app payment as a payment method based solely on their payment card information, but must verify their identity in the app when making a payment as required by PSD2;
  2. The general rule is always strong customer authentication. In-app payments will, in principle, require strong customer identification (SCA) unless regulated exceptions apply (see section 6);
  3. The general rule is always double authentication. For in-app payments, customers must, in principle, verify their identity when making a payment in at least two of the following ways:
  • Information (something that only the payer knows, such as a one-time password to be sent by SMS or e-mail or a PIN or password known to the payer);
  • Possession (something that only the payer has, e.g. the payer's own smartphone, card reader or other device); and
  • The payer's feature (e.g. face, fingerprint, voice tag or another payer's biometric identifier).

4. The payment initiated by the payer (CIT payment) generally requires strong customer identification.

  • CIT payment (payment initiated by the cardholder in the mobile application, e.g. purchase of a HSL mobile single ticket), in principle, requires strong customer identification in accordance with section 3, unless exceptions (section 6) apply;

5. Merchant-initiated payment (MIT payment) requires strong customer identification on the first time.

MIT payment (a payment initiated by a merchant based on the card information entered into the mobile application) requires strong customer identification when giving the merchant a MIT payment assignment in the mobile application. After this customer's strong authentication, there is no need to repeat the customer’s strong authentication.

In addition, payment by MIT requires that the cardholder by contract authorizes the merchant to charge MIT payments. To learn more about the topic, see the link with the answer from the European Banking Authority (EBA) to a question:

“Are card payments that are initiated by the payee on the basis of (1) an initial mandate authorizing the payee to initiate the periodic payments and (2) a pre-existing agreement between the payer and the payee for the provision of products or services, subject to RTS SCA requirements? "

    6. Exceptions to strong customer authentication.

Essential to remember! The acceptability of an exception is always decided on a case-by-case basis by the card issuer bank and cannot be directly derived from the EU regulation.

Therefore, even if EU regulation allows a certain exception to apply to a particular situation, it does not mean that it is available to all merchants. This is due to the increasing transfer of responsibility for card payment frauds to card issuer banks under new EU regulation.

In-app payments do not, in principle, require strong customer authentication in the following situations:

  • Payments of less than EUR 30. The exception is limited.

In-app one-time payments of less than EUR 30 are exempt from strong customer authentication.

Successive purchases of less than EUR 30 can be made up to a maximum of one hundred (100) euros and a maximum of five (5) payments without strong customer authentication.

  • Merchant initiated recurring payments (MIT payment). The exception is limited. Strong customer authentication is required once.

These fees include e.g. monthly subscription fees for social media (i.a. LinkedIn), digital TV channels (i.a. Netflix) and other service providers, which repeatedly charged the customers at predetermined amounts.

  • A trusted merchant registered by the payer. The exception is limited.

In practice, this condition requires the card issuing bank's approval, and even if the payer has registered a particular merchant as trustworthy, the payer's bank may unregister the merchant.

- Seita's team

More about the impact of PSD2 on card payments, please contact our:

Mr Markus Laaksonen
Head of Development
Seita Technologies Oy

Scroll to top