# \`last\_charge\_status\` is delayed **URL:** \ **Category:** API Feedback\ **Created:** [January 23, 2024, 5:01pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532 "2024-01-23T17:01:19Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Leo](https://avatars.discourse-cdn.com/v4/letter/l/c2a13f/32.png) [@Leo](https://www.patreondevelopers.com/u/Leo)\ **Post date:** [January 23, 2024, 5:01pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/1 "2024-01-23T17:01:19Z")
I’m using OAuth2 for users to login into my website. To verify the user is an actual paying member, I am checking both `patron_status` and `last_charge_status` for `active_patron` and `Paid` respectively (I’ve noticed in the past that `patron_status` sometimes did not update for people with declined charges). However, the `last_charge_status` field is lagging behind the actual status of the latest charge, I’ve noticed a (relatively consistent) delay of up to 30 minutes. This delay is even visible in the normal Dashboard. Here’s an example of a new Patron who was still Pending in the overview (which probably uses `last_charge_status`) but the charge in the history is already paid. ![image](https://canada1.discourse-cdn.com/flex036/uploads/patreondevelopers/original/2X/4/4c6b40aa4d62cef74b9b3ca3c8a9159e96040fa1.jpeg) (Excuse the weird format, I can only upload one image due to new user restrictions, so I had to improvise a bit) The charge of the example above: ```auto { "amount_cents": 1875, "currency": "SEK", "date": "2024-01-20T12:16:01.000+00:00", "is_refundable": true, "partial_annual_refund_data": { ... }, "status": "Paid", "supported_period_end": "2024-02-01T08:00:00.000+00:00", "supported_period_start": "2024-01-01T08:00:00.000+00:00", "underlying_charge_id": "...", "underlying_charge_type": "patronage_purchase" } ``` As you can see, the charge was created at 12:16:01. However my server logs report `last_charge_status` was still `Pending` until as late as 12:35:48 (response from a call to `https://www.patreon.com/api/oauth2/v2/identity?include=memberships&fields%5Bmember%5D=patron_status%2Cnext_charge_date%2Clast_charge_status`): ```json { "data": { "attributes": {}, "id": "...", "relationships": { "memberships": { "data": [ { "id": "...", "type": "member" } ] } }, "type": "user" }, "included": [ { "attributes": { "last_charge_status": "Pending", "next_charge_date": "2024-02-20T00:00:00.000+00:00", "patron_status": "active_patron" }, "id": "...", "type": "member" } ], "links": { "self": "https://www.patreon.com/api/oauth2/v2/user/..." } } ``` However, the last charge was already paid at the latest by 12:27, which is when the Patron contacted me and I took the screenshots above. Because I only log failed auth attempts, I don’t know when exactly the status finally updated, but it was outdated for _at least_ 8 minutes. (I re-checked the dashboard at 12:42 and it was finally up-to-date). ---
**Author:** ![codebard](https://yyz2.discourse-cdn.com/flex036/user_avatar/www.patreondevelopers.com/codebard/32/14_2.png) [@codebard](https://www.patreondevelopers.com/u/codebard)\ **Post date:** [January 26, 2024, 10:50pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/2 "2024-01-26T22:50:13Z")
If you are having your users log into your app, why arent you using currently\_entitled\_tiers and currently\_entitled\_amount\_cents to check to what the patron is entitled to without having to deal with payment statuses? ---
**Author:** ![Leo](https://avatars.discourse-cdn.com/v4/letter/l/c2a13f/32.png) [@Leo](https://www.patreondevelopers.com/u/Leo)\ **Post date:** [January 30, 2024, 12:56pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/3 "2024-01-30T12:56:58Z")
`currently_entitled_amount_cents` and `currently_entitled_tiers` do not account for pending charges. A Patron’s last (and also first) charge has been pending for 5 days but those fields return positive results. Had I been relying on those fields, this person would’ve gained access without the payment ever going through. ![image](https://canada1.discourse-cdn.com/flex036/uploads/patreondevelopers/original/2X/4/4ea79b57ad3edd3ce72afc7692863b8fc7f9478b.png) Notice `last_charge_date` being from Jan 25th and `last_charge_status` still being Pending. ---
**Author:** ![codebard](https://yyz2.discourse-cdn.com/flex036/user_avatar/www.patreondevelopers.com/codebard/32/14_2.png) [@codebard](https://www.patreondevelopers.com/u/codebard)\ **Post date:** [January 30, 2024, 8:42pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/4 "2024-01-30T20:42:30Z")
That is expected behavior. Until all the retries for charging a member are finished, the member is considered a valid member and those two fields should show the tier or amount the user was entitled to before the charging attempts started. This is how it works at [patreon.com](http://patreon.com) and following the same pattern at your app unless you have a very specific use case to not do so, would be best. ---
**Author:** ![Leo](https://avatars.discourse-cdn.com/v4/letter/l/c2a13f/32.png) [@Leo](https://www.patreondevelopers.com/u/Leo)\ **Post date:** [January 31, 2024, 9:10am UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/5 "2024-01-31T09:10:37Z")
Sadly bad actors exist and I can’t be so lenient to give someone access for weeks without even paying _once_. Which is why I want to use `last_charge_status` to make absolutely sure the payment went through. But that’s going off-topic, this post is about the fact that `last_charge_status` lags behind the actual status of the last charge. ---
**Author:** ![codebard](https://yyz2.discourse-cdn.com/flex036/user_avatar/www.patreondevelopers.com/codebard/32/14_2.png) [@codebard](https://www.patreondevelopers.com/u/codebard)\ **Post date:** [February 15, 2024, 4:35pm UTC](https://www.patreondevelopers.com/t/last-charge-status-is-delayed/8532/6 "2024-02-15T16:35:13Z")
That is possible as a payment can pass through, but could be reverted by the payment provider (or the payer’s bank) for any reason. You could try to incorporate that 30 min delay into your flow in case you definitely need to make sure, in case you arent able to revoke access to the patrons whose payment status get reverted etc.