Hopefully the issue will be fixed soon, this is very bad experience for our Patrons.
Itâs fixed now, as far as I can see.
Hey, out of curiosity, what overall changes did you have to implement to make your code compatible with the multicurrency thing? Was it just processing the currency conversion from Euro/GBP to USD? Were there any significant hurdles you ran into?
Sure; In this post, I go into it in some depth also (along with some recommendations on improvement). The short version of it is that since you wonât be able to depend on charge cents being consistent (Patreon plans to adjust it periodically based on currency fluctuations), we have to check the last charge. If youâre not doing charge up front, current tier is not necessarily what the user has paid for yet, so you canât trust that current tier value.
Hereâs the new algo (Looks like forums donât support more than two layers for nested bullets, so apologies for the ugly formatting here)
1. Get a list of all pledges from the API
2. Prune out any accounts from that list that don't have a locally linked account
3. For each remaining user:
i. If the last charge time is a long time ago, they can be skipped (old account)
ii. Determine whether this user should be further processed to avoid massive future API calls:
a. If the last charge timestamp significantly differs from last time program was run:
x. If the new status is paid, it definitely should be processed
y. If it's something else, it's probably safe to skip -- but this logic assumes Patreon does not update last charge time if a charge switches to revoked, which I don't know for sure if that's the case.
b. If the last charge timestamp is mostly the same as from last time:
x. If it's the same as the saved status from last time, there hasn't been any change, so user does not need any further reprocessing.
y. Otherwise it's a status change, so should be reprocessed.
c. (Yes, it's kinda top tier BS to be comparing timestamps instead of charge IDs, but working with what we're given... >.<)
iii. Hopefully most users have been pruned out at this point, because now we do an API call for each additional user to get their transaction history.
iv. Check most recent subscription event. Fortunately, here we finally have a payment ID and a charged tier ID. Here we can do the more traditional payment logic, like:
a. If it's a new payment in paid status, grant access to any relevant entitlements for a month (to cover the time paid, plus internally I add a bit of buffer when checking this value in case Patreon API is slow the next month)
b. If it's an old payment that used to be paid but now is something else, revoke the previously granted entitlements
It usually takes about 3.5 minutes for this algo to run with ~1000 active+former patrons, with small delays between each API call. I run the whole thing every 30 minutes. Itâs definitely a lot more API calls than the old method, but it works.
Big caveat: charge time is not the same between the two calls. One is approximate, the other is the true time. (I believe I mention that in my other post, too.)
This all means I had to upgrade half my site to v2 instead of v1, which ended up being a week+ long process of rewriting the code. This time around, Iâve built it so it can run for an extendedly long period of time, and resume if the process dies or needs to be restarted (and it locks itself to ensure two instances arenât running at the same time). Iâm not sure if the code is quite good or general-purpose enough to release one way or another. Iâm still working out to find situations where the code produces different entitlement values than the old version of my poller, probably because the new version is faster/can handle the case of someone charging+unpledging before the poller runs/can handle chargebacks/refunds, or possibly just because thereâs a bug 
And if anyone from Patreon is reading, again, recommendations here.
2 Likes
Thanks! That should be a big help when I look into adjusting my code tomorrow.
Sure is nice of Patreon not to just give us the equivalent value in good old consistent USD though and save us all the god damn trouble. I mean seriously, who makes these decisions?
Youâre welcome, good luck with the changeover.
Kinda agree, but keep in mind also that theyâre not charging the exact equivalent in USD. Theyâre setting a value thatâs roughly approximate (+5%?) rounded to an even number, that may fluctuate somewhat over time until they update the currency conversion table periodically. So Iâd rather have a last charge tier ID and last charge transaction ID, since theyâll be consistent.
You do realize that itâs completely optional, right? You donât have to enable multi-currency for your campaign. I am not going to since over 90% is from the US anyway and it saves me a LOT of hassle to just keep with one currency.
Also, guys, this is a thread related to a bug which has been fixed, please move this discussion to a relevant thread.
I hate to be the bearer of bad news, but itâs only optional until October 5th, at which point it becomes an option applicable to all campaigns.
From https://support.patreon.com/hc/en-us/articles/360044469871-Creator-currency-settings-on-Patreon,
Any existing creators who launched before August 5th, 2020 can opt into these new currencies if they choose, until October 5th, 2020 when we will automatically enable currency choice for everyone.
But yes, youâre right about it now being entirely off topic.