| 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 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.
|
|
|
|
|
|
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...
|
