[#7239] CBsubs Stripe Dispute no feed back

in order to trigger autoactions email to warn the client in case of a dispute, I guess we can use the following or is there any special trigger ?

Believe that should work fine.

Also is it possible to manually simulate the Reversed state for old disputes ? via a trigger or a manual edition ?

No.

Hello

I come back on this post with a question regarding paying the dispute again.

Everything is working fine on CBSubs but we noticed that in case of a dispute the CB invoice/basket is marked as Reversed and there is the Pay Now button on the backend. But this button shows a page saying that it's impossible to pay this basket again.

So can you explain if it's still possible to pay this basket from the backend or frontend or not ? Does the customer have to reissue a new basket, thus we should have to issue a manual refund note for the old invoice number or can he pay the basket again with another gateway or another try on the same gateway (which would be the best) ?

Thanks in advance

A reversed basket can only be restored if the payment gateway tells it to restore. This means you need to win the dispute at Stripe. If you lost the dispute then they will need to renew/subscribe from frontend as normally and no you can't reuse that basket as that wouldn't make sense from a financial record keeping standpoint as that payment was recorded, but reversed like a refund.

I've never heard of a law that requires you to use invoice ids like you keep trying to do. Please site your source as it just doesn't make sense. There should be no reason for you to have to sequentially use invoices so strictly. Especially given that invoice has a payment record of being reversed.

This is french law : as soon as an invoice is created it cannot be suppressed and the following one has to have a number with a +1 increment (also for recurring payments as these are new invoices each time)

The only mean to "reimburse" or "reverse" the invoice is by a "refund note" with same rules for the numbers or to pay the initial invoice number.

As we have a lot of business companies as customers they perfectly know these rules and we have to find a proper way to address this.

see the law:
www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000022147026&cidTexte=LEGITEXT000006069569&dateTexte=20100430

and

French government : bofip.impots.gouv.fr/bofip/140-PGP/version/1?branch=2&language=2

90

Il en résulte que, pour chaque série distincte de factures, les assujettis peuvent utiliser un système de numérotation propre pour chaque série à condition :

- que la numérotation soit effectuée chronologiquement au fur et à mesure de l'émission des factures ;

- qu'elle soit continue ;

- et que le dispositif retenu au sein de l'entreprise garantisse que deux factures émises la même année ne puissent pas porter le même numéro. Il est conseillé à cet égard d’utiliser pour chaque série de factures un préfixe de numérotation distinct de façon à éviter toute possibilité de confusion.

I don't have a solution for you at this time beyond manually issuing the refund notes. We don't have a means of reusing a basket like what you're wanting to do. There's just no basket state for that. I'll review what it might take to implement an additional state for when a dispute is lost to allow the basket to be reused, but I don't believe the functionality for that to work right exists.

Additionally we've plans to implement frontend access to a users payment history, which could be renamed to Invoices using language overrides and we'll be keeping this in mind when implementing frontend payment history so it can potentially function as invoices (with same/similar invoice number functionality).

Additionally we've plans to implement frontend access to a users payment history, which could be renamed to Invoices using language overrides and we'll be keeping this in mind when implementing frontend payment history so it can potentially function as invoices (with same/similar invoice number functionality).

That would be a good start for recurring invoices also provided that you can sort the problem of the invoice number. For now every recurring payment has the same invoice/basket number. So I guess that a good solution would be to append the payment id to the basket/invoice number chosen for instance, or add the day of payment to the invoice number but this would not solve the legal requirement for increment of +1 only.

I know that's not easy but as of now, I must say that CBsubs is not compatible with french law if it's used for invoicing purposes. And even transferring information from CBsubs DB to an external invoicing system as we do now is rather difficult to do to keep things simple.

Am very looking forward to a new dev of CBsubs on this subject