Documentation

1Que sont les liens de paiement ?

Les liens de paiement permettent d’encaisser des paiements lorsqu’aucun backend / boutique n’est disponible côté marchand pour traiter les paiements. Les liens de paiement vous permettent donc, en tant que marchand, d’encaisser des paiements sans aucune programmation côté serveur. Le paiement est créé en invoquant une URL avec des paramètres spécifiques. Les paramètres sont des paramètres HTTP GET ou POST classiques. Par exemple : l’adresse de facturation sera reprise des paramètres de la requête HTTP envoyée à l’URL.

Les liens de paiement peuvent être utilisés pour un large éventail de cas d’utilisation. La liste suivante, non exhaustive, présente quelques cas d’utilisation :

  • Si vous souhaitez vendre un produit simple sur votre site web sans implémenter de backend ni utiliser un panier pour la gestion des produits ou des stocks, vous pouvez utiliser ces liens de paiement. Cela peut être une très bonne solution pour traiter des ventes flash pour lesquelles vous ne voulez pas créer de boutique, des sites web à contenu statique, etc. Si vous utilisez des liens de paiement, vous pouvez placer un simple formulaire HTML sur votre site web, pointant vers notre plateforme qui traite le paiement et vérifie les données de facturation. De plus, vous pouvez définir une limite d’achats pour ce produit particulier. Le produit et tous les frais de livraison peuvent être prédéfinis dans le lien de paiement. Tous les e-mails de confirmation peuvent être envoyés par notre système.

  • Si vous souhaitez collecter des dons sur votre site web, vous pouvez placer un simple formulaire sur votre site web, pointant vers notre plateforme. Le montant peut être défini dynamiquement dans le formulaire hébergé sur votre site web. Vous pouvez collecter les coordonnées de votre choix et enregistrer ces données dans notre système si vous le souhaitez. Tous les e-mails seront envoyés depuis notre système. Vous pouvez les adapter et les personnaliser à votre guise.

Note
Veuillez utiliser les Charge Flows si vous souhaitez encaisser des paiements par e-mail sans devoir vous occuper de l’envoi de plusieurs e-mails ni de la gestion des différents niveaux de relance lorsque votre client ne clique pas sur le lien.

2Comment puis-je configurer un lien de paiement ?

Allez dans Space > Liens de paiement > Créer et fournissez les données requises. Si vous devez configurer de nombreux liens de paiement de manière automatisée, vous pouvez envisager d’utiliser le service web des liens de paiement.

Un nom est requis pour créer le lien de paiement, car il est affiché dans l’interface d’administration. Tous les autres détails supplémentaires sont facultatifs. Toutefois, si vous ne fournissez pas ces informations, elles peuvent être modifiées par l’utilisateur. Ainsi, si vous souhaitez encaisser les paiements uniquement dans une devise spécifique, vous devez fournir cette information. Sinon, nous prendrons la devise que vous avez fournie dans la requête envoyée à l’URL. Il en va de même pour les postes : s’ils ne sont pas fournis, nous prenons ceux fournis dans la requête.

Note
La requête peut être modifiée par l’acheteur et le montant débité peut différer de ce que vous aviez prévu.

3Comment puis-je utiliser un lien de paiement ? Comment puis-je l’intégrer dans mon site web ?

Une fois que vous avez créé un lien de paiement, vous pouvez prendre l’URL fournie et commencer à l’invoquer. Selon la façon dont vous avez configuré le lien de paiement, vous devez fournir des paramètres supplémentaires dans la requête qui invoque l’URL du lien de paiement.

Si vous souhaitez utiliser un formulaire sur votre site web pour l’invoquer, vous pouvez procéder ainsi :

<form action="<< put here payment link url >>" method="POST">

	<input type="text" name="billingAddress[givenName]" placeholder="Given Name" />
	<input type="text" name="billingAddress[familyName]" placeholder="Family Name" />
	<input type="text" name="billingAddress[street]" placeholder="Street" />
	<input type="text" name="billingAddress[postcode]" placeholder="Postcode" />
	<input type="text" name="billingAddress[city]" placeholder="City Name" />
	<input type="text" name="billingAddress[country]" placeholder="Country Code" />

	<input type="hidden" name="lineItems[0][uniqueId]" value="test" />
	<input type="hidden" name="lineItems[0][sku]" value="test" />
	<input type="hidden" name="lineItems[0][name]" value="Test" />
	<input type="hidden" name="lineItems[0][amountIncludingTax]" value="10.87" />
	<input type="hidden" name="lineItems[0][type]" value="PRODUCT" />
	<input type="hidden" name="lineItems[0][quantity]" value="1" />

	<input type="hidden" name="metaData[additionalData]" value="Further data you want to store along the transaction." />

	<input type="hidden" name="currency" value="CHF" />

	<!-- Further parameters as you need. -->

	<input type="submit" value="Pay" />
</form>

Nous recommandons d’utiliser la method POST et non GET, car les paramètres du formulaire seront sinon ajoutés à l’URL. La longueur de l’URL ne peut pas dépasser 2000 caractères, car certains navigateurs ne le supportent pas. En utilisant POST, vous éviterez ce genre de problèmes.

4Quels paramètres puis-je envoyer ?

En substance, vous pouvez envoyer tous les paramètres que vous pouvez envoyer via l’API des services web lorsque vous créez une transaction. Concrètement, le JSON doit être transposé dans un format pouvant être produit par des formulaires HTML classiques. Les données doivent être transmises en encodage UTF-8. Nous décrivons les paramètres et leur format ci-dessous :

4.1Adresse de facturation et adresse de livraison

L’adresse de facturation et l’adresse de livraison ont les mêmes champs. Lorsqu’une adresse est fournie, nous vérifions si un ensemble minimal de champs permettant une livraison est fourni. Les paramètres requis et leur format dépendent du pays. Vous trouverez ci-dessous une liste de tous les champs requis pour une adresse :

  • country : le code pays ISO 3166-1 à deux lettres détermine comment l’adresse est validée.

  • givenName : contient le prénom du client.

  • familyName : contient le nom de famille du client.

  • street : le nom de la rue, y compris le numéro de rue, etc. de l’adresse.

  • postCode : le code postal de l’adresse est normalement requis.

  • city : le nom de la ville est normalement également requis.

Veuillez également consulter la définition du modèle d’adresse pour plus d’informations sur les autres champs disponibles et la façon dont nous les validons.

Pour simplifier la validation d’adresse, vous pouvez intégrer notre bibliothèque JavaScript, qui permet de valider l’adresse directement sur votre site web. Vous pouvez consulter la documentation sur la validation d’adresse. La validation d’adresse offre également la possibilité de récupérer les régions et les pays disponibles. Cela permet de proposer à l’acheteur un champ de sélection dans lequel les options autorisées peuvent être choisies. De plus, nous indiquons dans la liste des pays quels champs sont requis selon le pays. Cela permet de mettre à jour le formulaire pour marquer comme requis les champs dépendant du pays.

Les champs mentionnés doivent être utilisés avec le préfixe billingAddress ou shippingAddress.

4.2Détails du client

Vous pouvez fournir un paramètre customerEmailAddress contenant l’adresse e-mail du client. Nous enverrons tous les e-mails à cette adresse. Tout autre détail concernant le client doit être fourni dans l’adresse de livraison ou de facturation.

Le customerId ne peut pas être fourni : comme il est utilisé pour le traitement des paiements en un clic, nous ignorons ce paramètre de requête.

4.3Postes

Lorsque vous ne fournissez pas les postes dans le lien de paiement, vous devez les fournir via la requête. Un poste requiert au moins les propriétés suivantes :

  • amountIncludingTax : le montant du poste, taxes comprises.

  • name : le nom du poste, affiché dans les documents et les e-mails.

  • quantity : la quantité du poste. Le prix unitaire est calculé en divisant amountIncludingTax par quantity.

  • type : le type du poste indique de quoi il s’agit. Types possibles : PRODUCT, SHIPPING, DISCOUNT ou FEE

  • uniqueId : l’identifiant unique identifie le poste au sein d’une même transaction.

Le poste peut avoir d’autres propriétés. La définition du modèle de poste fournit plus de détails sur les autres propriétés. Vous trouverez ci-dessous un exemple de poste :

<input type="hidden" name="lineItems[0][uniqueId]" value="t-shirt-123" />
<input type="hidden" name="lineItems[0][sku]" value="t-shirt-red-36" />
<input type="hidden" name="lineItems[0][name]" value="T-Shirt" />
<input type="hidden" name="lineItems[0][amountIncludingTax]" value="40.85" />
<input type="hidden" name="lineItems[0][taxes][0][title]" value="MwSt." />
<input type="hidden" name="lineItems[0][taxes][0][rate]" value="19" />
<input type="hidden" name="lineItems[0][shippingRequired]" value="true" />
<input type="hidden" name="lineItems[0][attributes][color][label]" value="Color" />
<input type="hidden" name="lineItems[0][attributes][color][value]" value="Red" />
<input type="hidden" name="lineItems[0][attributes][size][label]" value="Size" />
<input type="hidden" name="lineItems[0][attributes][size][value]" value="36" />

Si vous souhaitez envoyer plusieurs postes, vous devez répéter les propriétés et augmenter l’index de un.

Il est important de comprendre que fournir les postes via la requête permet à l’acheteur de les modifier. Nous ne pouvons pas l’empêcher. Cela implique que chaque transaction doit être vérifiée afin de s’assurer que le montant n’a pas été modifié par l’acheteur.

4.4Devise

La devise peut être fournie dans le paramètre currency. Lorsqu’elle est déjà définie dans le lien de paiement, la currency envoyée dans la requête sera ignorée.

Lorsque le lien de paiement définit les postes et qu’ils ne figurent pas dans la requête, la devise doit être définie sur le lien de paiement.

4.5Page d’échec et page de succès

Lorsque la transaction a été autorisée ou qu’elle a échoué, l’utilisateur peut être redirigé vers une page dédiée. Si rien n’a été spécifié, l’utilisateur sera redirigé vers la page par défaut.

Le paramètre failedUrl définit l’URL vers laquelle l’utilisateur est redirigé lorsque le paiement échoue. Le paramètre successUrl définit l’URL vers laquelle l’utilisateur est redirigé lorsque le paiement a été autorisé avec succès.

Note
Veillez à utiliser une URL absolue et non une URL relative.

4.6Référence marchand

Pour fournir une référence marchand, vous pouvez utiliser le paramètre merchantReference. La référence marchand est affichée dans l’aperçu de la transaction. Elle peut également être utilisée pour rechercher une transaction particulière.

Il est important de comprendre que cette merchantReference peut être modifiée par l’acheteur ; vous devez donc tenir compte de ce fait dans les processus que vous mettez en place.

4.7Informations supplémentaires

Si vous devez enregistrer des données supplémentaires avec la transaction, vous pouvez le faire en utilisant le champ metaData. Il permet d’enregistrer des paires clé-valeur supplémentaires. Par exemple, si vous souhaitez enregistrer dans la clé comment un commentaire sur l’achat, vous pouvez le faire en passant un commentaire dans le paramètre metaData[comment]. Certaines limites s’appliquent aux métadonnées. Vous trouverez plus de détails dans la section métadonnées de l’API des services web.

4.8Contrôler la disponibilité par date et heure

La disponibilité du lien de paiement peut être contrôlée avec les paramètres availableFrom et availableUntil. Ces paramètres sont interprétés de la même manière que les options correspondantes du lien de paiement. Toutefois, s’ils sont fournis via le lien de paiement, l’acheteur peut les contourner. S’ils doivent être appliqués de manière à ce que l’acheteur ne puisse pas les manipuler, il est nécessaire d’utiliser les options correspondantes sur le lien de paiement lui-même.

Les dates acceptées pour availableFrom et availableUntil doivent être au format ISO 8601. Par exemple :

  • 2018-05-01

  • 2018-08-09T10:10:10

  • 2018-08-09T10:10:10+02:00

Si la date ne contient pas de fuseau horaire, le fuseau horaire UTC est utilisé. Notez que vous devrez peut-être encoder la date au format URL.

5Comment gérer la validation ?

Nous validons les données du formulaire. Cependant, nous devons signaler l’échec sur une page dédiée, ce qui n’est pas optimal pour l’expérience utilisateur. Nous recommandons d’utiliser la validation d’adresse pour valider l’adresse dans le navigateur avant d’envoyer le formulaire à l’URL du lien de paiement. La validation d’adresse offre également la possibilité de récupérer les pays et les régions.

Nous validons à nouveau les données côté serveur. Nous garantissons ainsi qu’aucune donnée corrompue n’est traitée.

6Puis-je ajouter des conditions générales à la page de paiement ?

Nous recommandons d’ajouter une case de confirmation des conditions générales au formulaire de votre site web. Toutefois, si vous voulez obliger l’utilisateur à accepter certaines conditions générales, vous pouvez utiliser l’add-on de la page de paiement pour les conditions générales, qui oblige l’utilisateur à accepter vos conditions.

7Pourquoi ne puis-je pas utiliser les paiements en un clic avec les liens de paiement ?

Les paiements en un clic permettent à l’acheteur d’enregistrer ses données de paiement. Pour les achats ultérieurs, l’acheteur n’a pas à saisir à nouveau ses données de paiement.

Comme nous n’authentifions pas le client, nous ne pouvons pas lui permettre de payer sans saisir de données de paiement. C’est pourquoi vous ne pouvez pas utiliser la fonction de paiement en un clic avec les liens de paiement. Si vous activez la fonction de paiement en un clic sur le mode de paiement, nous devons l’ignorer.