What is Secure Remote Commerce? (SRC)

SRC - a new era of e-commerce?

The published press release in late April on Secure Remote Commerce (SRC) by EMVCo from the major schemes proves that the payment industry has already begun to direct their focus on eCommerce. Online shopping has become a vast industry that keeps on growing together with the digital evolvement. This increasing trend makes it a paradise for hackers and people with fraudulent intentions, especially since the security related to storing and processing card data have not been evolving equally fast to meet every new modern fraud methods.

The EMV security standards utilized at physical point-of-sales have shown to be successful in decreasing frauds and thefts. Together with the concept of tokenization where a token replaces the PAN makes this a solid security wall for keeping out anyone who wants to steal and misuse payment credentials from a cardholder. The introduction of SRC within the eCommerce domain would mean that we now can expect to achieve the same level of security for online shopping as we have in EMV chip and contactless payments.

Security is a large part of SRC; however, it also aims to simplify the shopping experience for consumers which in turn should decrease the number of abandoned shopping carts. One standard interface for all card schemes, no more manual entry of card data or home addresses, and simple checkout with just a few clicks. Having only a few steps together with convenient authentication, such as biometric/face recognition using technology like 3DS2.0, will give the shoppers with a whole new and easygoing experience.

Convenience and security are two elements in online shopping that have been on opposite side on the scale in eCommerce. The more security the merchant adds to its checkout process, the more cumbersome for the consumer to complete the process. This leads to an increased abandonment of shopping carts. Merchants are forced to accept a higher risk to gain more customers. This problem will be solved by SRC which offer both security and convenience in the same package.

SRC introduces the concepts of tokens and dynamic cryptograms which the merchant obtains during a checkout process from a token service provider through the SRC system. The token data will then be processed in a regular transaction flow, increasing the security and lowers the potential fraud for merchant and PSP.

One significant advantage for the merchant is the promise of a standard interface for all the card schemes participating in the SRC program. That will considerably simplify implementation and enablement. These services will further be available to the consumer through a common ‘checkout button’ on the merchant page and will be able to access all their stored cards (tokens) and shipping details with just a few clicks at every checkout.

But what about ID&V? How do we make sure that this is the rightful owner that is doing the checkout? After the first login, the SRC utilizes cookies to recognize re-visiting consumer which allows them to complete a checkout process. However; the issuing bank may choose to enforce ID&V smoothly and efficiently by using 3DS2.0 in the checkout process. 3DS2.0 supports authentication and authorization through issuer’s mobile banking application using device capabilities such as fingerprint and face recognition, in addition to existing methods from 3DS1.0.

Issuers must participate

For consumers to tokenize and store their cards with SRC, the issuing bank must connect to the card schemes’ token service provider (TSP). All of the major card schemes (Visa, Mastercard, American Express) have developed their own TSP which offers services that allow for creating, provisioning and managing digitized cards. This issuer-to-TSP connection will be a prerequisite for enabling SRC.

Getting started with SRC, card tokenization, token management may be a high barrier for many issuing banks. Understanding the concept, acquiring technical knowledge and developing support for one or multiple schemes can become costly and time-consuming. On top of this are the frequent changes in technology which will require follow up on new updates, re-development and potential strict and expensive certification tracks. However, the issuing bank has other possibilities than doing this by themselves.

SRC and card tokenization are within MeaWallet's core focus. We have built a pre-certified platform (referred to as Mea Token Platform) for those issuers who want to enable digital payments in a simplified and secure manner. All is provided through a single interface for integration which simplifies the complexity and reduces workload for the Issuer. The product comes together with the knowledge and guidance of our team and thus gives a short, easy and low-risk path to digital payments.

Our mission at MeaWallet is to help our clients simplify mobile payments and support implementation. Our team is passionate about the subject and continually looking at the evolution and trends in the mobile payments space. We welcome your comments or invite you to get in touch directly with us at contact@meawallet.com 

DSRP - The magic behind those four letters

DSRP - The magic behind those four letters

Since you have found the way to this blog post, the assumption is that you already know a bit about the concepts of card tokenization and dynamic cryptograms and how these enhance security within payments. Contactless payments with HCE enabled devices already leverages these security concepts, but have yet to be put to use for online payments.

A google search on e- and m-commerce gives clear indications that predict a significant increase over the next couple of years. There are over three billion internet users in the world today, and it is expected to be conducted around 195 billion m-commerce transactions annually by 2019. These numbers suggest that the two security concepts mentioned above should be applied to enhance secure online shopping as well. Mastercard has introduced a solution to this called Digital Secure Remote Payment (DSRP), which is tokenization and dynamic cryptograms brought to e- and m-commerce.

Card-on-file transactions
Card-on-file transactions are the most common methods to perform payments when shopping online in a browser or in-app. These types of transactions use static card data (such as a PAN, expiry date, and CVC/CVV), provided by the consumer, merchant or a third-party service at the time of checkout*. The card data is combined with payment details from the merchant and then transferred to the issuer over the appropriate network for validation.

*Card data may come from three different sources during checkout:
1. Consumer: Manually inputs the card data
2. Merchant: If the merchant is certified, the consumer can choose to store card data at the merchant after the first visit. This enables the merchant to retrieve the card data whenever the consumer is ready for checkout.
3. Third-party service: Consumers may create an account and store card data using services such as PayPal or a Amazon Pay. Card data will then be retrieved during checkout at merchants who have implemented this as a payment option.

Security mechanisms (e.g., 3D-secure) are present to conduct safe and reliable online transactions. However, as it is the same static data which is sent over the network for each transaction, the vulnerability and the risk of fraud increases.

This is where tokenization and cryptograms come into play. By using dynamic cryptograms unique to each transaction, prevention of anyone re-using the transactional data applies. The generated cryptograms will only be valid for one single transaction, and can not be reused once it has been utilized.

A contributing factor to transaction vulnerability is the direct connection between the PAN and bank account. This is why substitutions with device tokens through tokenization will help reduce the risks. A device token is not affiliated with anything considered to be sensitive information, and will not be of any value to others but the schemes own token service provider. They have the property of being easily invalidated and discarded if the situation requires it.

Digital Secure Remote Payment
Digital Secure Remote Payments bring tokenization and dynamic cryptograms to online shopping in order to achieve the same level of transaction security as held through a contactless HCE transaction in-store. The transaction flow utilizes the mobile device capabilities and includes elements such as authentication, token retrieval, and cryptogram generation. Facilitating this requires the online merchant and wallet application to communicate, and both parties will need to implement the relevant APIs and SDKs from Mastercard.

All DSRP transactions need to go through the mobile device in order to retrieve the tokens, in addition to the consumer who is required to apply their mobile PIN for payment authentication. Successful authentication leads to the sending of the token and generated cryptograms from the device to the online merchant, who will process these as a substitute for card-on-file data.

DSRP brings EMV security to online payments using the consumer’s own mobile device as a point-of-sale. An intriguing part is the absence of a terminal throughout the transaction process. When it is possible to achieve the same security level without physical terminals, why do we need them in stores? An important reason is that DSRP requires the device to be online. This will obviously, not be possible everywhere, so we need them still. But who can tell what the future will bring?

If the focus is on a digital mobile strategy, the next steps will be to start with tokenization and Masterpass, which are the foundations that must be in place to achieve DSRP.

Our mission at MeaWallet is to help our clients simplify mobile payments and support implementation. Our team is passionate about the subject and continually looking at the evolution and trends in the mobile payments space. We welcome your comments or invite you to get in touch directly with us at contact@meawallet.com 

Tokenization vs. Digitization - What is the difference?

Tokenization vs. Digitization

Tokenization and digitization are two central elements in mobile payments which are easily mixed when talking about them. Many are confused about their meaning and therefore use them interchangeably. Let us have a look at what the difference is:


Tokenization is simply the act of generating a device token (also called payment token). This will function as a representation of the funding primary account number (PAN) and expiry date given on your payment card. A mapping between the PAN data and the payment token is then created in a secure token vault for use in subsequent transaction processing.

It is possible to have several device tokens mapped to the same underlying funding PAN. This will be the case if you have two or more devices in which you want the card to be stored and be able to pay with:

Figure: Multiple device tokens mapped to the same underlying PAN

If the device is lost or stolen, the mapping can simply be deleted from the token vault in order to make the device token invalid. The device will then no longer be able to perform transactions.


The process of card digitization optionally includes tokenization (however required by Visa and Mastercard), but in addition embraces all other subprocesses needed to make a complete digital card ready and provisioned onto a device. These subprocesses comprise of important tasks such as identification and verification of the cardholder, card- and device eligibility checks, tokenization approval, provisioning of the digital card and initial key replenishment.

The figure below shows it very clear that tokenization is just one element of digitization and handles only the part with token creation and mapping. When speaking of digitization, we are referring to the complete process starting with the digitization request from the consumer's device, to the card is fully digitized (gone through every one of the subprocesses listed) and provisioned onto the device with key credentials. When the digitization process is complete, the device is ready to be used for payment.

   Figure: A simple overview of the different subprocesses included in digitization

MeaWallet has made all of this simple with its Mea Token Platform that handles both digitization and tokenization, by connecting Issuers to AmEx, Mastercard and Visa’s respective token platforms. Get in touch with us if you are interested in learning more about how this works and how we can help you get started with mobile payments. Just leave a reply in the contact form at the bottom of our web page, and one of us will contact you in no time. 

Our mission at MeaWallet is to help our clients simplify mobile payments and support implementation. Our team is passionate about the subject and continually looking at the evolution and trends in the mobile payments space. We welcome your comments or invite you to get in touch directly with us at contact@meawallet.com