Publication date: August 21, 2024
The following fictional case scenarios provide examples of payment functions, namely the initiation of an electronic funds transfer (EFT) at the request of an end user, and the authorization of an EFT or the transmission, reception or facilitation of an instruction in relation to the EFT. They also provide 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: Website and e-commerce building tools
Company A sells a software tool for merchants to build an e-commerce website. By subscribing to this software, merchants can easily build their own online store using customizable themes and a simple drag-and-drop interface. Merchants can use the software to decide how they want to display their products and offer a shopping cart function on their website. Company A typically charges merchants a monthly fee that includes access to the tool and hosting for the website.
Company A does not, however, handle the check-out process for the merchants who use its services. Instead, it has designed its software tool to be compatible with various payment gateways and payment processing solutions that can be built into the merchant’s website as a plug-in.
While Company A provides services to merchants that help them to sell their products online, it does not perform any payment functions. When a merchant’s client clicks on the checkout button on the merchant’s website, they are redirected to a page or portal hosted by another service provider, and Company A is not involved in the payment process. As a result, Company A is not considered a payment service provider (PSP) under the Retail Payment Activities Act (RPAA) and does not need to register with the Bank of Canada.
Case scenario: Payment gateways
Company B offers a software interface that merchants, including those using Company A’s website building tool, can integrate into their website to facilitate the checkout process and accept payments. Company B’s software captures and encrypts the relevant information regarding the payer and the payment credential (e.g., credit card) used for the payment, and relays that information to another entity that further processes the transaction. In doing so, Company B’s software allows for the transfer of a payer’s information between a payment portal and the front-end processor or the acquirer used by a merchant. Company B markets its software as a payment gateway and typically charges merchants a fixed fee per transaction for its services.
In providing this service, Company B is considered to perform the payment function of initiating an EFT at the request of an end user. This is because it captures the relevant payment information and packages it to generate the first payment instruction that triggers the EFT.
The software also allows the payer to give their consent for the transaction: after entering the necessary payment information, the software prompts the payer to click on an Order Now button, which puts the transaction into motion. Further, the software receives a payment instruction in relation to the EFT when it receives a confirmation that the payment has been approved and processed from another participant in the payment chain. As such, Company B also performs the following payment function: authorization of an EFT or the transmission, reception or facilitation of a payment instruction in relation to an EFT.
In this scenario, while Company B does not handle funds from the end user directly, it still meets the definition of a PSP, since it performs various payment functions in a manner that is not incidental to another service or business activity that it provides. As a result, it needs to register with the Bank, assuming it meets the other registration criteria.
Case scenario: E-commerce and payment gateway solution
Company A begins to offer its own payment gateway solution, which is paired with its e-commerce web-building tool. Now, merchants can choose between two options. They can use the solution offered by Company A to build their online store only, and use a third-party payment company such as Company B to facilitate payments. Alternatively, they can use Company A’s services not only to build their web store, but also to facilitate the checkout process and accept payments a. Company A still provides its services as a package for which merchants pay a monthly fee. Merchants can choose between the software package that includes only the web-building tool for a monthly fee, or they can include the payment gateway service at a higher monthly price.
By offering its own payment gateway solution, Company A now performs the following payment functions: the initiation of an EFT, and the authorization of an EFT or the transmission, reception or facilitation of an instruction in relation to an EFT.
Although Company A has historically offered, and continues to offer, a website building tool that has no payment component, the assessment of whether Company A is a PSP that needs to register with the Bank is affected by its introduction of payment services. Unless its payment services can be considered incidental to its website building tool, Company A would now meet the definition of a PSP.
In this case, the payment service is not incidental and represents a distinct service or business activity. By providing its own payment gateway option instead of redirecting to a third-party provider, Company A is now offering an additional service that its merchant customers use for a purpose that is distinct from that of the website building tool. Although the payment gateway and e-commerce building tool are packaged together and complement each other, the e-commerce building tool does not require Company A’s payment gateway to function. Even though Company A does not sell its payment gateway as an individual service, the gateway adds value to its commercial offering, which directly helps Company A generate more revenues. In addition, many other companies on the market offer similar payment gateway services on a standalone basis. Given these considerations, the payment functions that are being performed by Company A would not be considered incidental to its other, non payment-related, services or business activities.
As a result of this new service offering, Company A now meets the definition of a PSP under the RPAA and needs to register with the Bank, 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.
Topic(s):
Registration