| Age | Commit message (Collapse) | Author |
|---|
|
This is one never seen before and seems to be used for shipping labels.
Bring it in and treat it like any other.
Noted by Christophe Pettus, but not his patch - going for a minimalistic
one. This code may need some further refactoring down the road.
|
|
Apparently some bank withdrawals are "General Withdrawal - Bank account"
and others are "Withdrawals initiated by user".
|
|
Seems paypal sometimes can give back transactions without an email
address even if the email address is mandatory. Because why not. When
this happens, just fall back to our treasurer email from the config -
it's almost guaranteed to be the wrong but but it is also guaranteed to
exist, so the treasurer will just have to clean up the records manually
in accounting later.
|
|
|
|
Now a separate code for donations made using a mobile device, as if we'd
care...
|
|
Unsure exactly what this is, but they have no sender and no receiver,
and they don't show up in the Paypal UI, so they can most likely be
ignored. If not, it'll have to be dealt with manually.
|
|
It seems PayPal now has an API to get balances again, so use that one
instead of the previous ugly hack to figure out the balances. With luck
this means no multi-day wait for balances to match up.
|
|
|
|
This is a direct-bank-deposit, such as when doing an IBAN payment to
ones own account. There are no details at all available in the message
from paypal, so just make one up and fake the email, like we do with
paypal withdrawals.
|
|
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.
|
|
|
|
|
|
Seems there are also cases where there is no name on the paypal
transaction (again inconsistently). So if we have exchausted all known
ways to find the name, just fall back and set it to the email.
|
|
Seems code T1106 *sometimes* has an email address, and sometimes not,
attached to it. It's not documented when these differ, so just try to
get it and if it fails fall back to our own email address.
|
|
Yet another event code that started appearing. Previously, chargebacks
were posted as refunds.
|
|
|
|
They may look similar in some places, but are different in others.
|
|
Apparently you get "subscriptino payments" from people even if you don't
support subscriptions. It shows up if somebody voluntarily sets up for
example a monthly donation (as far as I can tell, I can't find any
documentation about it)
|
|
Trap errors and show them instead of just crashing with a json key
lookup error. In passing, also store the tokenscope in a member variable
on the API in case it's needed later.
|
|
The API we've been using has been deprecated for a while, and they've
now apparently started randomly dropping parts of it. So bite the bullet
and migrate to the new one. This is a bit cleaner for some things, lots
of things are missing, and transactions take several hours before they
show up in the reporting parts of it. Luckily, those parts are only used
in cronjobs running every few hours anyway...
There are new transaction codes for everything, so there are probably
some missed. There are also new and fancy inconsistencies in the
different ways that transaction texts can be reported, so there are most
likely some missed cases, but the common ones are covered.
Regular payment information is still using the PDT system (which is
independent of both APIs) and should not be affected. Only the fetching
of transactions, balances and issuing of refunds are.
NOTE: This requires reconfiguration of all paypal integrations. Instead
of api user/password/signature, an OAuth client and secret is used, and
the app itself has to be registered on each account. Instructions are in
the documentation.
|
|
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.
|
|
|
|
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.
|
|
It has been deprecated, and instead we should use "in" and "not in", so
make that change across the board.
|
|
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
That's what I get for not properly testing, yes...
|
|
This should decrease/remove the risk of losing track of where we are
when something goes wrong in the other integrations or when we fail to
properly track the summaries.
|
|
It seems that sometimes transactions come in starting from 1 and
sometimes from 0. Previously we'd just skip the 0 (and we would usually
find it once the *next* transaction came in). For now if there is no 0,
just retry on 1 as the starting number before giving up.
|
|
This means a few things:
1. We track refunds properly. Each invoice can be refunded once, but we now
also support partial refunds (which is important, as almost every refund we
make on a conference registration ends up being a partial one - if nothing
else it is deducted transaction fees).
2. We support API initiated refunds. That means that as long as the payment is
done using a supported provider (today that means Adyen and Paypal), the
complete invoice processing is done in the webapp, which means there is no
risk of getting the wrong numbers into the accounting (which has happened more
than once).
3. We now generate proper refund notices in PDF format for all refunds (both
automated and manual). The user receives this one as well as status updates
throughout the refund process.
Actual API refunds are handled by a new cronjob, to ensure that we don't end up
blocking the user if the API is slow. Initiating the refund puts it on the queue,
the cronjob sends it to the provider, and the notification from the provider
flags it as completed (and generates the refund notice).
|
|
Don't just return an empty resultsset (like "no new tranasctions"),
throw an actual exception.
|
|
Centralizes Paypal API calls, which we will need for some other things
|
