#Serdar

1 messages ยท Page 1 of 1 (latest)

somber ravenBOT
foggy skiff
#

We want to handle webhooks of subscriptions, where our customers have the possiblity to choose between credit card and SEPA

#

And as you know, SEPA throws after a few days an event, that it actually is really paid

#

But we want, that our customers can directly use the premium functionalities which come with the subscription

#

So now we ask ourselves, on which webhook event we should react and how we can differentiate between them .. and also which event comes when the subscription is renewed (as example every month)

slate dawn
foggy skiff
#

Yes but the invoice.paid event comes at SEPA after 4-5 days or not?

#

And we want, that our customers can directly use the premium functionalities

slate dawn
#

I think it happens as soon as the debit is initiated, not when it succeeds

foggy skiff
#

You think? ๐Ÿ˜„ we need to be 100% sure about this

slate dawn
#

best to test it in test mode then!

foggy skiff
#

We did .. but that does not help

#

Here are some SEPA to test .. but it does only jump directly to paid or in 3 minutes

#

and the 3 minutes .. the invoice.paid comes after 3 minutes ..

#

So my question is now .. what happens if the SEPA is paid in 4-5 days ..

#

does the invoice.paid then also comes in 4-5 days?

slate dawn
#

can you share a link to an invoice.paid event from your tests?

#

evt_xxx ID

foggy skiff
#

evt_1MEA0QD1fTq5Z6HuRosPM9c5

slate dawn
#

looks like I'm wrong then and the invoice.paid happens when the debit succeeds, as that test shows!

foggy skiff
#

Alright, so again back to our start question

#

Yes but the invoice.paid event comes at SEPA after 4-5 days or not?

#

To which event should we react then

#

for SEPA

slate dawn
#

invoice.paid I would say! otherwise you're giving access to the product before you have confirmed that you actually got the money from the customer

foggy skiff
#

Yes thats we want to do ๐Ÿ˜„

#

Because its a bad user experience, if he has to wait 4-5 days

slate dawn
#

fair, but it's a risk for your business then

#

SEPA is a method you need to be really careful with, it has a no-questions-asked dispute policy. It would be trivial for someone to sign up, pay with SEPA and get your product and then dispute it and not have to pay(and you have to pay a $15 dispute fee). Equally, you don't know if the payment even succeeds or has declined until those few days later

#

integration-wise, if you do want to do this, then I suppose you could just listen to the payment_intent.processing event and connect that to the related invoice and subscription and provision access at that point

foggy skiff
#

Alright, thank you very much for your help

#

๐Ÿ™‚

#

One more question

#

Where can we change the payment methods for Subscriptions?

slate dawn
#

change what exactly? the methods/options available to pay it with, or the specific payment method saved to a customer for future payments?