| Age | Commit message (Collapse) | Author |
|---|
|
Typical case is if an invoice is open for payment in two different tabs,
it's then paid in one tab and then reloaded in the other, the Strip
integration would crash because it accessed the wrong field. This has
been wrong since day one of the Strip integration, so the comment
stating it won't "normally happen" was entirely correct...
|
|
Stripe made a change (quite some time ago) in how they send refunds, and
no longer include the actual refund id in the webhook notification. The
only way to get the full details is to make another outbound API call.
Given how our refunds work, it looks like we can *probably* get away
with just looking up the refund based on charge id and amount, since
it's highly likely we'll trigger another refund before the webhook has
completed with exactly the same amount to the same invoice.
So re-implement the refunds hook to do this, and we can see after some
real-world testing if this was enough or if we also need to do the
outbound API calls to check in more detail.
Patially diagnosed and researched by Steve Singer.
Fixes #156
|
|
|
|
|
|
|
|
In particular, allow just the text STRIPE (or rather, anythign that ends
in it) with nothign following it, as that appears to be what comes out
of Stripe UK.
|
|
This change allows the currency format to be configured in the
instance. This allows us to use alternate symbols (e.g. £), and
to format amounts using the format required in different
jurisdictions.
The currency format is set to Euro by default.
Note that this change requires an update to any Jinja templates
that use the currency_format tag. This must be changed to
format_currency.
|
|
Newer versions have changed a number of things. We need to update to
work with those at some point, but to start with let's make sure we get
the current deployment working.
|
|
|
|
This is complained about more loudly in newer versions of pycodestyle,
and it's a bad idea in general. So rename them all to something more
readable.
|
|
|
|
This was already done once in 8289e05cd but had not been properly
maintained.
|
|
This should always be set to todays date, so set it in the function
instaed.
This changes the behaviour of the paypal plugin to actually use todays
date rather than a date parsed out from the notification. In theory this
could change the accounting entry date in case the notification is so
delayed it ends up on a different day, but either one could be argued to
be equally correct in this case, and using the date of creation of the
transaction makes tracking things a lot easier.
While at it, clean up some imports that have been missed earlier.
|
|
As a step on the way to better timezone support, use the django function
timezone.now() instead of datetime.now(). As long as we haven't enabled
timezones globally this becomes a no-op and does exactly what it did
before, but once timezones are enabled it will generate datetimes that
are aware of this.
No functionality change but gets a lot of boiler-plate out of the way
making the verification of the rest of the timezone work easier.
|
|
Now that we've seen a few in real life, we can make a better attempt.
Unfortunately the payout "magic number" cannot be matched to any data in
the API that I can find, so we will just have to by very basic matching
along with the amount.
|
|
Seems nobody has been doing Stripe refunds before :) The check looked
for refunds that had actually completed, and flagged them as stalled...
|
|
|
|
|
|
|
|
|
|
|
|
The column is called paymentmethod, not method. This has been breaking
since de857e0cac908f3f121812d4161c21dc4f33ad84, which fixed the name of
the implementation (before that, the job never got far enough to break
here).
|
|
|
|
|
|
|
|
|
|
This is not complete as we don't know exactly what a transfer will look
like on the bank side of things, but should work for everything except
managed bank accounts.
|
|
|
|
No support for payout tracking yet, since Stripe makes it impossible to
test that until 7 days after you sign up for the test account...
|
