Quand une facture échoue toutes ses relances de paiements, l'abonnement associé peut être annulé ou marqué comme impayé, selon l'action d'état d'abonnement que vous choisissez dans vos paramètres. Ce comportement peut être affecté par des calendriers de relances plus longs.
Les longs calendriers de relances qui s'étendent au-delà de la période de facturation d'un abonnement peuvent causer le chevauchement des calendriers de relances de multiples factures. Dans le cas rare où une facture échoue toutes les relances, mais que la facture la plus récente faisant partie du même abonnement est payée avec succès, l'abonnement est laissé tel quel et n'est pas annulé ou marqué comme impayé.
Prenez par exemple un abonnement qui a une période de facturation d'un mois, avec un calendrier des relances de deux mois. Puis supposons que la séquence d'événements suivante se produise :
1er janvier : Une facture in_1 est émise et le paiement échoue
Du 2 au 30 janvier : Certaines relances sont tentées et échouent jusqu'à ce qu'il ne reste qu'une seule relance pour in_1
1er février : Une facture in_2 est émise et le paiement est réussi
10 février : Il y a une dernière tentative de relance pour in_1 et elle échoue
Dans le cas ci-dessus, le calendrier des relances de in_1 chevauche le calendrier des relances de in_2, d'où la possibilité que la facture in_2 reçoive un paiement avant que toutes les relances pour in_1 ne se produisent. Les relances de in_1 sont encore susceptibles d'échouer, et dans le présent cas, elles échouent toutes. Quand cela se produit, l'état de l'abonnement ne change pas, en raison du décalage de paiement réussi. En gros, si le paramètre d'état de l'abonnement est réglé à « annuler l'abonnement », alors l'abonnement n'est pas annulé. Si le paramètre est réglé à « marquer l'abonnement comme non payé », alors l'abonnement n'est pas marqué comme non payé.
Comme mentionné ci-haut, ce qui importe, c'est l'état payé de la dernière facture. Prenez par exemple un abonnement qui a une période de facturation d'une semaine, avec un calendrier des relances d'un mois. La séquence d'événements suivante se produit :
1er janvier : Une facture in_1 est émise et le paiement échoue
2 janvier : Certaines relances sont tentées et échouent jusqu'à ce qu'il ne reste qu'une seule relance pour in_1
7 janvier : Une facture in_2 est émise et le paiement est réussi
14 janvier : Une facture in_3 est émise et le paiement échoue
15 janvier : Il y a une dernière tentative de relance pour in_1 et elle échoue
Dans ce cas, le 15 janvier, in_1 échoue pour la dernière fois et l'état de l'abonnement sera modifié. L'état de in_2 n'est pas important dans ce cas, parce que la dernière facture est in_3 et in_3 n'a pas été payée. En gros, si le paramètre d'état de l'abonnement est réglé à « annuler l'abonnement », alors l'abonnement est annulé en date du 15 janvier. Si le paramètre est réglé à « marquer l'abonnement comme non payé », alors l'abonnement est marqué comme non payé en date du 15 janvier.
Pour éviter que des relances ne se produisent après la finalisation de la facture suivante, la fenêtre de relance peut être fixée à une valeur inférieure ou égale à l'intervalle de facturation. Par exemple, pour les abonnements mensuels, une fenêtre de relance <= 1 mois évitera un chevauchement potentiel.