Canadian Short Code opt-out requirements

STOP/ARRET requirements in the body of the message

To be on the safe side, we recommend that you include language at the end of every message sent from your short code informing users how to stop from receiving further messages (e.g., “Text STOP to cancel”, or “Texter ARRET pour ##### pour annuler”).  Moreover, in all cases, your short code must be able to correctly handle an inbound STOP or ARRET message: a compliant STOP/ARRET message must be returned and you must discontinue sending messages to that end user unless the user re-initiates the service again.

However, strictly speaking, carriers distinguish between the following situations with respect to whether you must include STOP/ARRET language in the body of every message:

  • For a subscription service/recurring program, you must include STOP/ARRET language in the body of the messages that are part of the sign-up flow.  However, once the end user has opted into the program, you need not include STOP/ARRET language in the body of subsequent messages..
  • For an info on demand/single message program, you do not need to include the STOP/ARRET language in the body of messages sent to the user.  The rationale is that the user is initiating a response text from your service and therefore explicitly requesting you to send a short code message.
Remember that there is absolutely no difference when it comes to receiving the keyword STOP/ARRET from a user. If carriers audit a short code and text the keyword STOP/ARRET to your short code, a compliant STOP/ARRET message must be returned, and you must discontinue sending messages until the user initiates the service again.

More specifically, when a user sends the keyword STOP/ARRET to a short code, the application must reply with a message stating, “At your request we will no longer send you messages in connection with <your program name>” (or something similar), even if the phone number is not subscribed, or if you are not running a subscription service. You must also stop sending messages of any kind to that user until/unless the user sends another “JOIN” message to initiate the service again.

Have more questions? Submit a request
Powered by Zendesk