| Age | Commit message (Collapse) | Author |
|---|
|
The default expiry is 24 hours. That means that if an invoice was due to
be canceled in say 4 hours, and the user clicked the payment link they
would be able to use that one past when the invoice was actually
canceled, thereby causing errors. This happened at least once, where the
user forwarded the Adyen link (instead of the invoice link) to the
person who was supposed to do the payment, and that person made the
payment after the invoice was expired.
So, if the invoice is set to be canceled in <24 hours, we set the
expiresAt flag when creating the payment link, so Adyen will reject that
payment.
Reviewed-By: Daniel Gustafsson
|
|
|
|
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.
|
|
Replace them with an (inefficient) query, for the unusual cases where it
has to be checked in the django admin interface.
|
|
|
|
|
|
|
|
The system in general supports this but for some reason the Adyen record
of the refund (which isn't really used anywhere other than for logging
purposes) was limited to 1.
|
|
Seems the subject was copy/pasted without editing, and the actual
contents of the email used the wrong term as well. Oops.
|
|
This generates a gigantic dropdown otherwise, now that there are many
notifications. And it should never be changed anyway.
Use the same pattern as for the other models referring to notifications.
|
|
Add filters based on Merchant Account and Report Type, to make it easier
to scroll through very long lists of reports when debugging.
|
|
In passing, clarify the error message if we have a re-settle of a
transaction with a new amount.
|
|
|
|
|
|
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.
|
|
The current Hosted Payment Pages (HPP) system is deprecated by Adyen and
will be removed in Oct 2022. So we replace the implementation with one
using the Payment Link system.
The big advantage of HPP vs the other options provided by Adyen is that
*all* processing is handled at Adyen, thereby not requiring any PCI
certification. And luckily the same applies for Payment Link, which is
why it's picked over the other available options.
The difference in functionality is that instead of encoding and signing
the payment information as part of the URL of the page, and API call is
made to Adyen to get a link (passing the information as a json object)
and the user is redirected to the return URL. Once that part is done,
the processesing is handled by Adyen. There is no longer an actual
authorization result as part of the return url (something HPP had but we
didn't use anyway), but as before we send the user in a refresh loop
while we wait for the asynchronous notification to arrive.
Payment Link also providers a generally more modern interface and works
better on mobile for example, which while not necessary very important
to our customers, is a nice touch. It may also open the door for some
other payment methods in the future.
|
|
It makes more sense that they're called bank payments than invoice
payments, because all our payments are invoice payments.
|
|
This field is empty on AUTHORIZATION notifications and on some newer
notifications it appears to then simply not be included.
|
|
This was broken when we moved to python3, but the only result was the
string was stored in the db with a b'' wrapper. The in-line processing
used the original QueryDict and worked fine, but this broke later
re-processingf of the noficiations.
|
|
This code was copy/pasted between several different places, so
centralize it into the InvoiceManager class to reduce the risk of
furhter off-by-one mistakes when editing.
|
|
|
|
It seems we get a notification into the system for PDF reports manually
ordered in the interface as well (at least sometimes), which would then
crash the download process as we try to store the results in a text
field. Add a check for csv, and ignore all non-csv reports. We still
store them in the list of report (and just pre-flag them as processed),
so that we will have a record of which reports have been delivered if
something changes down the line.
|
|
|
|
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.
|
|
We dont want to lose things, but we dont mind loose things..
|
|
|
|
|
|
Previously some permisisons were directly controlled by the group and
some were controlled by directly checking module permissions.
|
|
If a managed bank account is specified as the payout account, the Adyen
provider will now register a pending matcher for that account and leave
the accounting entry open (to be closed when the payout actually
happens).
|
|
This adds the scheduling metadata to all the existing management
commands.
In passing, also makes the description nicer on a couple of them,
since it is now shown in the admin web.
|
|
|
|
|
|
This is a major refactoring of how the payment method integrates, with
the intetion of making it more flexible and more easy to use.
1. Configuration now lives in the database instead of local_settings.py.
2. This configuration is edited through the /admin/ interface, which
makes it a lot easier to add constraints (and instructions), thus
preventing misconfiguration.
3. Invoice payment methods are now separate from invoice payment
implementations. That means there can be multiple instances of the
same payment method, such as multiple different paypal accounts,
being managed.
4. All payment method implementations are now available in all
installations, including Braintree and Trustly. This retires the
x_ENABLED settings in local_settings.py. The code won't actually run
unless there are any payment methods defined with them.
5. On migration, all payment methods that are marked as inactive and
have never been used are removed. Any payment method that has been
used is left around, since there are old invoices connected to it.
Likewise, any payment method that is selected as available for any
sponsorship level (past or future) is left in the system.
XXXXXX manual action needed on production systems XXXXXX
1. Settings for payment methods should be migrated automatically, but
should of course be verified!
2. The template for Manual Bank Transfer is *not* migrated, since it
wasn't in settings.py, but in a template and overriden downstream.
Migrate the contents of the template invoices/banktransfer.html to the
database using the /admin/ interface. When this is done, the template
can be removed.
3. Notification URLs in Adyen must be updated in the Adyen backoffice to
include the payment method id in the url (adding a /n/ to the end of the
URL, with n being the id of the payment method).
4. Notification URLs in Paypal must be updated the same way.
|
|
This was never the right way to do it, but it randomly happened to work
in the old one. To properly round off a decimal, we should be using
quantize.
|
|
|
|
2to3 doesn't do this automatically, probably because weird things can
happen if you had both. We know we didn't, so just do a straight
replacement.
|
|
|
|
|
|
Instead of never doing anything about them other than sending an email,
add a setting for ADYEN_IS_TEST_SYSTEM. If this setting is True
(default!) and the notification comes in from the adyen test
environment, process it as normal. If it's False and the notification
comes in frmo the live environment, process as normal. Only if there is
a mismatch is the email generated.
In passing, change the term "test system" to "test environment", to make
it more clear.
|
|
It's a lot cleaner API than urllib2, and will be easier once we port
version.
Hopefully this doesn't break something. Probably it does break encoding
somewhere, because py2.
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
Python 2.6 introduced the better syntax, Python 3 removes the old one,
so one small step towards py3.
|
|
It has been deprecated, and instead we should use "in" and "not in", so
make that change across the board.
|
|
Embarassing mistakes for a database developer...
|
|
|
|
|
|
|
|
In passing remove some comments that were pointless
|
