Tout autre prestataire de paiement, via la Payments API.

01Ce que Tally enregistre

• Une vente de tout prestataire dont votre serveur a connaissance, comme Gumroad, FastSpring, Dodo Payments, Creem, PayPal ou votre propre facturation, envoyée avec son montant dans l’unité principale de la devise, la devise et un transaction_id.
• Les renouvellements : renewal à true, avec un subscription_id ou un customer_id, suit le premier paiement de l’abonnement et garde sa source.
• Les remboursements : refunded à true reprend le paiement désigné par son transaction_id, à hauteur du montant envoyé ; chaque remboursement partiel prend son propre refund_id.
• La taxe, si vous l’envoyez, est déduite du montant ; le reste est converti en cents US au taux de la Banque centrale européenne du jour du paiement.
• Un transaction_id déjà enregistré pour le site est un doublon : un paiement envoyé deux fois ne compte qu’une fois.
• Un timestamp date le paiement : un paiement encaissé plus tôt compte à son propre jour.

02Comment une vente retrouve sa visite

• Identifiant du visiteurEnvoyez le cookie _tally_vid de l’acheteur en tally_visitor_id (datafast_visitor_id et visitor_id fonctionnent aussi) et le paiement se lie à ce visiteur. Confiance élevée.
• E-mailEnvoyez email ou customer_email : l’adresse est hachée aussitôt, pour correspondre à un appel tally('identify') sur votre site. Confiance moyenne. Un nom est accepté mais jamais stocké.
• Renouvellements et remboursementsUn renouvellement reprend le lien du premier paiement de son abonnement ; un remboursement, celui du paiement qu’il annule.

03Ce qu’il ne peut pas lire

04Envoyer des paiements

1. Sur la page Setup de votre site, créez une clé API et cochez Record payments. Une clé sans cette option ne fait que lire, et un envoi avec elle est refusé avec un 403.
2. Là où votre serveur enregistre un paiement, envoyez-le à /api/v1/payments avec la clé en jeton Bearer : amount, currency, transaction_id, et l’identifiant de visiteur ou l’e-mail de l’acheteur.
3. Lisez l’identifiant de visiteur dans le cookie _tally_vid de la requête qui finalise l’achat, ou transmettez-le de la page à votre processus de paiement.
4. La réponse indique si le paiement a été enregistré ou l’était déjà ; un corps qui n’est pas un paiement reçoit un 400 avec une phrase qui explique pourquoi.
5. Les paiements envoyés apparaissent sur la page Integrations sous le nom Payments API, et chacun est lié à sa visite en quelques secondes.

Un paiement envoyé avec cURL

curl https://tallybyoutpost.com/api/v1/payments \
  -H "Authorization: Bearer $TALLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"amount": 29.99, "currency": "USD", "transaction_id": "order_1042",
       "tally_visitor_id": "the _tally_vid cookie", "email": "buyer@example.com"}'

05Questions fréquentes

• Je quitte DataFast. Dois-je modifier mon code de paiement ?

  Seulement l’adresse et la clé. Le chemin et le corps de DataFast fonctionnent tels quels, amount, currency, transaction_id, datafast_visitor_id, email, renewal et refunded compris, et son paramètre websiteId est ignoré, puisque la clé désigne le site.

• Depuis quels prestataires puis-je envoyer des paiements ?

  Tout paiement que votre serveur enregistre : Gumroad, FastSpring, Dodo Payments, Creem, PayPal, les factures que votre propre facturation marque payées. Si votre serveur apprend l’existence du paiement, par un webhook ou par son propre processus de paiement, il peut l’envoyer.

• Puis-je envoyer des paiements antérieurs à mes débuts ?

  Oui. Envoyez chacun avec son timestamp et il compte à son propre jour ; un timestamp dans le futur est refusé. Rien n’arrive tout seul : l’historique, c’est ce que vous envoyez.

• Et si mon serveur envoie deux fois le même paiement ?

  Le second envoi reçoit une réponse de doublon et rien de nouveau n’est enregistré, car transaction_id identifie le paiement au sein du site. Réessayer après un délai d’expiration est sans risque.