| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
This is a US based creditcard payment provider. Primarily to be used
by pgopen at this point, but added in a generic way so it can be reused
should someone else want it in the future.
The user flow of payment is slightly different from the previous
providers. Instead of sending the user to the payment site itself,
which we do for Adyen and Paypal, Braintree have decided to use client side
javascript. So the flow is.
1. Request a nonce using the braintree server side APIs, and render it in a form
2. The Braintree javascript will rewrite the creditcard number etc into a
secure token, that is submitted back to the site.
3. With this token, a transaction is generated server-side in the braintree
APIs, and the user is redirected to the payment completed page.
The transaction goes the same basic flow as the Adyen ones, with slightly
different terminlogy: Authorized -> Settled -> Disbursed
The first step is handled by the views in braintreepayment/views.py, and
the second two steps are both handled by the new cronjob in
tools/braintreepayment/update_transaction_status.py which should run
regularly (probably every 6 hours or so).
Another new cronjob, tools/braintreepayment/log_reporter.py, must be run
in order to get alerts for anything abnormal happening in the system. Really
bad things are emailed immediately, but most things are just logged as
errors and sent as an aggregated email by this script.
Note that unlike the other payment providers, the braintree module has
an external dependency. It requires the "braintree" module installed
(from pip or packages). For this reason, the braintree module is
disabled by default, and has to be enabled by setting the value
ENABLE_BRAINTREE=True in local_settings.py.
|
