Creating Customer On paddle_billing.subscription.created

[cfprotools]

I'll be selling access to my SaaS through a Paddle checkout embedded in a ClickFunnels page. Once a subscription is created during the sign up process Paddle will fire the webhook to the app so that a User, Team, Customer, etc... can be created. It seems like the Pay gem is expecting that the User and Pay::Customer will be created first and then the Pay::Customer will be passed to Paddle through the passthrough params. That's not how I'd like this to work.

How best to customize the webhook flow so that I can search for an existing Team (owned by a User) by the email in the webhook and either attach the subscription if the team and user already exist or create a new user and team and then attach them to the PayCustomer?

[deanpcmad]

For Paddle Billing it's best to create the customer first, as then any subscriptions/transactions are created for that Pay::Customer, which is then linked to your main model, may it be a User, Team, etc.

What's the reasoning behind why you don't like the current way? Do you not have users login first?

[deanpcmad]

I'm not entirely sure. I don't think it will completely override the webhook but maybe @excid3 could help with that?

[cfprotools]

Yeah, If I could capture the webhook and process with logic to find or create the team, user prior to the Subscription.sync being called, then I think we'd be good. I just am trying to sort out where to inject into the existing process without having to fork the whole thing. If the custom webhook handler fires first, then maybe I could do it there. Of, if it overrides entirely and stops the regular processing, then I could do it there and then call the Subscription.sync call from the custom one.

[cfprotools]

ah, I think I might see how to do this now in the docs. Looks like I can unsubscribe the default listener and then create a new custom listener and subscribe that one instead. The new listener would check for an existing team, user by email address and create them if needed, then continue on to the normal sync call just like the default listener.

Does that sound right?

[deanpcmad]

I've never needed to create custom webhook listeners, but yes it does appear so looking at the docs > https://github.com/pay-rails/pay/blob/main/docs/7_webhooks.md#unsubscribing-from-a-webhook-listener

[cfprotools]

Just an updated. I've got some updates made to override the incoming webhook for new Paddle subscriptions. I'm still working on testing, but I think I've got the solution I need.

Thanks for all your help.

[deanpcmad]

Sounds good! Glad to be of help 😄

[ninsky]

For Paddle Billing it's best to create the customer first, as then any subscriptions/transactions are created for that Pay::Customer, which is then linked to your main model, may it be a User, Team, etc.

What's the reasoning behind why you don't like the current way? Do you not have users login first?

Do you have a source showing how to create a customer first? Having a hard time to integrate Paddle

[deanpcmad]

Do you have a source showing how to create a customer first? Having a hard time to integrate Paddle

Yes, it's all in the docs - https://github.com/pay-rails/pay/blob/main/docs/paddle_billing/1_overview.md
But you would set the payment processor and then use the api_record method to create the customer on Paddle