The French Language and Law 25

Quebec is not an edge case for vertical software. It is a market with its own language rules and its own privacy statute, and both of them attach to whoever controls the customer experience. When your platform runs the card flow, that is you. The processor you used to hand payments off to is no longer the party writing the checkout copy, sending the receipt, or deciding how long a cardholder record sits in your database.

This is the trade that comes with keeping payment revenue in-house. You gain the economics. You also inherit a compliance surface that used to live somewhere else. The argument here is simple: build French and Law 25 handling as product infrastructure before you become the payment facilitator, not as a patch after your first Quebec merchant complains.

Owning the flow means owning the language

Quebec's language rules reach further into commerce than most US-headquartered software teams expect. Contracts of adhesion, invoices, receipts, order forms, and consumer-facing interfaces generally need to exist in French. Not machine-translated French. Not French that appears only when a user digs through a settings menu. The practical standard is that a Quebec customer should be able to complete the transaction start to finish without leaving their language.

When payments sat with an outside processor, a meaningful chunk of that text belonged to the processor. Their hosted checkout. Their receipt template. Their dispute notification. Move the flow inside your product and those strings become your strings. The payment page, the decline message, the refund confirmation, the stored card management screen, the chargeback notice you forward to the merchant, the merchant agreement your merchant signs to start accepting cards at all. Every one of those is now yours to translate and maintain.

The maintenance part is what teams underestimate. A single English release that adds a new error state creates an untranslated gap. Over eighteen months of shipping, those gaps accumulate into a checkout that is half French and half English, which is worse than either. The fix is structural. Treat locale as a first-class attribute of the merchant account, not a browser setting. Block deploys that introduce untranslated payment-facing strings. Have a Quebec French reviewer, not a general francophone reviewer, sign off on financial terminology.

Law 25 changes who answers for the data

Quebec's Law 25 has been fully in force for several years now, and the enforcement posture has hardened. The obligations that matter most to a platform running payments include appointing a privacy officer, maintaining a published and specific privacy policy, obtaining meaningful consent for collection and use, disclosing transfers outside Quebec with an assessment behind them, reporting confidentiality incidents, and honoring data portability requests.

Under the old arrangement, your processor carried much of the weight on cardholder data. As a payment facilitator, you are collecting and processing personal information about both merchants and their end customers. Merchant onboarding alone pulls identity documents, banking details, beneficial ownership information, and often a personal credit check on the principal. That is a dense concentration of sensitive data sitting in your systems because you chose to underwrite.

Three operational realities follow. First, your data map has to be real and current, because a portability request or an incident report gives you no time to go find out where things live. Second, cross-border transfers need documented assessments, which matters if your infrastructure, your sponsor bank, or your fraud vendor sits outside Quebec. Third, retention needs an actual schedule with deletion that works, because indefinite storage is the default state of most payment systems and it is the hardest thing to unwind later.

Why retrofitting costs more than building it in

The temptation is to launch the payment facilitator model, win merchants, and address Quebec when volume justifies it. That sequencing is expensive for a specific reason: payment data is the hardest data to reorganize after the fact.

Translated interfaces can be added incrementally. Retention and deletion cannot, not easily, once transaction records, tokenized instruments, dispute evidence, and settlement history are entangled across systems that were designed to keep everything forever. The same applies to consent. If you did not capture a defensible consent record at onboarding, you cannot reconstruct one from a log file two years later.

There is also a commercial argument. Vertical software wins on being the system of record for an industry. A Quebec clinic, contractor, or dealership evaluating your platform will ask whether their customers get a French receipt and whether their patient or client data is handled under Law 25. A vague answer costs the deal. A specific answer, backed by a French checkout your sales engineer can demo live, closes it.

What to do next

Pick one Quebec merchant segment and scope the full path. List every payment-facing string, from onboarding through dispute resolution, and mark which ones exist in French today. Separately, map where merchant and cardholder personal information enters, moves, and rests in your stack, then attach a retention rule to each store.

Bring Quebec counsel in early, before you write requirements, and have your payments partner document exactly which obligations sit with them and which sit with you. Get that division in writing. Then build the language and privacy handling into the same release cycle as the payment facilitator launch, so Quebec merchants can be sold to on day one rather than deferred to a roadmap item nobody owns.