Change theme
Change theme

Case scenarios about merchants and the incidental payment function

Publication date: December 12, 2023

The following fictional case scenarios provide examples of providing or maintaining an account payment function and explain the incidental concept 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 ABC Inc. 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 ABC Inc. 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 ABC Inc. 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 ABC Inc. 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 would be incidental to the non-payment activity, and Merchant ABC Inc. would not need to register as a payment service provider (PSP) with the Bank of Canada.

Case scenario: Payment service provider services an online merchant

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

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

Given that Fintech DEF Inc.’s main line of business is providing payment services to merchants (including Merchant ABC Inc.) and its payment activities generate revenues, Fintech DEF Inc. is not performing payment functions as an incidental service or business activity. Fintech DEF Inc. is a PSP under the RPAA and needs to register with the Bank of Canada.

Case scenario: Merchant activity that is not incidental

Let’s now assume that Merchant ABC Inc. expands the functionalities of its mobile application so other merchants not affiliated with or owned by Merchant ABC Inc. can use it. As a result, other merchants or businesses can sign a contract to use Merchant ABC Inc.’s application to accept payments at their own stores. The Merchant ABC Inc. account solution now appears as an option on the other merchants’ online stores. Clients can use their Merchant ABC Inc. log-in credentials to use the information stored on their Merchant ABC Inc. account to make payments to the other merchants. In exchange, those merchants pay a transaction fee to Merchant ABC Inc. 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 ABC Inc. 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 ABC Inc. to offer its mobile application now consist 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 ABC Inc. to receive payments from their respective clients. This means that Merchant ABC Inc. 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 ABC Inc. 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 ABC Inc.’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 ABC Inc. is not performing payment functions as an incidental service or business activity. It meets the definition of a PSP under the RPAA and should assess whether it needs register with the Bank of Canada.

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