Paramètres du Checkout

Ouvrez Checkout dans la Tapaya Platform. La page affiche vos Organization defaults (valeurs par défaut de l’organisation) et liste les Checkout merchants (commerçants Checkout) de votre organisation. Sélectionnez un commerçant pour ouvrir sa page de paramètres. Configurez un commerçant ici avant d’intégrer le Hosted Checkout ou l’Embedded Checkout.

Ce dont chaque intégration a besoin

Parcourez de haut en bas les paramètres utilisés par votre intégration :

Le mode plateforme utilise la Secret key de l’organisation, disponible sur la page API Keys, au lieu d’une clé checkout de commerçant.

Effectuer l’onboarding d’un commerçant pour le Checkout

Effectuez l’onboarding du commerçant en sélectionnant les paiements en ligne, ou les paiements en ligne et en magasin. L’onboarding en ligne recueille le site web de la boutique et les informations sur l’activité en ligne. Un commerçant qui utilise uniquement le Checkout n’a pas besoin de terminaux.

Les commerçants qui demandent les paiements en ligne apparaissent automatiquement dans Checkout merchants, y compris ceux en attente d’approbation. La création d’une fiche commerçant ou d’une clé checkout ne vaut pas approbation des paiements en ligne. Une approbation pour les paiements en magasin ne suffit pas à elle seule à activer le Checkout.

Le tableau indique l’état de préparation du commerçant :

Copiez le Merchant token pour le mode plateforme, ou sélectionnez Settings pour configurer le commerçant. Seuls les administrateurs de l’organisation peuvent modifier les paramètres du Checkout.

Créer des clés checkout de commerçant

Dans les Settings d’un commerçant, Merchant checkout keys liste les clés destinées au propre backend de ce commerçant. Saisissez un nom de clé et sélectionnez Create merchant key. Les clés commencent par tapaya_test_ dans la sandbox et par tapaya_live_ en production.

Copiez immédiatement le secret. La plateforme ne l’affiche qu’une seule fois et n’en stocke que le hash. Une clé ne fonctionne que pour son commerçant. Révoquez une clé pour bloquer les requêtes qui l’utilisent ; les autres clés de commerçant et les clés de votre organisation restent valides. Voir Authentification du Checkout.

Configurer les destinations de retour

Le Hosted Checkout renvoie le client vers votre boutique après le paiement ou lorsqu’il quitte la page. Les paiements intégrés n’utilisent pas d’URL de redirection.

Les destinations de retour sont rattachées à l’identifiant qui crée la session :

Les deux ne sont jamais combinés, et aucun ne sert de solution de repli pour l’autre. Une session en mode plateforme ne peut revenir que vers les sites autorisés de l’organisation, et une session créée avec une clé de commerçant uniquement vers ceux du commerçant. Si une session omet successUrl ou cancelUrl et que son identifiant n’a pas de valeur par défaut, la création est refusée.

Dans la section correspondant à votre identifiant, ajoutez votre boutique à Allowed websites, puis définissez la Default success URL et la Default cancel URL. Une boutique pourrait utiliser :

• Site autorisé : https://shop.example.
• URL de succès : https://shop.example/checkout/return.
• URL d’annulation : https://shop.example/checkout/cancel.

Un site autorisé est une origine : schéma, hôte et port facultatif, sans chemin, requête ni fragment. La correspondance porte sur l’origine exacte, port compris. Les caractères génériques et les suffixes de nom d’hôte ne correspondent pas. Utilisez HTTPS pour les boutiques déployées ; HTTP est accepté pour les hôtes locaux.

Une session peut remplacer les valeurs par défaut avec successUrl ou cancelUrl lorsque vous la créez. Les remplacements doivent tout de même correspondre à un site autorisé du même identifiant. Une plateforme qui sert des commerçants sur des chemins ou des sous-domaines différents transmet généralement les deux URL dans chaque session.

Le statut Ready décrit l’approbation du commerçant et la configuration de la passerelle. Il ne confirme pas la configuration de vos URL de retour. Les paiements intégrés n’ont pas besoin d’URL de retour. Les sessions hébergées ont besoin de valeurs par défaut ou d’URL explicitement autorisées pour l’identifiant qu’elles utilisent.

Une visite de l’une ou l’autre URL de retour ne prouve pas le résultat du paiement. Récupérez la session depuis votre serveur avant de marquer une commande comme payée.

Définir le nom affiché aux clients

Le Customer-facing name s’affiche lors du paiement et dans les portefeuilles de paiement. Laissez-le vide pour utiliser la raison sociale du commerçant. Il ne modifie pas le nom figurant sur le relevé bancaire.

Portefeuilles et apparence

Chaque commerçant sélectionne Use organization wallets and appearance ou définit ses propres réglages. Ce commutateur n’a pas d’effet sur les destinations de retour, qui suivent l’identifiant comme décrit ci-dessus. Le nom du commerçant et les clés checkout restent toujours propres au commerçant.

Les Organization defaults de portefeuilles et d’apparence s’appliquent à chaque commerçant qui les utilise, et les modifications atteignent ces commerçants immédiatement :

• Apple Pay et Google Pay. Les cartes sont toujours activées.
• Hide powered by Tapaya.
• Checkout color, une couleur hexadécimale à six chiffres, par exemple #1380A5.
• Checkout logo, une image PNG ou WebP de 5 Mo maximum. Les téléversements et suppressions de logo sont enregistrés immédiatement.

Si aucune valeur par défaut n’a été enregistrée, les portefeuilles sont activés, et la couleur et le logo proviennent de l’image de marque de votre organisation.

Un bouton de portefeuille dépend aussi de l’appareil et du navigateur du client. Activer un portefeuille ne garantit pas qu’il s’affiche partout. Google Pay en production nécessite un Google Pay merchant ID configuré.

Le Hosted Checkout utilise tous ces paramètres. L’Embedded Checkout utilise les paramètres de portefeuille et la couleur Checkout effectivement appliquée comme accent de focus des champs de carte (colorFocus). Les variables que votre page transmet dans appearance.variables la remplacent. Activez les boutons de portefeuille intégrés dans votre page comme décrit dans Embedded Checkout.

Utilisez Checkout preview pour vérifier l’image de marque et les moyens de paiement en mise en page ordinateur et mobile.

Enregistrer les domaines de boutique Apple Pay

Pour Apple Pay dans l’Embedded Checkout, enregistrez chaque nom d’hôte de boutique sur lequel le portefeuille s’affiche. Le Hosted Checkout s’exécute sur le domaine de Tapaya. Les Allowed websites des redirections hébergées n’enregistrent pas de domaine pour Apple Pay.

1. Ouvrez les Settings du commerçant, puis Apple Pay et Shop domains.
2. Sélectionnez Add domain et téléchargez le fichier de vérification.
3. Servez le fichier sans modification, sans extension, à l’adresse https://shop.example/.well-known/apple-developer-merchantid-domain-association. Utilisez un certificat HTTPS valide et servez le fichier directement, sans redirection.
4. Saisissez le nom d’hôte, par exemple shop.example, et sélectionnez Verify and add. Enregistrez www.shop.example séparément si vos clients l’utilisent également.
5. Attendez que le domaine affiche Active, puis activez Apple Pay. Utilisez Check now pour diagnostiquer un domaine en échec.

Laissez le fichier de vérification disponible après l’enregistrement. Chaque commerçant a besoin de son propre enregistrement de domaine, même lorsque les portefeuilles et l’apparence proviennent des valeurs par défaut de l’organisation. Un commerçant doit disposer d’une passerelle de paiement configurée avant qu’un domaine puisse être enregistré.

Il manque quelque chose sur cette page ?Demandez une fonctionnalité. Nous joignons cette page pour que l’équipe ait le contexte.