dj-paddle
dj-paddle copied to clipboard
paddle-python
Implement subscriber sync from Paddle API
Hi, I decided to implement subscriber sync.
A few things to note.
- Some fields aren't returned - see lines marked with question marks. Some are even returned conditionally depending on the state of the subscription.
- There is a serious problem - we can't get_or_create users (get_subscriber_model). The User model does not allow creating users without usernames, etc.
- I had to change a few DB fields to accommodate the API returns.
- No tests implemented yet. I did test with a prod workload and it seems to sync just fine, but nothing automated.
As a side note, I implemented a partial fix to bullet point 2: this seemed very worrying.
Code review welcome. So far it seems to be working fine, but it certainly isn't perfect.
Apologies for the messy commit history - it seems GH automatically merged another commit into my pull.
Added a few other bugfixes:
- Fix mistyped parameter in update_or_create: this was breaking functionality from_update.
- Fix extra 'created' unpack: this fixed a mistake I made.
More bugfixes:
- Made max_length on IDs TextFields rather than 32, for some reason Paddle is returning IDs of length 35 and this broke webhooks completely for me (on production).
@matteing A potential problem i see here is that the email used for Paddle checkout may not match the local user's email. A clean way of doing this would be to send a unique local user id as a passthrough argument when initializing the Paddle JS snippet (see https://paddle.com/docs/paddle-checkout-web/ - section "Sending additional user data"), this will then be included in the subscription_created webook and can be used to match a local user, even if a different email was used during the Paddle checkout.
However, Paddle currently only includes this passthrough string in the Webhook, not in the List-Subscriptions API endpoint*. So if anything goes wrong during the webhook, it will not be possible to manually sync via Django command later (or we will have to fallback to email matching).
*I've already contacted Paddle about including the passthrough argument is the API endpoint, was told they see that it would be useful but they can't provide a ETA.
Just something to consider.
I actually absolutely agree with @kennell on this subject (I face this problem on production), however I didn't find that the current code did this linking using the user_id argument - so I didn't implement it as to keep feature parity (see here).
If given a green light I think I can take a shot at adding user_id linking.
Edit: Reading more carefully, noted on the endpoint issue not returning webhook data.
@matteing thanks for your good work! I added some comments. However, it would be great to have a test for it. I'd like to see our test-coverage reach a reasonable level soon.
@matteing A potential problem i see here is that the email used for Paddle checkout may not match the local user's email. A clean way of doing this would be to send a unique local user id as a passthrough argument when initializing the Paddle JS snippet (see https://paddle.com/docs/paddle-checkout-web/ - section "Sending additional user data"), this will then be included in the
subscription_createdwebook and can be used to match a local user, even if a different email was used during the Paddle checkout.However, Paddle currently only includes this passthrough string in the Webhook, not in the List-Subscriptions API endpoint*. So if anything goes wrong during the webhook, it will not be possible to manually sync via Django command later (or we will have to fallback to email matching).
*I've already contacted Paddle about including the passthrough argument is the API endpoint, was told they see that it would be useful but they can't provide a ETA.
Just something to consider.
Agree. This is another good argument to make the matching of subscribers configurable with a sane default (e.g. email-matching). So the developer that implements dj-paddle into his project can decide how to handle it for his respective use-case.
I need this feature. Are the owners of the repo active lately? I don't want to put in the work if they aren't reviewing pull requests.
Package seems long unmaintained. I'm unsure of any alternatives. It's been a while since this thread! :)
@matteing thanks for the reply and the initial work!
Package seems long unmaintained.
ugh, forking it is then.
@matteing thanks for the reply and the initial work!
Package seems long unmaintained.
ugh, forking it is then.
That's a good approach! Although no shade on the original authors -- they did great work pushing support for Paddle with Django.
I hope the Paddle API primitives haven't changed since then!
That's a good approach! Although no shade on the original authors -- they did great work pushing support for Paddle with Django.
Totally true. My comment was rude. The authors don't owe nobody their time and the project is of great value as it is.
No worries homie! Hope my work helps as well.
Sent from my iPhone
On May 26, 2023, at 4:22 PM, Juan Olvera @.***> wrote:
That's a good approach! Although no shade on the original authors -- they did great work pushing support for Paddle with Django.
Totally true. My comment was rude. The authors don't owe nobody their time and the project is of great value as it is.
— Reply to this email directly, view it on GitHubhttps://github.com/paddle-python/dj-paddle/pull/19#issuecomment-1564904171, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB4XGZNWZJ366LPPPRQ6QP3XIEGGZANCNFSM4MFENADA. You are receiving this because you were mentioned.Message ID: @.***>
@j0lv3r4 I ended up forking for a fix/features I needed semi-recently. Don't know if you are interested in any of those changes: https://github.com/saschwarz/dj-paddle/commits/master
Just FYI i started a alternative implementation a while ago:
https://github.com/kennell/django-paddle
Far from feature complete, but perhaps a alternative to some -- or at least a inspiration ;)