Support REST-API calls too, instead of only webhook events

[Osiris-Team]

Currently, PayHook relies on webhook events/notifications and was designed around it.
However, it can also be done without webhooks.

Contributions are welcome for this one since I don't need support for it.

• Find a way to capture payments after they have been created
• Find a way to check if subscriptions have been paid

[harshitissm]

Hi, I am starting my open-source contribution journey and came across Payhook. I would like to help you resolve this issue. can you please explain and give me a walkthrough? I have experience with Stripe, where I implemented the payment system for a project. I've also handled the stripe webhook events.

[Osiris-Team]

@harshitissm that's great! Currently it works by relying on Webhooks that notify PayHook / your website with new data like new successfull payments. Instead of relying on these Webhooks we can implement an alternative way like a loop that checks every minute for example via the REST API for new payments instead.

[harshitissm]

Hi @Osiris-Team.

Thank you for sharing the idea, I completely understand the feature you're suggesting.

From my experience working with webhooks, Stripe provides comprehensive event notifications for all payment-related activities across subscriptions. These webhooks are event-driven and efficient, as they only trigger when something happens and come with a built-in retry mechanism for reliability.

On the other hand, implementing a polling mechanism that checks for new events every minute via the REST API could introduce significant overhead. As the number of subscriptions increases, polling at such a frequent interval might result in a large number of unnecessary API calls, potentially impacting performance and scalability.

That said, I’d love to understand your perspective better. Could you please share more about the specific use case or challenges you're aiming to address with this approach?

Looking forward to your thoughts!

[Osiris-Team]

@harshitissm I think the only real benefit of this feature is that you reduce the chance for DOS attacks since you don't have an endpoint that basically accepts any data.

[harshitissm]

Hi @Osiris-Team,

We only provide the webhook receiving endpoint to Stripe via their dashboard and do not expose it elsewhere. Given this limited exposure, could you please clarify how it would be vulnerable to an increased risk of DoS attacks?

[Osiris-Team]

Yeah, it's security through obscurity, the endpoint is still theoretically public.