| Age | Commit message (Collapse) | Author |
|---|
|
Due to the new transferwise restrictions, creating payouts would crash.
This change attempts to make it complete the parts that work and leave
the rest for a manual approval in the transferwise web interface,
hopefully keeping the rest of the system working.
When half way complete, send a notification to the user to go complete
it manually.
|
|
Turns out we need to do this both for primary ands secondary amounts
(which makes sense). Clarify the comment a bit further after more
research that still shows Wise API returns that incoming payments are
actually outgoing. Sigh.
|
|
It's just for display and they're easier to identify this way.
|
|
Unfortunately, Wise decided one is no longer allowed to access
information about ones own transactions when in Europe, unless
registered as a European payment provider. This is of course stupid, but
what can we do.
Attempt to re-implement the transferwise support over their new
activities API.
Unfortunately there are likely bugs still hiding around, since for
example amounts are now returned in some self-invented html-like markup
like '<positive> 2,000 EUR</positive>' instead of as a number like
before (and sometimes they are returned as <positive> with a negative
number inside). But we have to start somewhere...
Unfortunately, it seems there's a permanent loss of funcionality in that
the account number (IBAN) of the sender is no longer available anywhere
in the API. This means that in practice, automatic refunds of transfers
are no longer possible. (This information appears to also no longer be
available on their website). We keep the refund functionality itself in
the system for now, as we might want to extend it later with the ability
to refund while manually specifying an IBAN number.
|
|
|
|
Our check only worked properly if the primary currency was the one we
used, and it seems wise can open a new balance and just chance the
primary currency on us, so update the check.
|
|
|
|
This becomes a requirement on Oct 1 to support statement fetching (which
we use both to update accounting and to fetch monthly statements) and
for funding transfer requests (which we use for refunds and payouts).
Initially it's optional and has to be enabled separately in the
transferwise account.
This method uses a RSA public/secret keypair (stored on the invoice
payment method, so this needs to be generated before the requirement can
be enabled, and the public part of the key needs to be uploaded) to sign
a token when making the request. Note that the actual request itself is
not signed, only the login.
Fixes #56, though the funding is not fully tested yet due to the sandbox
not containing all functionality and no payments being queued up in
production.
|
|
Apparently it's forbidden to create recipients with only one name, there
has to be at least two parts separated by a space (but can be more than
two parts). If this happens, just duplicate the name with a space in
between, as the name of the recipient is actually completely irrelevent.
|
|
This will work differently for conferences and non-conferences once we
add proper timezone support, so abstract it out into a separate couple
of functions. For now they both return the same thing, but this will
change in a later commit.
In passing, fix missing datetime.now() -> timezone.now() conversions.
|
|
It seems there are more combinations in names that are OK to receive
from but not OK to send to... Since the name isn't compared to anything,
just replace the comma with a space. (This is similar to 954fb04c4 which
disallowed digits)
|
|
TransferWise doesn't send statements automatically, and downloading them
is limited by the single-user-per-account-system. But since their API
allows downloading of a PDF statement between arbitrary dates, use that
to download the statements once per month and email them as an
attachment.
The function is optional and turned on/off on a per-paymentmethod basis.
|
|
The native one can't convert Decimal, which we use everywhere. It's
unknown how this ever worked, since we have always passed in decimals
and it causes a local exception. For now, switch to the Django
serializer which *can* deal with decimal.
|
|
Apparently TW does not allow for digits in the name of a recipient, for
reasons unknown. Just remove them and leave it empty, as the actual name
isn't validated by the API anyway.
|
|
This separates out the "send money" functionality into a separate
function and makes refund_transaction() call this one with refund
specific details.
|
|
|
|
This uses the TransferWise REST API to get access to an IBAN account,
allowing "traditional" bank paid invoices to be reasonably automated.
The provider integrates with the "managed bank transfer" system, thereby
handling automated payments using the payment reference. Since this
reference is created by us it can be printed on the invoice, making it
easier to deal with in traditional corporate environments. Payments that
are incorrect in either amount or payment reference will now also show
up in the regular "pending bank transactions" view and can be processed
manually as necessary.
For most SEPA transfers, TransferWise will be able to provide the IBAN
number to the sending account. When this is the case, the provider also
supports refunds, that will be issued as general IBAN transfers to tihs
account. Note that refunds requires the API token to have "full access"
as it's permissions in the TW system, meaning it can make arbitrary
transfers of any funds. There is no way to specifically tie it to just
refunds, as these are just transfers and not payments.
|
