#kiwi_webhooks
1 messages · Page 1 of 1 (latest)
đź‘‹ Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1337044536047697960
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
đź‘‹ happy to help
Hi! is my question clear?
I'm not sure I get it all
Maybe some more context: we have a product, with an attached feature that sends us entitlement webhooks like so: (looking for an event)
evt_1QNvd9RpgCGwteH1f10nm8CM
we expected that when the customer fails their payment, we receive an entitlement update without the access
the customer is subscribed to this product through a price, and they failed to pay their invoice that I linked
and we see that they didn't lose their entitlement
Hey! Taking over for my colleague. Let me catch up.
take your time, let me know if I can clarify any details
Do you have a more recent example ? This one is very old
you mean for the entitlement?
unfortunately my problem is not receiving the empty response
I'm not understanding you sorry.
like we would be expecting this webhook event:
{
"object": {
"object": "entitlements.active_entitlement_summary",
"customer": "cus_RGSPQ5RjjaB4sp",
"entitlements": {
"data": [
]
},
...
},
"previous_attributes": {
"entitlements": {
"data": [
{
"feature": "feat_61RRUNX85ottv7bPG41RpgCGwteH1OiW"
}
]
}
}
}
Let's start from the begining, what guide are you following for your integration ?
we base our access to the product based on these entitlements - they work properly with cancel and create however we expected it will handle past due in the following way:
- customer fails payment -> lose access
- customer fixes incomplete invoice -> regain access
instead what we see is:
- customer fails payment -> no event received for entitlement
we do receive past due subscription update, however the whole point of entitlements would be to handle these edgecases so we don't have to implement it ourselves
if we have to use the subscription events for this, we can basically throw out the entitlements all together
is this case
a) not handled by entitlements
b) is there a delay before the entitlement will follow the subscription state like after all retries are exhausted?
let me know if i can clarify any more details
Why no listening to invoice.payment_failed event ?
Well, if you have to listen to another source, entitlements are suddenly not a golden source of access to the resource
what would I do if I receive a payment_failed event? cancel the subscription manually? fake the entitlement? how do I handle the edge cases between a model provided by Stripe and my additional extension?
it is not scalable, at that point I would need to reimplement the entitlements API fully because handling the complexity between our model and yours is just more work than handling it ourselves.
can you confirm whether the customer will lose entitlement when all the retries are exhausted?
if they do lose entitlement at that point, maybe less retry attempts and less time window is a good solution.
These are some checks you need to add and decide what to do depending on your use case.
Entitlements aren't linked to payments AFAIK.
they are linked to having a subscription on the product which they are attached to
can you confirm whether the customer will lose entitlement when all the retries are exhausted?
This is related to the Subscription lifecycle
yes, aren't entitlements linked with the Subscription lifecycle?
maybe that is where we are misunderstanding th emodel?
entitlements is for feature related and not payments
If a all payment attempts fails, then you revoke access regardless of what feature you are offering.
I am familiar with the subscription lifecycle, however it doesn't detail its linkage to entitlements as this is all it mentions about entitlements:
Sent when a customer’s active entitlements are updated. When you receive this event, you can provision or de-provision access to your product’s features. Read more about integrating with entitlements.
therefore reducing retry window would be a solution because after the retry window is exhausted, the subscription will enter a state where the entitlements will update correct?
This strongly depends on how you want to handle failed payments. There are folks that want to revoke access immediately until next payment is succeed and others want to keep access and give the merchant 1 month... Entitlements don't offer such customization that's why it's not linked to payments.
we can also handle the edge case of past due based on the mentioned events if we need to, but when the retries are exhausted we will receive a lost entitlement as the subscription will no longer be active
aha, makes sense. how would "Revoke access immediately until next payment is succeed" look like based on your recommendation?
listen to failed payment and implement the edge case ourselves for the time between failed payment and exhausted retries?
For example in your integration:
- When you receive
invoice.payment_failed, you revoke access to the customer immediatly - When you receive
invoice.paidyou regain access