Nouvelles fonctionnalités
1. Reports
Un nouvel onglet Reports sous Settings rassemble les rapports de solde, de frais et de rapprochement au même endroit. Suivre les mouvements de fonds Deux vues toujours à jour, décrites ainsi : « Comprenez comment l’activité, les frais et les versements affectent votre solde » :- Résumé du solde et des versements — solde initial, répartition de l’activité et détail de chaque versement dans une seule vue
- Tous les frais — une ventilation détaillée de chaque frais facturé au cours de la période
2. Période de grâce des abonnements
Un abonnement dont le renouvellement échoue peut désormais continuer à fonctionner pendant une période configurable au lieu d’être immédiatement mis en attente. Activez Subscription Grace Period sous Settings → Subscriptions et définissez le Nombre de jours de la période de grâce — de 1 à 30 jours. Les périodes de grâce sont désactivées par défaut. Pendant cette période, l’abonnement prend le statutpast_due : l’accès est conservé et l’utilisation continue de s’accumuler. Ainsi, un client dont la carte a simplement expiré n’est pas interrompu pendant qu’il règle le problème. Un nouveau webhook subscription.past_due est déclenché lorsque la période commence.
Choisissez ce qui se passe si la période se termine sans paiement avec Statut de l’abonnement après la période de grâce — soit On Hold, comme aujourd’hui, soit Annuler l’abonnement.
3. Liste de blocage des clients
Bloquez un client qui ne doit plus pouvoir acheter chez vous, à l’aide de son identifiant client ou de son adresse e-mail. Le blocage annule les abonnements actifs du client, empêche les futures sessions de checkout et les paiements directs, et rend son Customer Portal accessible en lecture seule. Comme les entrées correspondent à l’adresse e-mail, un client qui se réinscrit avec la même adresse est toujours détecté. Les entrées de la liste de blocage peuvent contenir des notes, afin que vous puissiez indiquer pourquoi une personne a été bloquée.
4. Nouvelle tentative de paiement manuelle
Relancez vous-même un renouvellement d’abonnement échoué au lieu d’attendre le calendrier automatique, en utilisant Réessayer le paiement manuellement sur la page de détails du paiement. Le débit est effectué sur le moyen de paiement déjà enregistré pour l’abonnement : le client n’a rien à faire et cette action ne consomme pas de tentative du calendrier automatique. Chaque facture de renouvellement autorise jusqu’à trois nouvelles tentatives manuelles, avec un délai entre chacune — une heure avant la deuxième et trois heures avant la troisième — afin que les refus répétés ne nuisent pas à votre taux d’autorisation.
5. Journal d’activité sur les paiements
Chaque page de détails du paiement comporte désormais un journal d’activité — « Un historique des actions effectuées sur cette transaction au cours des 90 derniers jours ». Le journal retrace l’ensemble du cycle de vie dans l’ordre, de Paiement initié à Paiement réussi, en passant par l’authentification et la capture, puis couvre également les remboursements et les litiges. Un paiement contesté se lit ainsi comme une seule histoire plutôt que comme plusieurs enregistrements déconnectés.
6. Un formulaire de remise repensé
La création d’un code de remise affiche désormais ce que vous construisez au fur et à mesure. Un panneau latéral permet de basculer entre Résumé, une présentation de la remise en langage clair, et Aperçu, qui affiche la remise telle qu’un client la verrait lors du checkout. Options de devise vous permet de définir le montant de la remise pour chaque devise dans laquelle vous vendez. Éligibilité et restrictions regroupe les règles relatives aux produits et aux clients. Les limites d’utilisation, la limite du cycle de facturation et Exiger une valeur minimale de commande — un montant minimal du panier appliqué par devise — se trouvent désormais sous Avancé.
7. Contrôles d’annulation distincts
L’annulation en libre-service était auparavant contrôlée par un seul bouton. Elle comprend désormais deux paramètres indépendants sous Settings → Subscriptions :- Autoriser l’annulation immédiate — « Permettre aux clients de mettre fin à leur abonnement et de perdre immédiatement l’accès. »
- Autoriser l’annulation à la prochaine date de facturation — « Permettre aux clients d’annuler à la fin de la période déjà payée. »
8. Modifications de forfait payées sur une page de checkout
Activez Collecter les paiements de modification de forfait par Payment Link sous Settings → Subscriptions : un client qui passe à un forfait supérieur dans le Customer Portal paie la modification sur une page de checkout hébergée plutôt qu’avec le mandat enregistré. Le bouton de confirmation affiche le montant dû. Lorsque le checkout s’ouvre, le client voit le message suivant : « Effectuez votre paiement dans le nouvel onglet. Votre forfait actuel reste actif jusqu’à la réussite du paiement. » L’abonnement conserve son ancien forfait jusqu’à la réussite du paiement, et un paiement refusé peut être réessayé avec le même lien. Le Customer Portal sait également désormais si vous autorisez l’annulation d’une modification de forfait programmée. Il affiche ou masque donc ce contrôle au lieu de proposer une action qui serait refusée.
9. Budget de nouvelles tentatives KYC
Une vérification d’identité échouée indique désormais pourquoi elle a échoué et combien de tentatives il vous reste, au lieu de simplement signaler un échec. Chaque utilisateur dispose de trois tentatives, et l’avis indique « Tentatives restantes : 2/3 » avec la raison réelle fournie par le prestataire de vérification. Le bouton devient Réessayer tant qu’il reste des tentatives. Si les trois tentatives ont été utilisées, l’avis explique que le support peut rouvrir la vérification. En savoir plus : Vérification du compte10. Checkout en géorgien
Le checkout est désormais disponible en géorgien, ce qui porte le total à 22 langues. Le géorgien est détecté à partir du navigateur du client comme toutes les autres langues prises en charge, ou vous pouvez l’imposer avec le paramètreforce_language.
En savoir plus : Langues prises en charge
11. Sans carte pour un prix de $0
Un abonnement peut désormais commencer sans moyen de paiement lorsqu’aucun montant n’est dû aujourd’hui. Activez la case Sans carte pour un prix de $0 dans la section de tarification du produit, à côté de Période d’essai (jours) et Remise par défaut (%). Deux situations peuvent entraîner l’absence de montant dû aujourd’hui, et une seule case couvre les deux :- Un essai gratuit — une période d’essai sans montant d’essai, de sorte que le premier débit est
0pendant l’essai. - Un prix récurrent de $0 — soit le prix est directement
0, soit une remise le ramène à ce montant, qu’il s’agisse de la Remise par défaut (%) du produit ou de codes de remise cumulés jusqu’à une remise de 100 % lors du checkout.
payment_method_required: false. Un e-mail de rappel est ensuite envoyé avant le début de la facturation réelle — le délai est défini par Rappel du moyen de paiement sous Settings → Subscriptions, entre 1 et 30 jours, avec une valeur par défaut de 3 jours. Si la carte n’est jamais ajoutée, l’abonnement passe à on_hold lorsque le premier débit réel devient exigible, et l’ajout d’un moyen de paiement le réactive. Deux e-mails clients couvrent ce cas, tous deux activés par défaut : Rappel d’ajout d’un moyen de paiement et Abonnement mis en attente, aucun moyen de paiement.
Via l’API, la case unique correspond à deux champs de prix indépendants, trial_payment_method_optional et zero_amount_payment_method_optional. Vous pouvez donc activer chaque cas séparément si vous gérez directement les produits.
12. Tax ID obligatoire au checkout
Les sessions de checkout acceptent désormais un nouvel indicateur de fonctionnalitérequire_tax_id, destiné aux entreprises qui vendent uniquement à des entreprises enregistrées. Sa valeur par défaut est false : rien ne change tant que vous ne l’activez pas.
Lorsque l’indicateur est activé, Acheter en tant qu’entreprise est présélectionné et verrouillé sur la page de checkout, Nom de l’entreprise et Numéro de Tax ID deviennent obligatoires, et Continuer vers le paiement reste grisé tant que l’un des champs est vide ou que le Tax ID est rejeté. La validation du Tax ID reste en mode fail-open : une panne de recherche ne bloque donc jamais complètement le client.
allow_tax_id doit également être true, sinon la requête est rejetée avec une 400. De plus, une session créée avec confirm: true doit contenir une tax_id, car elle ignore entièrement la page de checkout.
L’exigence est appliquée sur la page de checkout et non côté serveur : une confirmation envoyée directement à l’API peut toujours omettre tax_id. Considérez donc cet indicateur comme un contrôle de l’expérience de checkout, et non comme une garantie.
En savoir plus : Rendre le Tax ID obligatoire