Aplikacje/moduły do obsługi płatności w Django

[bt]

Witam,

Na początku chciałbym Was gorąco przywitać!

Chciałbym Was zapytać o opinie i ewentualne implementację modułów
płatności internetowych takich jak PayU (kiedyś platnosci.pl) /
przelewy24.pl / PayPal w Django. Odnośnie platnosci.pl i PayPal
znalazłem coś w internecie choć nie wiem czy te implementację są
bezpieczne na tyle aby powierzyć im obrót gotówki, może Wy używaliście
którejś z nich i możecie się podzielić swoimi doświadczeniami.
Aplikacje, które odnalazłem to do platnosci.pl:
https://github.com/mpasternacki/django-platnoscipl -> ta aplikacja nie
jest rozwijana już od 3 lat więc może być przestarzała oraz
http://code.google.com/p/django-platnosci/ -> tutaj twórcy piszą by
nie używać ich do rzeczywistych przelewów. Znalazłem również coś na
temat PayPal.

Serdecznie proszę Was o opinie czy te aplikację do platnosci.pl są
aplikacjami, którym warto powierzyć obrót gotówką a może ktoś z Was
napisał jakiś własny bezpieczny moduł i chciałby się nim podzielić.
Serdecznie proszę o jaką kolwiek radę bądź przykład, miło by było
również gdybyście wypowiedzieli się na temat który system płatności
internetowej według Was najlepiej spełnia się w polskiej
rzeczywistości.

Pozdrawiam

[KubAT]

Jakbyś chciał sam pisać to patrząc na dokumentacje tych serwisów płatnościowych pół roku temu najprostszy do implementacji wydawał mi sie dotpay.

I tu jest też coś takiego
http://pypi.python.org/pypi/django-dotpay/0.2.1

ale repo z githuba zniknęło

[haloween]

Ja mam napisany i produkcyjnie dzialajacy platnosci.pl/payu
Konfiguracja PP z poziomu panelu django etc ...

Generalnie dzien siedzenia.

Pozdr

On Mar 25, 10:20 pm, bt <scr34...@gmail.com> wrote:
> Witam,
>
> Na początku chciałbym Was gorąco przywitać!
>
> Chciałbym Was zapytać o opinie i ewentualne implementację modułów
> płatności internetowych takich jak PayU (kiedyś platnosci.pl) /
> przelewy24.pl / PayPal w Django. Odnośnie platnosci.pl i PayPal
> znalazłem coś w internecie choć nie wiem czy te implementację są
> bezpieczne na tyle aby powierzyć im obrót gotówki, może Wy używaliście
> którejś z nich i możecie się podzielić swoimi doświadczeniami.

> Aplikacje, które odnalazłem to do platnosci.pl:https://github.com/mpasternacki/django-platnoscipl-> ta aplikacja nie
> jest rozwijana już od 3 lat więc może być przestarzała orazhttp://code.google.com/p/django-platnosci/-> tutaj twórcy piszą by

[citos88]

Ja stosuje właśnie ten moduł http://code.google.com/p/django-platnosci/ z jakimiś swoimi małymi zmianami (bez celery) i na produkcji jest jak najbardziej ok :)

[perpetoom]

Repozytorium django dot-pay zostało przeniesione do https://github.com/hoffmannkrzysztof/django-dotpay

[Krzysztof Dorosz]

Witam,

może przyda się komuś informacja, że powstała nowa aplikacja "django-getpaid", która ma na celu być uniwersalną logiką obsługi płatności za zamówienie w django, opierająca się na mechanizmie backendów obsługujących dowolne systemy płatności. Aplikacja zawiera dokumentacje i testy.

kod źródłowy - https://github.com/cypreess/django-getpaid

dokumentacja - http://django-getpaid.readthedocs.org/en/latest/

Pakiet jest także dostępny w standardowym systemie pakietowym Pythona PyPi

http://pypi.python.org/pypi/django-getpaid/

Na chwilę obecną podpięte są backendy PayU.pl (dawne Platnosci.pl) oraz Transferuj.pl

Pozdrawiam

DK

[Tomek Kiedos]

Hej, bardzo fajna wiadomość :)
Czy jest już jakieś produkcyjne (czytaj: przetestowane) wdrożenie oparte na tym? :)

--
Otrzymujesz tę wiadomość, ponieważ subskrybujesz grupę dyskusyjną Google o nazwie „django-pl - grupa polskiej społeczności Django”.

Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msg/django-pl/-/y4vx90Fl3E0J.

Aby zamieszczać posty w tej grupie, wyślij e-mail na adres djan...@googlegroups.com.
Aby anulować subskrypcję tej grupy, wyślij e-mail na adres django-pl+...@googlegroups.com.
Aby uzyskać więcej informacji, odwiedź tę grupę pod adresem http://groups.google.com/group/django-pl?hl=pl.

[Krzysztof Dorosz]

Wersja 1.1.1 powinna być juz production ready - aczkolwiek nie wdrozylem jeszcze softu opartego na tej apce.  Niedlugo bedzie. Zmiany jakis sie spodziewam ew jeszcze to poza modulami backendow, dodanie jakis helperów (ulatwiajacych typowe czynności), lepszego logowania.

Co do backendu PayU (Platnosci.pl) warto zwrocic uwage ze wykorzystuje django-celery task, wiec nie odpytuje synchronicznie ich serwera podczas requestu "online" o dane transakcji, tylko robi to asynchronicznie, co sprawia ze bedzie to duzo stabilniejsze rozwiazanie.

DK

[3mpty]

Mógłbyś udostępnić przykład projektu dla PayU? Próbowałem podpiąć się do konta na sandboxie PayU (konfiguracja backendu dodana, plus jednostka płatności PLN) i po przekierowaniu na stronę PayU dostaję kod błędu 201.

[Łukasz Rekucki]

201 to nie jest kod bledu tylko poprawna odpowiedz oznaczajaca ze zasob zostal stworzony.

[Krzysztof Dorosz]

Testowy projekt znajduje się tutaj:

https://github.com/cypreess/django-getpaid/tree/master/getpaid_test_project

Nie używałem tego z sandboxem PayU, ale na normalnym koncie działa bez zarzutów. Możesz ewentualnie podać jak dostać się do sandboxa tak żebym mógł przetestować po swojej stronie z sandboxem?

DK

 

Aby wyświetlić tę dyskusję w internecie, odwiedź stronę https://groups.google.com/d/msg/django-pl/-/04hghLXwy1AJ.

[Krzysztof Dorosz]

Skąd jest ta informacja?

Zgodnie z dokumentacją techniczną PayU http://www.payu.pl/sites/default/files/regulaminy_i_pliki/Dokumentacja_techniczna_systemu_PayU.pdf kod błedu 201 oznacza "inny chwilowy bład bazy". 

Możliwe więc, ze po prostu backend sandboxa im się wysypał podczas gdy 3empty go testował.

DK

On Oct 8, 2012, at 8:01 PM, Łukasz Rekucki wrote:

201 to nie jest kod bledu tylko poprawna odpowiedz oznaczajaca ze zasob zostal stworzony.

[Łukasz Rekucki]

2012/10/8 Krzysztof Dorosz <cypr...@gmail.com>:
> Skąd jest ta informacja?

Jak ktoś pisze, że od serwera dostaje jakiś kod to na ogół można
założyć, że chodzi o HTTP. Jeśli nie, to wypadałoby aby piszący np.
zamieścił odpowiedź.

Natomiast autorom API gratuluję wysysłanie odpowiedzi "200 OK" z
napisem "ERROR" w środku. I podpisów MD5 bez użycia HMAC. Good luck.

--
Łukasz Rekucki

[3mpty]

Troszkę ogarnąłem kod backendu i uświadomiłem sobie gdzie leży przyczyna, otóż sandbox jest całkowicie osobnym tworem, z osobną db, dlatego pluł błędem dot. db bo nie miał takiego poi.

Sandbox jest pod adresem: https://sandbox.payu.pl czyli inny gateway ale nie udało mi się zmusić gepaid do współpracy z sandboxem nawet po zamianie _GATEWAY_URL. Sandbox ma tą zaletę, że rejestracja jest bardzo szybka, wystarczy tylko potwierdzić via email.

Dla odmiany na normalnym koncie, po zaznaczeniu w panelu płatności testowych wszystko działa jak należy.

[Krzysztof Dorosz]

To jak wygląda to API to pozostawię bez komentarza. Jak chcesz więcej to zajrzyj do API z transferuj.pl :)

DK

[Krzysztof Dorosz]

Tak - ja właśnie nie testowałem rozwiązania na sandboxie, tylko na koncie produkcyjnym z włączoną płatnością testową (szczerze mówiąc nawet nie wiedziałem, że jest sandbox). Dziwne wobec tego, że sandbox nie działa z czymś co poprawnie działa z ich systemem produkcyjnym... 

DK

[3mpty]

Struktura ich serwisów jest tragiczna. Pytanie: czy to normalne, że każdy payment w trybie testowym zostaje mi 'in progress'? Po stronie płatności widnieją jako zakończone.

[blackbit]

Próbuję właśnie wykorzystać Twoją obsługę płatności w swoim projekcie (backend transferuj.pl). Generalnie wszystko działało ok, kiedy uruchamiałem aplikację lokalnie z DEBUG=True. Nie było problemów z płatnościami rzeczywistymi i testowymi. Problem pojawił się jednak po umieszczeniu aplikacji na serwerze testowym (DEBUG=False).

Poniżej najważniejszy fragment błędu jaki dostaję:

  File "/srv/panel/code/source/MyApp/urls.py", line 5, in <module>
    from GPShipment.views.orders import OrderView

  File "/srv/panel/code/source/MyApp/views/orders.py", line 2, in <module>
    from getpaid.forms import PaymentMethodForm

  File "/home/gsa/.virtualenvs/panel/local/lib/python2.7/site-packages/getpaid/forms.py", line 6, in <module>
    from getpaid.models import Order

ImportError: cannot import name Order

Moja implementacja oparta jest o przykład integracji z dokumentacji. Wygląda na to, że forms.py próbuje importować model, który nie jest zdefiniowany w ramach paczki getpaid (nie widzę go w getpaid/models.py). Definicja tego modelu znajduje się w mojej aplikacji, więc nie jest widoczna z poziomu getpaid/forms.py

W zasadzie, to wygląda na to, że problem ten istnieje przy DEBUG=True, jednak nie wiem czemu nie wyszło to wcześniej.

Czy masz jakieś sugestie lub pomysł na to, jak można to elegancko rozwiązać? Może błąd ten jest konsekwencją jakiegoś mojego niedopatrzenia podczas integracji?

Pozdrawiam,

blackbit

[Krzysztof Dorosz]

Wygląda to na jakiś problem importowania zbyt wcześnie. Order jest ustawiany w module getpaid.models dopiero po zawolaniu register_to_payment

Sprobuj przetestowac jeszcze kod z mastera na githubie (usunalem tam drobny bug z importami wlasnie). Najlepiej jakbys mogl pokazac przykladowy kod ktory powoduje ten problem.

DK

[blackbit]

Witam,

Dokładnie był to problem z importowaniem, który udało mi się już jakiś czas temu rozwiązać. Pomogło przeniesienie linijki:

from getpaid.forms import PaymentMethodForm

na koniec pliku z widokiem OrderView. Od tego momentu wszystko już działa jak należy.

Pozdrawiam,

blackbit