Conditions pour les développeurs

Les présentes conditions pour les développeurs régissent la construction et l’exploitation d’une intégration RapidCents : la façon dont les identifiants d’API sont émis et l’endroit où chacun peut se trouver, ce à quoi sert le sandbox et ce qu’il ne doit jamais contenir, l’utilisation permise des API et les conséquences d’un dépassement de limite, la vérification des webhooks et leur traitement idempotent, la dépréciation des versions, la propriété de chaque élément, et la portée PCI DSS que votre intégration détermine. Elles font partie de l’entente de services RapidCents et lient à la fois le commerçant et quiconque construit pour lui. Lorsque l’entente de services énonce déjà une règle, les présentes conditions la citent par lettre et numéro d’article afin que vous puissiez en lire le texte opérationnel.

Section A — Portée et application

1. Qui les présentes conditions lient

Les présentes conditions visent toute personne qui touche à votre intégration RapidCents : vos propres développeurs, un entrepreneur, une agence ou un fournisseur de logiciels qui travaille pour vous. Peu importe qui écrit le code, c’est le commerçant dont le compte est utilisé que RapidCents tient responsable.

Les présentes conditions pour les développeurs régissent l’accès aux API, aux SDK, à Rapid.js, à RapidBridge, aux webhooks, aux plugiciels, au sandbox et à la documentation pour développeurs de RapidCents, ainsi que leur utilisation (collectivement, les « Services pour développeurs »). Elles font partie de l’entente de services RapidCents et y sont intégrées. Les termes définis de l’entente de services s’appliquent ici avec le même sens, notamment « Services », « Utilisateur secondaire », « Données du titulaire de carte », « règles des réseaux », « Client » et « Transaction ».

Elles lient deux parties, et il vaut la peine de préciser lesquelles. La première est le Commerçant : l’entreprise dont le compte RapidCents a été approuvé et dont les identifiants font fonctionner l’intégration. La seconde est toute personne qui construit, exploite, entretient ou détient un accès à cette intégration pour le compte du Commerçant : un employé, un entrepreneur, une agence, un intégrateur, un fournisseur de logiciels ou un consultant. L’entente de services appelle cette seconde partie un Utilisateur secondaire et définit ce terme comme visant tout tiers à qui le Commerçant accorde des identifiants ou un accès aux API.

La conséquence est énoncée dans l’entente de services plutôt qu’inventée ici. La définition d’Utilisateur secondaire rend le Commerçant responsable de tout ce qu’un Utilisateur secondaire fait sous le compte comme s’il l’avait fait lui-même, et l’article B.1 (au point 1.2) rend le Commerçant entièrement responsable de toutes les activités qui se déroulent sous son compte. Un développeur qui expose une clé, ignore une limite ou soumet une Transaction pour laquelle le compte n’est pas approuvé crée un manquement du Commerçant. RapidCents n’arbitre pas les différends entre un commerçant et son développeur, et rien dans les présentes conditions ne crée de contrat entre RapidCents et un développeur qui n’est pas lui-même un Commerçant.

Si vous êtes un développeur et que vous lisez ceci sans détenir votre propre compte RapidCents, lisez-le comme la norme que votre client est contractuellement tenu de vous imposer. Si vous êtes un Commerçant, lisez l’article 6 avant de remettre des identifiants à qui que ce soit.

2. Rapport avec l’entente de services

Si les présentes conditions et votre entente de commerçant se contredisent, c’est l’entente qui l’emporte. Les présentes conditions ajoutent du détail; elles ne remplacent rien.

Les présentes conditions pour les développeurs sont supplétives. Elles reprennent des obligations que l’entente de services impose déjà et ajoutent le détail opérationnel dont une intégration a besoin, à l’endroit où un développeur le cherchera. Elles ne modifient pas l’entente de services, ne la restreignent pas et ne créent pas de droits qu’elle n’accorde pas.

Lorsque les présentes conditions et l’entente de services peuvent se lire ensemble, les deux s’appliquent. En cas de conflit, l’entente de services prévaut. Un renvoi, dans les présentes conditions, à une lettre et à un numéro d’article — B.3, D.2, E.1 — est un renvoi à cet article de l’entente de services publiée à /legal/terms.

La politique d’utilisation acceptable, la politique de confidentialité, la page sur la conformité PCI et la page sur la sécurité s’appliquent également à une intégration. L’article B.5 intègre la politique d’utilisation acceptable à l’entente de services par renvoi, et l’article D.1 (au point 1.4) fait de même pour la politique de confidentialité. Rien dans les présentes conditions n’écarte l’une ou l’autre.

La référence API et la documentation pour développeurs décrivent le comportement de la plateforme; elles ne font pas partie de l’entente de services. Lorsque la documentation et un article opérationnel divergent, l’article régit les obligations des parties et la référence régit le contrat technique : le nom d’un champ, son type, ses valeurs permises, une limite.

Section B — Identifiants d’API

3. Les identifiants émis par RapidCents et ce que chacun permet

Il existe différents types de clés et elles ne sont pas interchangeables. Une clé publiable ne pose pas de problème dans un navigateur parce qu’elle ne peut pas déplacer d’argent. Une clé secrète peut rembourser : sa place est sur un serveur et nulle part ailleurs.

RapidCents émet des identifiants qui diffèrent par leur rôle et par leur environnement. Cette séparation constitue la conception même : ce qu’un identifiant permet de faire détermine où il peut se trouver sans risque, et un identifiant capable de déplacer de l’argent n’est jamais admis là où un utilisateur, un navigateur ou un décompilateur peut le lire.

Les identifiants sont émis au Commerçant, rattachés au compte RapidCents du Commerçant. Ils ne sont pas émis à un développeur en son nom propre, ils ne sont pas transférables d’un commerçant à un autre, et un développeur qui travaille pour plusieurs commerçants doit utiliser les identifiants propres à chacun pour le trafic de celui-ci, plutôt que d’acheminer plusieurs entreprises par un seul jeu d’identifiants. Soumettre les Transactions d’une autre entreprise au moyen de vos identifiants est interdit par l’article B.4(g) et par l’article H.9, quelle que soit l’organisation du code.

Les identifiants du sandbox et ceux de la production sont émis séparément, et aucun ne s’authentifie dans l’autre environnement. C’est une propriété sur laquelle s’appuyer plutôt qu’une limite à contourner : une confusion d’environnement échoue immédiatement au lieu de réussir au mauvais endroit.

La signature des requêtes est offerte en complément de l’identifiant pour les intégrations serveur à serveur qui exigent une preuve d’intégrité au-delà du TLS, et elle est recommandée pour les flux à valeur élevée. Elle ne remplace pas le fait de garder la clé secrète confidentielle.

Identifiants émis par RapidCents

Identifiant	Où il se trouve	Ce qu’il permet
Clé API secrète	Côté serveur uniquement, chargée à l’exécution depuis un gestionnaire de secrets	Crée, encaisse, rembourse et consulte — toute la capacité du compte dans son environnement
Clé publiable	Code client, dans le navigateur et le mobile	Initialise Rapid.js et échange les données de carte contre un jeton; ne peut pas déplacer d’argent
Secret de signature des webhooks	Côté serveur uniquement, dans le point de terminaison qui reçoit les événements	Prouve qu’un événement entrant a bien été envoyé par RapidCents
Autorisation OAuth	Détenue par une plateforme agissant pour une entreprise connectée	Agit pour cette entreprise sans que la plateforme détienne ses clés; révocable par l’entreprise

Chacun de ces identifiants est cloisonné à un seul environnement. Un identifiant sandbox ne s’authentifie pas en production, et un identifiant de production ne s’authentifie pas dans le sandbox. La possibilité d’appliquer à une clé une restriction plus étroite, en lecture seule, se confirme auprès de la référence API et de votre personne-ressource de compte RapidCents.

4. Une clé secrète ne doit jamais se retrouver dans du code client

Ne mettez jamais une clé secrète dans une page Web, un paquet d’application, un binaire mobile, un dépôt ou un billet de support. Si une clé sort, considérez-la comme compromise et faites la rotation avant même d’enquêter.

C’est la seule obligation des présentes conditions qui n’admet aucune exception, aucune dérogation pour un environnement de préproduction et aucun arrangement temporaire. Une clé API secrète ne doit pas figurer dans du code client, ni nulle part où une personne autre que le personnel autorisé du Commerçant peut la lire. L’article B.1 (au point 1.2) de l’entente de services rend le Commerçant responsable de la confidentialité et de la sécurité des identifiants de son compte, y compris les clés API, et l’article B.3 le rend responsable de la sécurité de ses clés API en particulier.

En pratique, l’interdiction vise tout ce qui suit, à titre indicatif et non exhaustif :

• Le JavaScript servi à un navigateur, y compris un paquet, une carte de sources, un script en ligne et un objet de configuration rendu dans la page.
• Un binaire d’application mobile, un actif compilé ou tout autre élément livré à un appareil, qu’il soit obscurci ou non.
• Un dépôt de code public ou partagé, un historique de commits, un billet, une demande de fusion ou un journal d’intégration continue.
• Un billet de support, un courriel, un message de clavardage, une capture d’écran, un enregistrement d’écran ou un document transmis à un tiers — y compris un document transmis à RapidCents.
• Une variable d’environnement côté client, un fichier de configuration servi au client, ou toute requête faite par le navigateur qui porte la clé en paramètre ou en en-tête.

Lorsque la saisie de carte doit se faire dans un navigateur ou une application, utilisez Rapid.js avec la clé publiable, ou le checkout hébergé, qui déplace entièrement la saisie de carte sur une page hébergée par RapidCents. Une clé publiable ne peut qu’échanger des données de carte contre un jeton; elle ne peut ni créer, ni encaisser, ni rembourser un paiement, et c’est ce qui permet de la livrer sans risque. Votre serveur crée ensuite le paiement à partir de ce jeton au moyen de la clé secrète, qui ne quitte jamais votre infrastructure.

L’obscurcissement n’est pas une mesure de contrôle. Pas davantage une clé conservée dans une variable côté client, restreinte par référent, ou intégrée à une application destinée à un usage interne seulement. Si une clé secrète peut être extraite de quelque chose que vous distribuez, elle est exposée, et elle peut émettre des remboursements.

Une clé secrète qui s’est retrouvée à l’un de ces endroits est compromise, que vous puissiez démontrer ou non qu’elle a été utilisée. Faites d’abord la rotation, enquêtez ensuite : émettez une nouvelle clé, déployez-la, confirmez dans vos journaux de requêtes que l’ancien identifiant de clé n’apparaît plus, puis révoquez l’ancienne. L’article 5 expose la suite, et l’article 21 traite du signalement.

5. Conservation, rotation et révocation

Gardez les clés dans un gestionnaire de secrets, utilisez des clés différentes par environnement et par système, changez-les selon un calendrier et chaque fois qu’une personne y ayant accès part, et gardez brièvement les deux clés actives pour que rien n’échoue pendant la rotation.

L’article D.2 (au point 2.2) de l’entente de services exige que le Commerçant mette en place et maintienne des mesures de sécurité raisonnables et adaptées à la nature des renseignements protégés, notamment des mots de passe forts et uniques, l’authentification multifacteur lorsqu’elle est offerte, l’application des correctifs, des pare-feu, le chiffrement et des contrôles d’accès, des évaluations et des analyses de vulnérabilité régulières, la formation du personnel et un plan d’intervention en cas d’incident. Appliqué aux identifiants d’API, cela signifie ce qui suit.

• Chargez les identifiants depuis un gestionnaire de secrets à l’exécution. Ne versionnez que des valeurs fictives dans la configuration, et exécutez une analyse de secrets avant qu’un commit n’atteigne un dépôt.
• Utilisez des identifiants distincts par environnement, afin que le trafic du sandbox ne puisse atteindre la production et qu’une clé de production ne puisse être déployée par accident en préproduction.
• Refusez de démarrer l’application lorsque l’identifiant ne correspond pas à l’environnement attendu. Cela transforme une panne en production en un déploiement qui échoue.
• Émettez des identifiants distincts par système et par personne partout où la plateforme le permet, afin qu’une rotation ou une fuite touche un seul consommateur plutôt que tous à la fois. L’intégration continue devrait avoir les siens.
• Journalisez l’identifiant de la clé qui a servi chaque requête, afin qu’une fuite se retrace jusqu’à un système au lieu de se deviner.
• Faites la rotation selon un calendrier fixe, et immédiatement lorsqu’un employé, un entrepreneur ou une agence ayant accès à un identifiant part ou que le mandat prend fin.

Faites la rotation avec chevauchement. Révoquer l’ancien identifiant au moment même où le nouveau est émis fait échouer toutes les requêtes encore en vol : émettez le nouvel identifiant, déployez-le, regardez l’ancien identifiant disparaître de vos journaux, puis révoquez. Répéter la séquence complète dans le sandbox prouve le mécanisme avant le jour où il faudra l’exécuter sous pression en production.

RapidCents peut révoquer ou réémettre un identifiant lorsqu’il est compromis, lorsqu’il est utilisé en contravention des présentes conditions ou de l’entente de services, ou lorsque l’article B.5 permet une suspension. L’article 11 traite de ce cas.

RapidCents ne vous demandera jamais une clé secrète, un mot de passe ou un code à usage unique, et aucun document, courriel ou échange de support de RapidCents n’exige que vous en transmettiez un. Considérez comme frauduleuse toute demande en ce sens, et signalez-la conformément à l’article 21.

6. Développeurs, agences et plateformes agissant pour un commerçant

Si vous embauchez quelqu’un pour construire votre intégration, donnez-lui ses propres identifiants et retirez-les à la fin du mandat. Si vous êtes une plateforme qui encaisse pour d’autres entreprises, il faut OAuth et une approbation écrite : vous ne pouvez pas faire passer leurs ventes par votre propre compte.

Le Commerçant qui retient les services d’un développeur, d’une agence ou d’un fournisseur de logiciels accorde un accès à un Utilisateur secondaire. L’entente de services rend le Commerçant responsable de ce que cette personne fait sous le compte comme s’il l’avait fait lui-même, et l’article B.1 (au point 1.2) le rend responsable de toutes les activités qui se déroulent sous le compte.

Deux arrangements sont souvent confondus, et ils sont régis différemment.

• Un développeur qui construit ou exploite une intégration pour un seul Commerçant, sur le compte de ce Commerçant, avec les identifiants de ce Commerçant. Il s’agit d’un arrangement d’Utilisateur secondaire. Il est permis, et les obligations des présentes conditions incombent au Commerçant.
• Une plateforme, une place de marché ou un fournisseur de services qui soumet, règle ou reçoit des fonds pour des Transactions appartenant à d’autres entreprises. Il ne s’agit pas d’un arrangement d’Utilisateur secondaire et il n’est pas permis sur un compte ordinaire. L’article B.4(g) interdit d’utiliser les Services pour traiter des Transactions pour un tiers ou d’agir comme intermédiaire ou agrégateur de paiement, et l’article H.9 le précise en détail opérationnel : une place de marché, des sous-marchands, des sous-comptes, un règlement fractionné ou des versements pour le compte d’autrui exigent l’approbation écrite préalable de RapidCents, donnée expressément et non par le comportement.

Lorsqu’une plateforme est approuvée pour agir au nom d’entreprises connectées, OAuth est le mécanisme : la plateforme agit pour une entreprise sur l’autorisation de cette entreprise, sans jamais détenir ses clés, et l’entreprise peut révoquer l’autorisation sans faire tourner quoi que ce soit de son côté. Lorsqu’une autorisation est révoquée, les appels faits pour cette entreprise échouent à l’autorisation alors que les identifiants de la plateforme demeurent valides; traitez cela comme un changement d’état dans votre plateforme plutôt que comme un incident généralisé.

À la fin d’un mandat, retirez l’accès qu’il exigeait. Faites la rotation de tout identifiant que la partie sortante a pu lire, révoquez son accès au tableau de bord et retirez ses systèmes de toute liste d’autorisation. L’article D.2 (au point 2.2) exige des contrôles d’accès; une agence qui détient encore une clé de production fonctionnelle dix-huit mois après la remise du projet constitue une défaillance de ce contrôle, et cette défaillance demeure celle du Commerçant.

Rien dans les présentes conditions ne fait de RapidCents une partie au contrat entre un Commerçant et son développeur. RapidCents n’offre aucune garantie et n’assume aucune responsabilité à l’égard des travaux exécutés par un développeur retenu par le Commerçant.

Section C — Environnements

7. Le sandbox, et ce à quoi il ne sert pas

Le sandbox est une copie complète de l’interface avec de l’argent fictif. Construisez-y, cassez-y des choses, testez-y les refus et les remboursements. N’y mettez jamais un vrai numéro de carte, et ne l’utilisez jamais comme banc d’essai de charge.

Le sandbox est un environnement isolé, doté de ses propres identifiants, d’identifiants de marchand test, de réseaux de cartes simulés et d’un règlement accéléré. Rien de ce qui s’y trouve ne touche aux données de production ni à de l’argent réel. Ce n’est pas une maquette réduite : les points de terminaison, les corps de requête, les codes d’erreur et les charges utiles des webhooks sont ceux que sert la production, et il est versionné de la même façon, ce qui rend le travail qui y est fait transférable plutôt qu’à refaire.

L’accès au sandbox est émis pendant l’évaluation, sans entente de commerçant signée, et il demeure offert après la mise en production afin que les livraisons continuent d’être vérifiées. L’utilisation du sandbox est une utilisation des Services et elle est régie par l’entente de services et par les présentes conditions.

Le sandbox ne doit pas être utilisé avec de véritables données de carte. Les numéros de carte, dates d’expiration, codes de sécurité, noms de titulaires et toute autre Donnée du titulaire de carte réelle ne doivent jamais être soumis à un point de terminaison sandbox, saisis dans un formulaire sandbox ni intégrés à un jeu de données de test. Testez avec les cartes de test documentées, qui sont ce qui rend un résultat déterministe et reproductible. Il ne s’agit pas d’une préférence de style : un vrai numéro de compte principal envoyé à un environnement de test constitue une communication de Données du titulaire de carte en dehors du flux pour lequel elle a été autorisée, et cela fait entrer les systèmes qui l’ont traité dans la portée de la norme PCI DSS.

Le sandbox ne doit pas non plus être utilisé avec les données réelles d’une autre personne. N’utilisez pas les renseignements d’un titulaire de carte réel, le compte d’un autre commerçant, les renseignements personnels d’un tiers ni des fiches clients de production pendant vos tests, et n’employez pas de techniques qui dégradent l’environnement pour les autres.

Quatre écarts par rapport à la production sont voulus, et c’est de là que viennent les surprises de mise en production :

• Les frais, les délais de versement et les décisions d’acceptation observés dans le sandbox sont illustratifs. Votre tarif réel et votre calendrier de dépôt proviennent de votre compte et non d’une réponse du sandbox, et aucune sortie du sandbox ne constitue une soumission.
• Le règlement est comprimé afin qu’un cycle complet, de l’encaissement au dépôt, puisse être exercé en une seule séance. En production, le versement suit le calendrier de versement de votre compte, et un traitement conçu sur le rythme du sandbox restera inactif.
• Le sandbox est un environnement de justesse, non de capacité. Les chiffres qu’on y observe ne disent rien du débit en production, et un test de charge qui y est mené produit surtout des réponses de limitation. L’article 10 s’y applique.
• Les jetons, les fiches clients et les paiements ne franchissent pas la frontière des environnements. Une carte mise en coffre dans le sandbox n’a aucun équivalent en production, et tout ce dont vous avez besoin en production doit y être créé.

La durée de conservation des données du sandbox, et la question de savoir si un compte sandbox inactif est récupéré, relèvent de l’exploitation plutôt que des modalités du présent document. Adressez-vous au support pour développeurs si un jeu de données de test doit être conservé.

8. Passage en production

Quatre éléments changent à la bascule : la clé secrète, la clé publiable, le secret de signature des webhooks et le point de terminaison où sont livrés les événements. Changez les quatre ensemble : un remplacement partiel échoue d’une manière qui ressemble à tout autre chose.

L’accès à la production exige un compte RapidCents approuvé. Les identifiants du sandbox ne le confèrent pas, et une intégration sandbox qui fonctionne parfaitement ne constitue pas un compte marchand approuvé.

À la bascule, traitez les éléments suivants comme un seul ensemble de changements : la clé secrète, la clé publiable, le secret de signature des webhooks et le point de terminaison auquel les événements sont livrés. Un remplacement partiel est l’échec de mise en production le plus courant et il se présente de façon trompeuse : un gestionnaire qui vérifiait correctement chaque événement du sandbox rejette tous les événements réels lorsque le secret de signature n’a pas été remplacé, et comme un rejet ressemble à une requête falsifiée, on y voit fréquemment une attaque.

Avant la bascule, exercez les chemins difficiles à reproduire par la suite : une approbation, un refus, un remboursement, un défi 3-D Secure et au moins un webhook rejoué confirmant que votre gestionnaire écrit une seule fois plutôt que deux. Changez ensuite les clés, effectuez un petit paiement réel, remboursez-le et suivez le règlement du premier lot.

Le passage en production ne met fin ni à l’accès au sandbox ni aux présentes conditions. Tout ce que contient le présent document s’applique à une intégration de production de la même façon qu’à celle qui a été construite dans le sandbox.

Section D — Utilisation acceptable des API

9. Utilisation acceptable des API

Utilisez les API comme l’indique la documentation, pour votre propre entreprise, dans le respect de la loi et des règles des réseaux de cartes. Ne démontez pas la plateforme, ne revendez pas l’accès et n’essayez pas de contourner ses contrôles de risque.

L’article B.3 de l’entente de services exige que le Commerçant se conforme à la documentation d’API et aux consignes d’utilisation en vigueur lorsqu’il utilise les API de RapidCents. L’article B.2 accorde une licence limitée, non exclusive, incessible, non sous-licenciable et révocable pour accéder aux Services et les utiliser uniquement aux fins internes de l’entreprise du Commerçant. L’article B.4 énonce ce que le Commerçant s’engage à ne pas faire et à ne pas laisser un tiers faire. Ces restrictions s’appliquent à une intégration exactement comme au tableau de bord, et elles sont reprises ici parce que le développeur est la personne en mesure d’y contrevenir :

• N’utilisez pas les Services pour développeurs à des fins illégales, frauduleuses ou non autorisées, ni pour quoi que ce soit qu’interdit la politique d’utilisation acceptable.
• Ne les utilisez pas d’une manière qui contrevient à une loi, à un règlement ou à une règle des réseaux applicable.
• Ne copiez, ne modifiez, ne rétroconcevez, ne décompilez et ne désassemblez aucune partie des Services ni du Logiciel RapidCents, y compris les SDK, Rapid.js, RapidBridge et les plugiciels.
• Ne louez, ne vendez, ne distribuez et ne sous-licenciez pas les Services ni le Logiciel RapidCents, et ne revendez pas l’accès aux API et ne l’offrez pas à des tiers comme un service qui vous appartiendrait.
• Ne nuisez pas à l’intégrité ou à la performance des Services ni des données qu’ils contiennent.
• Ne tentez pas d’obtenir un accès non autorisé aux Services ni aux systèmes ou réseaux connexes, y compris au compte ou aux données d’un autre commerçant.
• N’utilisez pas les Services pour traiter des Transactions pour un tiers et n’agissez pas comme intermédiaire ou agrégateur de paiement, sauf dans la mesure où l’article H.9 le permet avec une approbation écrite préalable.
• Ne transmettez pas de vers, de virus, de maliciels ni de code de nature destructrice.

Deux autres interdictions découlent de la politique d’utilisation acceptable et méritent d’être nommées dans un contexte d’intégration. N’éludez pas, ne désactivez pas et n’entravez pas les contrôles de risque, de fraude, de vérification ou de conformité de RapidCents, et ne dénaturez pas la nature, le montant, la devise, le pays ou le Client d’une Transaction afin d’obtenir une autorisation. Et n’ouvrez ni n’exploitez un second compte, ou un compte au nom d’une autre personne ou entité, afin de contourner une limite, une Réserve, une suspension ou une résiliation.

L’interrogation répétée n’est pas interdite, mais c’est la mauvaise conception et elle est imputée aux mêmes limites que tout le reste. Relire sans cesse un paiement pour voir si quelque chose a changé est plus lent que le webhook, plus lourd pour vos limites, et rate tout de même un remboursement ou une contestation soulevée à l’extérieur de votre application. L’article 12 expose la solution de rechange.

10. Limites de débit

Il existe des limites à la vitesse à laquelle vous pouvez appeler l’API. Les dépasser donne une erreur documentée assortie d’une indication de relance, et non une requête abandonnée. Ralentissez lorsque vous la voyez; n’insistez pas.

L’article B.3 de l’entente de services prévoit que RapidCents peut fixer des limites à l’utilisation des API, exprimées par exemple en nombre de requêtes par seconde. Les limites s’appliquent par compte, et elles valent dans le sandbox comme en production.

Le présent document ne publie pas les valeurs numériques de ces limites, car elles constituent une propriété de l’interface plutôt qu’une modalité du contrat et elles ont leur place là où une intégration peut en tenir compte : les limites applicables à votre compte, et la façon dont une réponse signale que l’une d’elles est atteinte, sont documentées dans la référence API. Si votre intégration a un besoin légitime qui les dépasse — un rapprochement de masse, une migration, une pointe saisonnière —, soulevez-le auprès du support pour développeurs à l’avance plutôt que de découvrir la limite en production.

Le dépassement d’une limite renvoie un code d’état documenté assorti d’une indication de relance plutôt que d’abandonner la requête en silence. Traitez cette réponse comme un signal et non comme une panne : ralentissez selon l’indication, relancez avec une variation aléatoire, et portez une clé d’idempotence pour qu’une requête qui a bel et bien réussi ne soit pas appliquée deux fois. Continuer d’émettre au même rythme est ce qui transforme une limitation en incident.

Le mépris persistant d’une limite — un client qui relance immédiatement et indéfiniment, un test de charge exécuté contre la production, ou un trafic qui, de l’avis de RapidCents, menace de façon imminente la sécurité, l’intégrité ou la disponibilité des Services — constitue un motif de suspension immédiate au titre de l’article B.5 de l’entente de services. L’article 11 expose ce que cela signifie en pratique.

11. Suspension et retrait des identifiants

RapidCents peut couper votre accès aux API sans préavis si l’intégration menace la plateforme ou enfreint les règles, et retenir des fonds pendant qu’elle enquête. Perdre l’accès aux API n’entraîne aucuns frais d’annulation : RapidCents n’en facture pas.

L’article B.5 de l’entente de services permet à RapidCents de suspendre immédiatement et sans préavis l’utilisation des Services lorsque le Commerçant ou un Utilisateur secondaire enfreint intentionnellement la politique d’utilisation acceptable, ou utilise les Services en contravention de l’entente d’une manière qui, de l’avis de RapidCents, menace de façon imminente la sécurité, l’intégrité ou la disponibilité des Services. Il énumère également les motifs pour lesquels l’accès peut être suspendu ou résilié sans préavis, notamment un manquement à l’entente ou à la politique d’utilisation acceptable, un usage soupçonné frauduleux, illégal ou non autorisé, une activité qui présente un risque de sécurité, le refus de collaborer à une enquête ou de fournir les renseignements demandés, et des taux de rétrofacturation, de retour ou de plainte supérieurs aux seuils applicables.

Appliquée à une intégration, la suspension peut prendre la forme d’une révocation ou d’une désactivation d’identifiant plutôt que d’une fermeture de compte. RapidCents peut révoquer, désactiver ou réémettre un identifiant, le restreindre à une capacité plus étroite, ou bloquer le trafic d’une intégration donnée, lorsque l’un des motifs de l’article B.5 s’applique ou lorsqu’un identifiant est compromis.

Pendant une suspension, RapidCents peut retenir les fonds du compte RapidCents ou d’une Réserve jusqu’au règlement d’une enquête ou d’un différend, comme le prévoit l’article B.5. Cet article consigne également la renonciation du Commerçant à toute réclamation contre RapidCents pour les pertes découlant de mesures prises pour des motifs d’intégrité ou de sécurité.

La suspension n’est pas la résiliation, et ni l’une ni l’autre n’entraîne de pénalité. RapidCents ne facture aucuns frais d’annulation ni frais de résiliation anticipée. L’article F.1 (au point 1.2) permet au Commerçant de résilier à tout moment sur avis écrit et consigne que RapidCents ne facture aucuns frais de résiliation anticipée et n’impose aucune pénalité pour la fermeture d’un compte avant la fin d’une durée, et l’article A.4 l’énonce clairement. L’article A.3 ajoute un droit supplémentaire d’annuler sans pénalité dans les circonstances précises qu’il énumère — l’introduction de nouveaux frais, la hausse de frais existants en dehors d’un barème que l’entente nomme déjà, le défaut de répercuter une réduction des coûts d’interchange, ou une modification défavorable importante imposée unilatéralement — exerçable sur avis écrit dans les quatre-vingt-dix (90) jours. Lorsque l’accès est rétabli, il l’est sur le même compte et aux mêmes conditions.

La résiliation de l’entente de services révoque la licence d’utilisation du Logiciel RapidCents, comme le prévoit l’article A.7, et avec elle la licence de l’article 18 des présentes conditions. Les obligations destinées par leur nature à survivre à la résiliation — notamment celles qui touchent la propriété intellectuelle, la confidentialité, la responsabilité ainsi que la collaboration et la conservation des dossiers à la suite d’une compromission — y survivent également ici.

Section E — Webhooks

12. Livraison des webhooks et vérification de la signature

Les webhooks vous disent ce qui s’est passé après le retour de votre requête. Vérifiez la signature sur le corps brut avant de faire confiance à l’événement, et répondez rapidement par un 2xx.

Les webhooks livrent les événements du cycle de vie d’un paiement à un point de terminaison exploité par le Commerçant : autorisation, encaissement, remboursement, ouverture d’une contestation et versement du règlement, entre autres. Ils existent parce que l’essentiel de ce qui arrive à un paiement survient après le retour de la requête initiale — un remboursement effectué au tableau de bord, une rétrofacturation déposée des semaines plus tard, un dépôt versé pendant la nuit — et rien de cela n’atteint une intégration qui ne lit que des réponses synchrones.

Chaque charge utile est signée par un HMAC calculé sur les octets exacts envoyés. Vérifier cette signature est une obligation du Commerçant, et non une mesure de renforcement facultative. Un point de terminaison de webhook non vérifié est une instruction non authentifiée de modifier l’état d’une commande, de libérer des marchandises ou de créditer un compte, accessible à quiconque en apprend l’adresse.

• Captez le corps brut de la requête avant qu’un intergiciel ne l’analyse. Un intergiciel de cadriciel qui analyse le JSON et vous remet un objet a déjà modifié les octets, et le HMAC ne correspondra pas; le symptôme est un événement valide rejeté comme falsifié.
• Calculez le HMAC sur ce corps brut avec le secret de signature de l’environnement d’où provient l’événement, et comparez-le à l’en-tête de signature en temps constant.
• Rejetez tout ce qui ne correspond pas, et ne vous rabattez pas sur un traitement quand même. Un échec de vérification n’est pas un problème de format.
• Traitez le secret de signature avec la même rigueur qu’une clé secrète : côté serveur, dans un gestionnaire de secrets, jamais dans du code client, et avec la rotation qu’exige l’article 5.
• Enregistrez le point de terminaison en HTTPS, à une adresse routable dotée d’un certificat valide. Plusieurs points de terminaison peuvent être enregistrés, ce qui est l’arrangement le plus propre quand des systèmes différents s’intéressent à des événements différents : un service de commandes qui consomme les événements de paiement et un traitement financier qui consomme les événements de règlement n’ont pas à partager un gestionnaire.

L’en-tête exact, l’algorithme et l’encodage utilisés pour la signature sont documentés dans la référence API, qui en constitue le contrat technique faisant autorité.

Le sandbox et la production signent avec des secrets différents. Un gestionnaire qui a vérifié correctement pendant tout le développement rejettera chaque événement réel si le secret n’a pas été remplacé à la bascule; l’article 8 les traite comme un seul ensemble de changements précisément pour cette raison.

13. Livraison au moins une fois, ordre et traitement idempotent

Le même événement peut arriver plus d’une fois et dans le désordre. Répondez d’abord 2xx, faites le travail ensuite, et rendez ce travail répétable sans dommage.

La livraison des webhooks se fait au moins une fois. Le même événement peut être livré plus d’une fois, et un événement plus tardif peut arriver avant un événement plus ancien. Ces deux caractéristiques relèvent du modèle de livraison et non d’un défaut, et une intégration qui présume une livraison exactement une fois et en ordre finira par exécuter une commande en double. Les gérer est une obligation du Commerçant.

• Dédupliquez sur l’identifiant de l’événement. Consignez les identifiants déjà traités et faites en sorte qu’une deuxième livraison du même événement n’ait aucun effet.
• Accusez d’abord réception par un code 2xx et effectuez le travail lent ensuite. Tout ce qui sort du 2xx est lu comme un échec et planifie une relivraison : une écriture lente en base de données à l’intérieur du gestionnaire produit des livraisons en double plutôt qu’un succès tardif.
• Fiez-vous à l’état porté par la charge utile plutôt qu’à l’ordre d’arrivée, et ignorez un événement qui ferait reculer une ressource.
• Utilisez une clé d’idempotence sur tout appel d’API qui modifie un état, y compris celui que votre gestionnaire effectue en réponse à un événement, afin qu’un appel relancé ne puisse être appliqué deux fois.
• Déclenchez une alerte sur les réponses non 2xx répétées de votre propre point de terminaison. Les livraisons n’échouent pas bruyamment du côté récepteur; chaque tentative et son résultat sont consignés avec l’événement, et un point de terminaison silencieusement hors service se découvre autrement par l’intermédiaire d’un client.

Lorsqu’un point de terminaison n’accuse pas réception, la livraison est relancée selon un calendrier de temporisation progressive, puis cesse. Le nombre de tentatives et la période sur laquelle elles s’étalent sont documentés dans la référence API plutôt que fixés par le présent document. Un événement dont la réception n’a jamais été accusée n’est pas perdu : les événements demeurent consultables par l’API, de sorte que la reprise après une panne prolongée est un rattrapage et non une demande de support.

C’est le webhook, et non la réponse synchrone, qui devrait piloter l’état d’une commande. La réponse indique ce qui s’est produit à cet instant; le webhook rapporte tout ce qui suit, et c’est le seul canal qui porte un remboursement ou une contestation née à l’extérieur de votre application.

Section F — Versions et changements

14. Versions de l’API et dépréciation

Fixez votre version. Les changements incompatibles sont livrés dans une nouvelle version : rien ne bouge sous vos pieds tant que vous ne basculez pas. Lorsqu’un élément est retiré, vous recevez un avis et une fenêtre, publiés dans le journal des modifications.

L’API de RapidCents est versionnée, et une version est fixée par compte et peut être envoyée explicitement sur une requête. Les changements par ajout parviennent à une intégration ancrée sans aucune action, puisque la version fixée continue de se comporter comme documenté. Les changements incompatibles sont livrés dans une nouvelle version et demeurent facultatifs jusqu’à ce que le Commerçant y bascule.

RapidCents peut déprécier une version d’API, un point de terminaison, un type d’événement, un champ ou une version de SDK. Le cas échéant, un avis est publié dans le journal des modifications pour développeurs. L’entrée précise ce qui change, quelle version d’API le porte, s’il s’agit d’un ajout ou d’une rupture et, pour une dépréciation, la date à laquelle l’ancien comportement cesse. L’ancien comportement continue d’être servi jusqu’à cette date.

La durée du préavis est fixée pour chaque dépréciation et énoncée dans l’entrée du journal des modifications plutôt que fixée dans le présent document, parce que la fenêtre appropriée n’est pas la même pour le retrait d’un champ facultatif et pour le retrait d’une version. L’engagement de RapidCents est qu’un changement incompatible est annoncé avec une fenêtre de migration avant l’arrêt de l’ancien comportement, et que cette fenêtre et sa date de fin sont publiées plutôt que communiquées uniquement sur demande. Lorsqu’un changement doit être fait sans le préavis habituel — parce qu’une règle des réseaux, un organisme de réglementation ou une faille de sécurité l’exige —, RapidCents l’indiquera dans l’avis et accordera tout le délai que la situation permet.

Les obligations du côté du Commerçant relèvent de l’hygiène technique ordinaire, et il lui revient de les remplir : fixer explicitement la version d’API plutôt que de suivre la plus récente; consigner la version envoyée par chaque service, afin qu’une migration soit une liste connue de déploiements et non une découverte; acheminer les avis du journal des modifications là où l’équipe de garde peut les voir, car un abonnement dirigé vers une boîte non surveillée équivaut à aucun abonnement; et éprouver la nouvelle version dans le sandbox pendant la fenêtre plutôt qu’à sa fin.

Une version de SDK vise une version d’API précise : monter un paquet peut donc faire franchir à une intégration une frontière de version sans aucune modification de votre propre code. Fixez le paquet et fixez la version d’API séparément.

L’article F.2 de l’entente de services régit les modifications de l’entente elle-même, ce qui est distinct d’un changement apporté à l’API. L’article 22 des présentes conditions traite des modifications du présent document.

15. SDK, plugiciels et intégrations tierces

Les SDK et plugiciels officiels sont des logiciels pris en charge. Une version dérivée ne l’est pas : elle cesse de recevoir les correctifs, y compris ceux de sécurité. Tout ce que vous branchez en provenance d’un tiers est à vos risques, pas aux nôtres.

RapidCents publie des SDK officiels pour Node.js, Python, PHP et le mobile; des plugiciels et extensions pour les plateformes de commerce courantes, dont un plugiciel WooCommerce pour les boutiques WordPress et une connexion pour une vitrine Shopify; Rapid.js pour les champs de carte intégrés; et RapidBridge pour amener les paiements dans un logiciel d’affaires qui ne peut pas être modifié. Chaque version de SDK indique la version d’API qu’elle vise. Les plateformes couvertes par un plugiciel prêt à l’emploi, et celles qui le sont plutôt par des sessions de checkout hébergé ou des liens de paiement, sont confirmées par votre personne-ressource en intégration plutôt qu’énumérées ici, car cet ensemble évolue.

Gardez-les à des versions prises en charge. La page sur la sécurité énonce la même obligation en termes généraux : une intégration, un plugiciel, un logiciel de point de vente ou un terminal laissé à une version qui ne reçoit plus de correctifs est l’une des façons ordinaires dont commence un incident du côté du commerçant. Confirmez la compatibilité d’un plugiciel avant une montée de version majeure de la plateforme plutôt qu’après l’arrêt du paiement.

Ne dérivez pas un plugiciel ni un SDK pour y ajouter une fonction. Une copie modifiée cesse de recevoir les mises à jour, y compris celles de sécurité, et hérite de toutes les incompatibilités futures; lorsque le besoin est réel, construisez-le plutôt sur Rapid.js ou sur les API. L’article B.4 interdit de toute façon de copier, de modifier, de rétroconcevoir et de redistribuer le Logiciel RapidCents, et l’article 18 précise ce que la licence permet et ne permet pas.

Les services, applications et contenus de tiers sont régis par l’article B.6 de l’entente de services. RapidCents ne les cautionne ni ne les contrôle, ne formule aucune déclaration ni garantie quant à leur fonctionnalité, leur sécurité ou leur fiabilité, peut cesser d’en prendre en charge n’importe lequel à tout moment et sans préavis, et n’assume aucune responsabilité pour les pertes découlant de leur utilisation. Évaluer, choisir et mettre en œuvre une intégration tierce relève de la responsabilité du Commerçant, tout comme le respect des conditions de ce fournisseur, et la disponibilité d’un service tiers par l’entremise de RapidCents n’implique aucune relation d’affaires entre RapidCents et son fournisseur.

Les conditions de licence sous lesquelles un SDK ou un plugiciel officiel est distribué accompagnent le paquet. Lorsqu’un paquet porte son propre fichier de licence, cette licence régit le code qu’il contient, en plus des présentes conditions et de l’entente de services.

16. Fonctions bêta et fonctions automatisées

Tout ce qui porte l’étiquette bêta ou aperçu peut casser, changer ou disparaître, sans aucune garantie. Tout ce qui recourt à l’IA, y compris APPIE, peut se tromper : lisez la sortie avant d’agir sur sa foi.

L’article H.7 de l’entente de services régit les fonctionnalités bêta et de préversion ainsi que les fonctions qui recourent à l’intelligence artificielle ou à d’autres traitements automatisés. Ces deux catégories parviennent à un développeur avant quiconque, d’où la reprise des modalités ici.

Une fonction que RapidCents désigne comme bêta, aperçu, pilote, accès anticipé, diffusion limitée ou expérimentale est fournie telle quelle et selon sa disponibilité, sans garantie d’aucune sorte. RapidCents ne s’engage pas à ce qu’elle fonctionne comme décrit, soit prise en charge, soit compatible avec une version ultérieure, préserve les données qui y sont saisies ou devienne un jour une composante généralement offerte des Services, et elle peut la modifier, la restreindre, la suspendre ou la retirer en tout temps, avec ou sans préavis et sans fournir de remplacement. Lorsque RapidCents publie des conditions propres à une fonction bêta, celles-ci s’appliquent en plus des présentes et prévalent sur elles à l’égard de cette fonction. Le Commerçant l’utilise à ses propres risques et demeure responsable de chaque Transaction qui y est traitée.

Une fonction qui recourt à l’intelligence artificielle, à l’apprentissage automatique, à de grands modèles de langage, à des modèles statistiques ou à d’autres traitements automatisés — y compris les fonctions offertes sous le nom APPIE — produit une sortie par inférence et non par vérification. Cette sortie peut être incomplète, inexacte, périmée, incohérente ou erronée d’une manière qui n’est pas apparente, et une même entrée peut ne pas produire deux fois la même sortie. Il incombe au Commerçant de réviser cette sortie avant de s’y fier, d’agir sur sa foi, de l’envoyer à un Client, de l’inscrire dans un registre ou de s’en servir pour satisfaire à une obligation légale, fiscale, comptable, déclarative ou découlant des règles des réseaux, et il ne l’utilisera pas comme seul fondement d’une décision produisant un effet juridique ou comparable sur une personne sans révision humaine de cette décision.

Aucune sortie d’une fonction automatisée, ni aucun contenu généré par les Services, ne constitue un avis juridique, fiscal, comptable, financier, de placement ou de conformité, ne constitue une déclaration de RapidCents selon laquelle une Transaction est licite, authentique, autorisée ou recouvrable, ni ne crée d’obligation, de niveau de service, de délai de réponse ou de garantie de la part de RapidCents. N’utilisez pas une fonction bêta ou automatisée pour développer, entraîner ou améliorer un produit ou un modèle concurrent, et ne présentez pas sa sortie à un Client ou à un tiers comme ayant été vérifiée, cautionnée ou garantie par RapidCents.

Section G — Propriété intellectuelle

17. Propriété : la plateforme, votre code et vos données

RapidCents est propriétaire de la plateforme, des API, des SDK et de la documentation. Vous êtes propriétaire de votre propre code, de votre contenu et de vos données. L’intégration ne transfère la propriété d’aucune des parties à l’autre.

L’article E.1 de l’entente de services répartit la propriété, et la construction d’une intégration ne déplace pas cette frontière.

RapidCents détient l’ensemble des droits, titres et intérêts sur les Services, le Logiciel RapidCents, les API, la documentation, les marques de commerce et logos de RapidCents ainsi que tous les droits de propriété intellectuelle connexes. Les présentes conditions n’accordent aucun droit sur ces éléments au-delà de la licence limitée de l’article 18, et les droits qui ne sont pas expressément accordés sont réservés, comme le prévoit l’article A.7.

Le Commerçant conserve la propriété du contenu, des données et des renseignements qu’il fournit ou téléverse dans les Services, que l’entente de services appelle le Contenu du marchand, et accorde à RapidCents une licence mondiale, libre de redevances et non exclusive lui permettant de les utiliser, reproduire, modifier, adapter et afficher uniquement dans la mesure nécessaire à la prestation des Services. RapidCents ne revendique aucune propriété sur l’application du Commerçant, son code source, sa logique d’affaires, ses fiches clients ou les produits qu’il vend.

Lorsque le Commerçant transmet des suggestions, des idées, des améliorations ou toute autre rétroaction au sujet des Services, l’article E.1 (au point 1.3) accorde à RapidCents une licence mondiale, perpétuelle, irrévocable et libre de redevances lui permettant d’utiliser, de modifier et d’intégrer cette rétroaction aux Services sans obligation. Signaler un défaut ou demander une fonction constitue une rétroaction; cela ne transfère pas le code du Commerçant.

Les Données des Clients relèvent d’une question distincte. L’article D.1 fait du Commerçant le responsable du traitement des renseignements personnels relatifs à ses Clients et de RapidCents un sous-traitant agissant selon les instructions documentées du Commerçant, et il intègre la politique de confidentialité de RapidCents à l’entente de services. La propriété des données et la responsabilité à leur égard ne sont pas la même question, et c’est l’article D.1, et non l’article E.1, qui répond à la seconde.

L’utilisation du nom, des marques et des logos de RapidCents dans une intégration est régie par l’avis de marque de commerce publié à /legal/trademark plutôt que par la licence de l’article 18, qui n’accorde aucun droit sur ceux-ci. Cet avis permet certains usages sans autorisation préalable : indiquer véridiquement sur votre site, dans votre application, sur vos reçus et à votre point de vente que les paiements sont traités par RapidCents, et afficher le logo de RapidCents à cette fin de la manière qu’il prescrit. D’autres usages exigent d’abord la permission écrite de RapidCents, notamment la combinaison d’une marque avec votre propre nom ou logo en un seul macaron, sceau ou verrou graphique, et tout usage qui se lit comme une co-marque ou une caution. Lisez cet avis avant de livrer une marque, et non après.

18. La licence d’utilisation des SDK, de Rapid.js et de la documentation

Vous obtenez une licence limitée d’utilisation des SDK et des outils pour développeurs afin de construire votre propre intégration à RapidCents, tant que votre compte est ouvert et en règle. Vous ne pouvez ni la revendre, ni la sous-licencier, ni démonter ce qu’elle couvre.

L’article B.2 de l’entente de services accorde une licence limitée, non exclusive, incessible, non sous-licenciable et révocable pour accéder aux Services et les utiliser uniquement aux fins internes de l’entreprise du Commerçant, sous réserve du respect de l’entente. L’article A.7 accorde la licence correspondante pour le Logiciel RapidCents et consigne qu’elle ne dure qu’aussi longtemps que le compte RapidCents demeure actif et en règle, qu’aucun droit de propriété sur le logiciel n’est acquis, et que la copie, la modification, la distribution, la rétroconception ou la sous-licence non autorisées sont interdites.

Pour dissiper tout doute, dans les limites de cette licence, le Commerçant et ses Utilisateurs secondaires peuvent :

• Installer, configurer et exécuter les SDK officiels, Rapid.js, RapidBridge et les plugiciels RapidCents afin de relier les propres systèmes du Commerçant aux Services.
• Copier et adapter les exemples de code de la documentation dans la propre application du Commerçant.
• Déployer l’intégration ainsi obtenue dans les propres environnements du Commerçant, y compris le développement, la préproduction, l’intégration continue et la production.
• Accorder à un développeur retenu par le Commerçant l’accès nécessaire à ces travaux, aux conditions énoncées à l’article 6.

La licence ne permet pas de louer, de vendre, de distribuer ni de sous-licencier le Logiciel RapidCents; d’offrir l’accès aux API à des tiers comme un service qui vous appartiendrait; de copier, de modifier, de rétroconcevoir, de décompiler ou de désassembler l’une de ses parties; de retirer ou d’altérer une mention qu’il porte; ni de l’utiliser autrement qu’en lien avec le propre compte RapidCents du Commerçant. L’article B.4 énonce ces interdictions, et rien ici ne les restreint.

La licence prend fin à la résiliation de l’entente de services, comme le prévoit l’article A.7. Les dispositions destinées par leur nature à survivre à la résiliation — notamment celles portant sur la propriété intellectuelle, la confidentialité et la responsabilité — lui survivent.

Les Services, le Logiciel RapidCents et chaque fonction bêta ou automatisée sont fournis sous réserve de l’exclusion de garanties de l’article E.4 et de la limitation de responsabilité de l’article E.5. Rien dans les présentes conditions n’ajoute une garantie, un niveau de service, un engagement de temps de disponibilité ou une garantie de disponibilité que l’entente de services n’accorde pas.

Section H — Données de carte et sécurité

19. Portée PCI DSS et détermination du SAQ applicable

Votre façon de recueillir la carte détermine l’ampleur de vos obligations PCI DSS. Si la carte passe directement du navigateur du client à RapidCents, votre questionnaire est le court. Si elle transite par votre serveur, c’est le long.

RapidCents fait valider chaque année sa conformité en tant que fournisseur de services PCI DSS de niveau 1, et cette validation vise l’environnement de RapidCents. Elle ne vise pas les systèmes du Commerçant et ne le libère pas de ses propres obligations. L’article D.2 (au point 2.1) de l’entente de services exige que le Commerçant maintienne la conformité PCI DSS de ses propres systèmes, processus et personnel, remplisse la documentation de validation applicable à son niveau de commerçant, corrige promptement les manquements constatés et avise immédiatement RapidCents de toute atteinte soupçonnée ou confirmée aux Données du titulaire de carte.

Le questionnaire d’auto-évaluation que le Commerçant doit remplir dépend de son mode d’acceptation réel — c’est-à-dire de décisions prises dans l’intégration. La correspondance ci-dessous couvre les configurations RapidCents courantes, à titre indicatif. C’est votre propre flux de paiement qui détermine votre SAQ, et c’est votre acquéreur, ou un évaluateur de sécurité qualifié le cas échéant, qui le confirme. Le tableau reprend la correspondance publiée sur la page de conformité PCI et ne la modifie pas.

La conséquence pratique, pour un développeur, est qu’une seule décision de conception fait passer le Commerçant du questionnaire le plus court à un programme de conformité complet. Transmettre la carte à votre propre serveur dorsal pour la valider, journaliser un corps de requête contenant un numéro de compte principal ou accepter un numéro de carte dans un formulaire de support suffit chaque fois à provoquer ce passage.

La portée change en silence. Une modification apportée après la validation — un nouveau checkout, un processus de centre d’appels qui saisit des cartes dans un système de commandes, un plugiciel remplacé par un flux sur mesure — peut changer le questionnaire applicable sans que personne ne rouvre la question. Réévaluez immédiatement plutôt que d’attendre la prochaine date de validation : un commerçant validé au SAQ A alors qu’il exploite un flux SAQ D n’est pas validé du tout.

La validation est annuelle et s’effectue au regard de la version de la norme alors en vigueur. L’attestation de conformité de RapidCents ne fait preuve que de l’environnement de RapidCents et ne répond pas à la question d’un réviseur portant sur l’environnement du Commerçant; elle peut être demandée auprès de votre personne-ressource de compte ou du support.

Correspondance entre l’intégration et le questionnaire d’auto-évaluation

Mode de collecte des données de carte	Questionnaire	Ce sur quoi il porte
Checkout hébergé, liens de paiement ou champs intégrés Rapid.js — la carte est transmise du navigateur du client directement à RapidCents et n’atteint jamais vos serveurs	SAQ A	Les tiers auxquels vous vous fiez, les politiques qui les encadrent et la confirmation que la délégation est réelle
Acceptation avec carte présente sur des terminaux homologués autonomes, sans stockage électronique de données de titulaires dans vos systèmes	SAQ B ou SAQ B-IP	La manipulation des appareils, le contrôle physique et la connexion — SAQ B pour une ligne commutée, SAQ B-IP pour un terminal autonome relié par IP
Un checkout sur mesure qui relaie la carte par votre propre serveur, des numéros de carte saisis dans votre CRM ou votre système de commandes, ou tout stockage électronique de données de titulaires	SAQ D	L’ensemble complet des exigences, avec des analyses externes trimestrielles par un fournisseur d’analyse agréé

D’autres questionnaires existent pour des configurations que ce tableau ne décrit pas, notamment les SAQ C, SAQ C-VT et SAQ P2PE. Si aucun de ces cas ne correspond à votre installation, confirmez le bon questionnaire auprès de votre acquéreur plutôt que de le présumer.

20. Données qu’il ne faut jamais conserver

Ne conservez jamais un code de sécurité, un NIP ni des données complètes de puce ou de bande après l’autorisation du paiement. Les chiffrer ne les rend pas permises. Si vous avez besoin d’une carte enregistrée, conservez un jeton.

La norme PCI DSS interdit la conservation des données d’authentification sensibles après l’autorisation. L’interdiction est absolue : le chiffrement ne la lève pas, et elle s’applique que les données se trouvent dans une base de données, un fichier journal, une file de messages, un chiffrier, un formulaire numérisé, un enregistrement d’appel ou un carnet papier. Dans une intégration, c’est habituellement dans le fichier journal et la file de messages que cela se produit. Les éléments suivants ne doivent jamais être conservés après l’autorisation, par quiconque et sous quelque forme que ce soit :

• Les valeurs de vérification de carte — CVV, CVC ou CID.
• Les NIP et tout bloc de NIP, sous quelque forme que ce soit.
• Les données complètes de bande magnétique (piste) après l’autorisation.
• Les données complètes de puce EMV après l’autorisation.

Au-delà de cette interdiction absolue, une intégration devrait éviter de détenir un numéro de compte principal, tout simplement. Lorsqu’il existe une raison véritable de conserver un moyen de paiement, conservez plutôt un jeton RapidCents. La carte est saisie sur une surface hébergée par RapidCents — champs intégrés, checkout hébergé, terminal ou terminal virtuel — et ce que vos systèmes détiennent est une référence que seule RapidCents peut résoudre et qui ne peut être rejouée auprès d’un autre processeur. Conservez le jeton avec la fiche client à laquelle il appartient, gardez la marque et les quatre derniers chiffres à des fins d’affichage seulement, et construisez le chemin qui retire un jeton lorsqu’un client supprime le moyen de paiement, car c’est le chemin que les intégrations omettent le plus souvent.

Conserver le numéro de carte en plus du jeton, même brièvement, même chiffré, remet la donnée d’identification dans votre environnement et annule la raison même de la tokenisation.

N’inscrivez pas de Données du titulaire de carte dans un message d’erreur, une trace d’appels, un événement d’analytique, un rapport de plantage, un outil de suivi de bogues, un billet de support ou un message à RapidCents, et n’envoyez pas de numéros de carte, ni de fichiers qui en contiennent, par courriel ou par clavardage — y compris pendant l’examen d’un incident. RapidCents s’applique la même interdiction : elle ne conserve ni CVV, ni NIP, ni données de puce EMV, ni données de bande magnétique, et les Données du titulaire de carte qu’elle conserve sont chiffrées au moyen d’AES avec des clés de 256 bits et tenues à l’écart des serveurs Web publics.

21. Incidents de sécurité, compromission d’identifiants et signalement de vulnérabilités

Si des données de carte ou vos identifiants sont compromis, avisez RapidCents sans délai — écrivez à la sécurité et au service juridique —, faites la rotation des clés et n’effacez pas les preuves. Si vous découvrez une faille dans un produit RapidCents, signalez-la par la page de divulgation et ne testez jamais avec de vraies cartes.

L’article D.2 (au point 2.3) de l’entente de services exige que le Commerçant avise immédiatement RapidCents de tout événement de compromission de données soupçonné, allégué ou confirmé, quelle qu’en soit la source et y compris s’il touche l’un de ses fournisseurs de services tiers, en écrivant à la fois à [email protected] et à [email protected]. L’obligation est immédiate, et aucun document de RapidCents ne fixe de limite extérieure en heures. Signalez tôt : un signalement rapide préserve vos options, un signalement tardif les réduit.

Un identifiant compromis se signale au même titre que des données de carte compromises. Si une clé secrète, un secret de signature de webhook ou un identifiant du tableau de bord a été exposé — dans un dépôt, un paquet, un journal, une capture d’écran ou les systèmes d’un tiers —, faites-en d’abord la rotation, signalez-le ensuite, puis enquêtez.

Dans les premières heures, le confinement importe davantage que la propreté :

• Préservez les preuves. Ne réinstallez pas, n’effacez pas et ne reconstruisez pas les systèmes touchés, et ne supprimez pas les journaux. L’article D.2 (au point 2.3) exige que le Commerçant n’altère ni ne détruise les dossiers connexes et qu’il tienne une documentation complète et exacte de toute modification qui y est apportée; une enquête judiciaire a besoin précisément de ce qu’une reconstruction propre détruit.
• Confinez plutôt que d’effacer : retirez du réseau le système touché, faites la rotation des identifiants et des clés API, et révoquez les sessions actives.
• N’envoyez pas de numéros de carte, ni de fichiers qui en contiennent, par courriel ou par clavardage pendant l’examen.
• Attendez-vous à ce que RapidCents puisse mandater un enquêteur judiciaire agréé par une Association, et collaborez pleinement avec lui. L’article D.2 (au point 2.3) exige cette collaboration, oblige le Commerçant à communiquer les éléments de l’enquête, y compris les rapports d’expertise et les audits de systèmes, permet à RapidCents et à ses fournisseurs de partager ces éléments avec les Associations et d’effectuer, sur avis, des analyses électroniques à distance des systèmes du Commerçant, et rend le Commerçant responsable des coûts liés à l’enquête.
• Tenez compte de vos propres obligations distinctes. La législation sur la protection des renseignements personnels peut vous obliger à déclarer une atteinte aux mesures de sécurité à un organisme de réglementation et aux personnes touchées, selon son propre échéancier — au Canada en vertu de la LPRPDE, de la Loi 25 du Québec ou des lois albertaine et britanno-colombienne sur la protection des renseignements personnels, et aux États-Unis en vertu des lois d’État sur la notification des atteintes et sur la vie privée qui vous sont applicables. Ces obligations s’exécutent parallèlement à l’avis donné à RapidCents, et non à sa place.

Une vulnérabilité découverte dans un produit RapidCents est autre chose qu’une compromission de votre propre environnement, et elle emprunte sa propre voie : signalez-la par le processus décrit à /legal/vulnerability-disclosure, et faites-le avant toute divulgation ailleurs. Au cours de vos tests, n’utilisez pas de données de titulaires réelles, ni le compte d’un tiers, ni les données d’un autre commerçant, et n’employez pas de techniques qui dégradent le service pour autrui. Le sandbox existe pour que ce type d’essai dispose d’un endroit sûr.

Lorsqu’un incident survenu du côté de RapidCents touche les données ou le compte d’un commerçant, RapidCents avise les commerçants concernés sans délai indu et précise ce qui est établi, ce qui ne l’est pas encore et ce que le commerçant devrait faire, et elle transmet aux organismes de réglementation, aux banques acquéreuses et aux réseaux de cartes les avis qu’exigent la loi et les règles des réseaux.

Section I — Dispositions générales

22. Support, modifications des présentes conditions et coordonnées

Transmettez l’identifiant de requête quand quelque chose casse : c’est la différence entre une simple consultation et un projet de recherche. Les présentes conditions peuvent être modifiées comme le reste de l’entente. Le droit de l’Ontario s’applique, et les différends sont soumis à l’arbitrage.

Le support pour développeurs est un canal vers des ingénieurs capables de retrouver un identifiant de requête. Ce qui fait avancer un billet, c’est un identifiant : l’identifiant de requête de l’appel en échec, l’environnement d’où il provient, les versions d’API et de SDK utilisées, le code d’erreur typé et un exemple concret opposant le comportement attendu au comportement observé. Un billet qui nomme trois identifiants de requête ayant renvoyé le même code en quinze minutes est une consultation; un billet signalant que les refus ont augmenté est un projet de recherche. Journalisez l’identifiant de requête avec votre propre enregistrement de transaction, car il n’existe que sur la réponse que vous jetteriez autrement. Les identifiants de requête sont cloisonnés par environnement : précisez donc de quel environnement provient le vôtre. Les engagements de réponse sont échelonnés selon la gravité, les incidents en production étant sur l’horloge la plus courte; les paliers applicables à votre compte sont confirmés par votre personne-ressource de compte plutôt qu’énoncés ici.

Consultez la page d’état du système avant de signaler un symptôme généralisé. Lorsqu’un composant est déjà déclaré dégradé, un billet supplémentaire ajoute de la file d’attente plutôt que de l’information.

Les présentes conditions pour les développeurs peuvent être modifiées de la même façon que le reste de l’entente de services. L’article F.2 prévoit que RapidCents peut modifier l’entente en publiant une version révisée sur son site Web ou en donnant un avis par un autre moyen, que la version révisée prend effet dès sa publication ou selon ce qu’indique l’avis, et que la poursuite de l’utilisation des Services après cette date en constitue l’acceptation. Les changements importants aux modalités de paiement s’accompagnent des droits distincts de préavis et d’annulation énoncés à la Section A. Si vous n’acceptez pas une modification, votre recours est de résilier et de cesser d’utiliser les Services — et, comme le consigne l’article 11, cela n’entraîne aucuns frais d’annulation ni frais de résiliation anticipée.

Les avis à RapidCents prévus par l’entente de services doivent être donnés par écrit, par courriel à [email protected] ou par la poste, avec accusé de réception, à RapidCents Inc., à l’attention du service juridique, 515 Consumers Road, unité 210, North York (Ontario) M2J 4Z2, Canada, comme le prévoit l’article F.3. Les avis au Commerçant sont donnés au moyen du tableau de bord RapidCents, par courriel à l’adresse inscrite au compte ou par la poste. Les questions générales sur les Services s’adressent à [email protected] ou au +1-844-957-2743; aux États-Unis, au 43300 Southern Walk Plaza, #166, Ashburn (Virginie) 20148, ou au +1-202-902-6226. Une compromission soupçonnée se signale aux adresses de l’article 21 et non au support général.

L’article E.7 de l’entente de services régit le droit applicable et le mode de règlement des différends : les lois de la province d’Ontario et les lois fédérales du Canada qui y sont applicables, tout différend étant tranché par arbitrage devant un arbitre unique à Toronto (Ontario), sous l’administration de l’Institut d’arbitrage et de médiation du Canada selon ses règles applicables, chaque partie demeurant libre de demander à un tribunal des mesures provisoires à l’appui de cet arbitrage. Cet article s’applique aux présentes conditions, et l’article H.10 prévoit que les procédures sont intentées à titre individuel.

Droit applicable

Les lois de la province d’Ontario et les lois fédérales du Canada qui y sont applicables, comme le prévoit l’article E.7 de l’entente de services RapidCents. Les différends sont tranchés par arbitrage devant un arbitre unique à Toronto (Ontario), sous l’administration de l’Institut d’arbitrage et de médiation du Canada.