Case scenarios about merchants and the incidental payment function

Publication date: December 12, 2023

The following fictional case scenarios offer examples of providing or maintaining an account payment function as well as examples of incidental activities under the Retail Payment Activities Act.

The examples provided are not a replacement for the Criteria for registering payment service providers supervisory policy, but rather they are meant to complement the policy. They should be read in conjunction with the policy.

These examples build off each other. We recommend reading them in the order they appear.

Case scenario: Merchant activity that is incidental

Merchant A sells boots online. At no additional cost, its customers can create an account to store personal information, like their name and address, to simplify future purchases. This way, they can simply log in to their account and make purchases without having to re-enter all their information.

By storing customer information, Merchant A is performing the payment function “provision or maintenance of an account” as defined in section 2 of the Retail Payment Activities Act (RPAA) (in addition to its non-payment-related activity of selling boots online).

In this case, however, Merchant A performs the payment function only to directly support a non-payment activity. In other words, it maintains an account:

  • exclusively to facilitate or improve the end user’s experience when buying boots online (the non-payment activity)
  • not as a distinct service or business activity that would directly generate incremental revenue

Further, clients of Merchant A likely do not expect to receive payment services when using their accounts with the business because they use them only to shop boots online.

Based on these indicators, the payment function is incidental to the non-payment activity, and Merchant A does not need to register as a payment service provider (PSP) with the Bank of Canada.

Case scenario: Online merchant uses a payment service provider

To accept online payments from its clients, Merchant A enters into an agreement with Company B, a financial services platform. In exchange for a merchant fee, Company B provides an application programming interface (API) that allows merchants like Merchant A to accept a large set of payment methods on their website and process online payments. In doing so, Company B performs several payment functions as set out in the RPAA:

  • initiation of an electronic funds transfer (EFT)
  • authorization of EFT or transmission, reception or facilitation of an instruction in relation to an EFT

Given that Company B’s main line of business is providing payment services to merchants (including Merchant A) and its payment activities generate revenues, Company B is not performing payment functions as an incidental service or business activity. Company B is a PSP under the RPAA and needs to register with the Bank of Canada, assuming it meets the other registration criteria.

Case scenario: Merchant activity that is not incidental

Let’s now assume that Merchant A expands the functionalities of its mobile application so other merchants not affiliated with or owned by Merchant A can use it. As a result, other merchants or businesses can sign a contract to use Merchant A’s application to accept payments at their own stores. The Merchant A account solution now appears as an option on the other merchants’ online stores. Clients can use their Merchant A log-in credentials to use the information stored on their Merchant A account to make payments to the other merchants. In exchange, those merchants pay a transaction fee to Merchant A every time their customers use the mobile application as their means of payment. While these merchants have to pay an additional transaction cost, the mobile application attract new customers who appreciate the convenience of using Merchant A application.

It is important to consider new situations like the one described in this scenario because they can change the incidental nature of a payment function. Based on the elements and indicators described in the Criteria for registering payment service providers, the payment function performed by Merchant A to offer its mobile application now consists of a distinct service or business activity that is no longer incidental.

First, the application allows merchants that are not affiliated with or owned by Merchant A to receive payments from their respective clients. This means that Merchant A is no longer performing the payment function only to enable the sale of its own goods but is instead performing them as a service to others.

Second, the fact that Merchant A charges a fee to other businesses to use its payment service and thus generates revenues from that service further indicates that the payment function and activities have become a distinct business line.

Even if the payment function continues to support Merchant A’s non-payment activity at its own locations (the sale of its boots), it is not performed exclusively to support that non-payment activity anymore.

Consequently, Merchant A is not performing payment functions as an incidental service or business activity. It meets the definition of a PSP under the RPAA and needs to register with the Bank of Canada, assuming it meets the other registration criteria.

Disclaimer

The case scenarios are illustrative examples reflecting the Bank of Canada’s interpretation of certain requirements set out in the Retail Payment Activities Act (RPAA). All names, facts and descriptions in these scenarios are entirely fictitious and do not reflect any real or actual individuals or entities.

Additionally, they do not represent legal advice and should not be used as a replacement for seeking such advice if an individual or entity is unsure about whether they are required to register with the Bank of Canada as a payment service provider. The nature of the products and services offered by each individual or entity will vary, as will the circumstances around offering these products and services. Therefore, any individual or entity that may be subject to the RPAA should assess their own situation on a case-by-case basis according to their own facts and circumstances. Any entity or individual that may be subject to the RPAA is ultimately responsible for determining whether they are required to register with the Bank.

The examples provided are not a replacement for the Criteria for registering payment service providers supervisory policy, but rather they are meant to complement the policy. They should be read in conjunction with the policy.

On this page
Table of contents