| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
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.
|
|
Trustly payments can remaining pending state for quite a long time, due
to banks being closed over weekends etc. In this case, bad things
happened when the invoice was automatically canceled.
However, unlike iban payments we know that the likelihood of the payment
actually being completed is very high. So instead of giving up, have the
system automatically extend the invoice cancel time when this happens.
This is done in two stages:
1. Immediately as the payment arrives it's made certain that the invoice
has a lifetime of at least 2 hours left. This extension is done
silently (except logged of course)
2. A cronjob designed to run hourly (to make sure it runs before an
invoice extended by 2 hours expires) will extend it in steps of 24
hours if it remains in pending state. If this happens a notification is
sent, so the admin can make a decision on whether to cancel or not.
Do this by implementing the functionality generically in the
InvoiceManager so it can also be used by other payment methods in the
future, but Trustly being the only one it's implemented for right now.
|
|
When a Trustly transaction is refunded in a non-default currency the
actual refund is listed in that currency and not the primary one, which
makes it not match up in the accounting.
To deal with that, fetch the ledger rows for the day of the refund and
try to locate the actual amount there. If found, use this amount to
calculate "fake fees" (as the amount normally doesn't match perfecly due
to currency rates changing between payment and refund). This should
hopefully lead to a balanced accounting entry.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
In passing remove some comments that were pointless
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sorry about the spam..
|
|
|
|
|
|
This ensures we don't fail on reprocessing cancels
|
|
This is normal, not a fatal error.
|
|
|
|
|
|
There are probably still some rough edges since a number of things
cannot be tested until it's deployed on a live server, but basic
payments should work.
|
