Add external Payments (BankTransfer, DirectPayment)

[devkral]

Sometimes it is useful to have placeholders for certain payments (BankTransfer and manual cashing process). I provide here two Providers for this purpose: DirectPaymentProvider: versatile Provider, for e.g. voucher systems or cash on delivery. BankTransferProvider: for normal bank transfers. Some other logic has to validate payments

This pull request depends on the pull requests: https://github.com/mirumee/django-payments/pull/148, https://github.com/mirumee/django-payments/pull/149

[codecov-io]

Codecov Report

Merging #152 into master will increase coverage by 1.83%. The diff coverage is 87.34%.

@@            Coverage Diff             @@
##           master     #152      +/-   ##
==========================================
+ Coverage   79.13%   80.97%   +1.83%     
==========================================
  Files          27       30       +3     
  Lines        1649     1819     +170     
  Branches      190      204      +14     
==========================================
+ Hits         1305     1473     +168     
+ Misses        245      239       -6     
- Partials       99      107       +8

Impacted Files	Coverage Δ
payments/sofort/__init__.py	87.71% <ø> (-1.17%)	:arrow_down:
payments/braintree/forms.py	93.1% <100%> (+0.51%)	:arrow_up:
payments/stripe/__init__.py	60% <100%> (ø)	:arrow_up:
payments/stripe/forms.py	96.92% <100%> (+0.09%)	:arrow_up:
payments/paypal/__init__.py	84.58% <100%> (ø)	:arrow_up:
payments/testcommon.py	100% <100%> (ø)
payments/dummy/__init__.py	86.79% <100%> (ø)	:arrow_up:
payments/cybersource/__init__.py	66.56% <100%> (+0.1%)	:arrow_up:
payments/authorizenet/__init__.py	86.11% <100%> (+6.56%)	:arrow_up:
payments/core.py	87.69% <100%> (ø)	:arrow_up:
... and 11 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 49c93aa...b613ba0. Read the comment docs.

[iraycd]

I have been waiting for this. @devkral thank you.

[xponrails]

@devkral , great job. Can you provide an external repository with this PR yet merged in the latest version of django_payments so I can clone it as is and use in my saleor project? I would like to wait an "official" merge by mirumee but I don't think it happens in the next few days :-)

[devkral]

the state is also very unsatisfying for me. I solved all problems but no feedback (may I changed too much). I can do and think about a fork.

[patrys]

Would you mind submitting the API changes as a separate pull request? We generally encourage third-party payment gateway to release separate packages (as we usually have no way to test and maintain them) but it seems that you've also refactored parts of the existing API which we'll be happy to review.

See https://github.com/esistgut/django-payments-bnlepos for an example of a payment implementation that lives in a separate package.

[devkral]

I really would like to but I depend on some pull requests which were not integrated: see devkral in prs

[devkral]

I started my fork. I think it is the best thing because I can eliminate bad design decisions this way. @patrys I can understand your decision as you represent a company. You want most probably not so many big changes to a system which is in production. anyway here the link: https://github.com/devkral/web-payments-connector

[devkral]

@patrys I pushed the PRs I required separately and waited 6 months now with no response.

[devkral]

And anyway the changes I would really like to integrate are too heavy weight. It is not realistic that you will ever integrate them (breaking api into small chunks, renaming payments to web_payments because of name conflicts, non-django framework support)

[zchking]

HI, any update?

[devkral]

yes, integration will unlikely happen, so I put all my efforts into my fork (see above), which is stable now. Still need to port backends.

[patrys]

Just to reiterate: there is no reason for all backends to live in this repository. The code was built in a way that makes loading third party backends no different from loading the first party ones. You don't need to fork to maintain a custom backend. If the core needs to change for a backend to work then we're looking forward to patches but we can't possibly take over maintenance of all possible bank and payment gateway integrations as we're only humans, I hope that does not surprise anyone 😄

[devkral]

that's absolutely true but I was too headstrong with my ideas :). And anyway, flask support and a test project to develop backends with is cool.