- dj-paddle version: 0.1.2
- Django version: 4.2.3
- Python version: 3.9.9
- Operating System: Linux
Description
In production, we had an error when a user created a subscription and a webhook was sent:
"Subscriber could not be found for subscription <subscription_id> with payload".
We narrowed down the problem to a case sensitivity issue. Specifically if a user registered on our site with an uppercase letter and then tried to subscribe, the Paddle JS front end would lowercase the email address by default. When the subscription_created webhook was fired, the mapping would fail to find the associated user and they wouldn't be successfully marked as having a paid subscription. Unfortunately this affected our very first paying customer - talk about bad luck!
What I Did
- Create a user like 'Test@example.com' with an uppercase letter in their email address.
- Try to initiate a subscription using the Paddle UI
- Note that the UI will default to lowercasing their email address (you can also probably just manually change the casing in the Paddle modal).
- Complete the payment
- You get an error when the subscription_created webhook is fired stating that the user is not found.
Workaround
You can override the default mapping by setting the settings param DJPADDLE_SUBSCRIBER_BY_PAYLOAD. Then you can replace the default djpaddle.mappers.subscriber_by_payload() and make sure you're doing a case-insensitive search.
Fix
I believe the user search should be case-insensitive, since subscriptions_by_subscriber() is also doing a case-insensitive search. I'll try to submit a pull request.
Description
In production, we had an error when a user created a subscription and a webhook was sent:
"Subscriber could not be found for subscription <subscription_id> with payload".
We narrowed down the problem to a case sensitivity issue. Specifically if a user registered on our site with an uppercase letter and then tried to subscribe, the Paddle JS front end would lowercase the email address by default. When the subscription_created webhook was fired, the mapping would fail to find the associated user and they wouldn't be successfully marked as having a paid subscription. Unfortunately this affected our very first paying customer - talk about bad luck!
What I Did
Workaround
You can override the default mapping by setting the settings param DJPADDLE_SUBSCRIBER_BY_PAYLOAD. Then you can replace the default djpaddle.mappers.subscriber_by_payload() and make sure you're doing a case-insensitive search.
Fix
I believe the user search should be case-insensitive, since subscriptions_by_subscriber() is also doing a case-insensitive search. I'll try to submit a pull request.