I am doing a request to https://www.patreon.com/api/oauth2/v2/campaigns/XXX/members
In the results, there is invalid data. The two relevant fields are:
[last_charge_date] =>
[last_charge_status] => Paid
The last_charge_date should have a date in it? If it’s empty, does that mean they haven’t paid?
In fact, since yesterday (2020-09-03) the last_charge_date is empty for EVERY patron in the result. Please fix!
This is incredibly important, and I posted a separate issue on precisely why it’s so critical here: WebHook API sending NULL last_charge_date, resulting in double rewards. MAJOR issue before I noticed it was raised already.
The short of it is that when processing webhook events, the last_charge_date is basically the only way you can differentiate separate payments, since a patron paying can often (though not always) generate multiple events. Right now with the date of ‘null’ my system is forced to think of them as separate, unique payments, resulting in double and even triple rewards which I then have to sort through manually.
Yep. I basically have the same issue. Let’s hope they fix it soon.
I have encountered a major issue with the Webhook API today. To summarize the issue, the “last_charge_date” is returning NULL instead of an actual date. This is a critical problem for the reason I will explain below. This has been happening as of September 3rd and has resulted in many of my patrons receiving double rewards. I had to go through 250+ records manually to remove the doubled rewards, and am continuing to have to do so as more payments come in.
I fully understand that the API is no longer supported (I actually don’t know if this applies to the webhooks as well though I’ve always figured they were more or less the same thing), but from what I have read, that merely means that it’s not being updated, but that creators who have relied upon it to dispense rewards to their users can still continue to do so.
The reason the last_charge_date is important is because the Webhook API itself has always been broken when attempting to get notification of a payment being processed. When a patron’s payment has been processed, there are multiple things that happen:
Because this is entirely inconsistent, I cannot reliably trust whether the payment I’m processing here has been handled already or not, but until today (September 3rd) I was able to rely on the fact that the last_charge_date would be unique to the payment. Therefore by keeping track of the last payment processed, I could tell if I was receiving duplicate information or not.
Now that the last_charge_date is coming as null, this effectively has caused all second packets to be counted as a new payment, and so I just finished up combing through 250 individual such packets to delete the doubled rewards that ended up being given out today alone. My patreon campaign has over a thousand individuals pledged, so this kind of problem is rather considerable.
Reliance on the last_charge_date shouldn’t required of course, but this total unreliability of the system isn’t exactly an unknown thing. I’ve seen plenty of others mention it on the community forum. I do not hold out hope that we will be able to reliably get notifications per-payment, but is it unreasonable to hope that what is already barely working will not be broken further?
In case I have not provided enough information, here’s an example of a packet received from the web hook. Notice the value of the last_charge_date.
{“campaign_lifetime_support_cents”:12200,“currently_entitled_amount_cents”:500,“email”:“@.",“full_name”:"**”,“is_follower”:false,“last_charge_date”:null,“last_charge_status”:“Paid”,“lifetime_support_cents”:12200,“note”:"",“patron_status”:“active_patron”,“pledge_relationship_start”:“2017-06-10T19:27:12.244+00:00”,“will_pay_amount_cents”:500}
If this last_charge_date:null issue isn’t fixed, I can’t really see any other way to somewhat reliably tell different payments apart. Without that, the entire backbone of my patreon rewards system cannot function.
Same issue as me: Issue/Bug in Patreon API: last_charge_date empty for ALL patrons since 2020-09-03
It’s broken for both the webhook AND the members request since 2020-09-03
Same issue for us too! And I could not find a way to contact them to even try to get a solution for this…
I had opened a support ticket last night after I finished manually combing through my new records, they told me to post it on the community forum. Based on the fact that they just merged our two topics, I imagine it’s being looked at.
I just really hope that they do something about this… this is Too way important to let without a fix…
I Also noticed too that this message is wrong ans it’s appearing every day!
UGH. Yeah, I’m seeing it too via polling the members endpoint.
I just spent a whole week rewriting my code to support multicurrency, and I now depend on this parameter being accurate so I don’t have to spam the API with 1k+ calls every half hour to check pledge history on every linked member (just the ones with a new last_charge_date/status)
(It would be a lot more efficient for us if the members endpoint included a last_charge_tier and last_charge_id so we could know what a user has paid for, and more accurately differentiate charges than comparing inconsistent timestamps (pledge history endpoint returns an entirely different one)
I had opened a support ticket last night after I finished manually combing through my new records, they told me to post it on the community forum.
This is ridiculous behavior on Patreon’s part. Something as critical as this going down should have official, immediate communication.
According to this:
There is no devleoper support as of 22 June.
I used to use the “lifetime total” as a way to check if someone had paid again. The API (both old and new) are really bad for answering the simple question of: “For how much did Patron X support me this month?”
The “endpoints will continue to function as normal” bit should, hopefully, suggest that any bugs they introduce on their own should still be something they intend to fix in a timely manner.
But then who the hell knows.
I had initially thought to use the lifetime total, but unfortunately when I was setting up the webhook handling back in February, it seemed to be unreliable. I’d usually get a webhook event that would report the old lifetime support, and then sometimes I’d get one that reported the new one. Sometimes though, there would be no second event, meaning that someone could pay have no such change reflected in the data sent at the time.
It really seems like “I got paid X by Y” is the absolute most basic functionality this API should be delivering, not something to be dredged up through obscure, inconsistent relationships between fields.
Fully agreed. Let’s at least hope they fix this VERY silly bug that has been there for 3 days now.
In my experience, after a charge, lifetime total takes anywhere between a couple hours and 17 days to update -.-
Though it did get better last couple years and generally only took 1~3 days to update, so we relied on it until multicurrency.
I guess if they don’t fix it, we can always do massive numbers of API calls, but if we all do that, I wonder if the API will fall over entirely. ¯\(ツ)/¯
Does anyone here got any reply from them about this issue?
I raised a ticket with them as well and got the standard copy-paste response.
I know this is non-ideal, but if you don’t mind writing a bit of code, just automate loading up the website and downloading the CSV. The CSV continues to have the correct data. If you need help with this, let me know.
I am now seeing signs that the issue is fixed (or being fixed) - at least the last two payment records I got via web hooks, both within the last few hours, came in with non-null lastChargeDate values.
CONFIRMED - It appears to be fixed both in the webhook AND in the members request.
The earliest webhook call I had the data in was 2020-09-09 03:30:07 UTC
I tested the members call just before I posted the reply.