pay-now/paynow-php-sdk

Bazowanie na paymentId w przypadku podnoszenia płatności nie jest dobrym rozwiązaniem brakuje funkcjonalności

Opened this issue · 4 comments

designezpl commented

Scenariusz pozytywny

  1. Dodawanie płatności - otrzymujemy zwrotnie paymentId (XXX-XX-XX-XX), status (NEW), redirectUrl
  2. za pomocą redirectUrl przekierowujemy klienta do bramki
  3. klient opłaca i wraca. Sprawdzamy z URL paymentId ?paymentId=XXX-XX-XX-XX&paymentStatus=CONFIRMED.
  4. Sprawdzamy status płatności wykorzystując paymentId przez API i mamy informacje o wpłacie do konkretnego zamówienia (oczywiście paymentId XXX-XX-XX-XX rejestrujemy w bazie podczas tworzenia płatności aby odpytać API o status płatności i porównać z URL powrotu).

Scenariusz problematyczny

  1. Dodawanie płatności - otrzymujemy zwrotnie paymentId (XXX-XX-XX-XX), status (NEW), redirectUrl
  2. za pomocą redirectUrl przekierowujemy klienta do bramki
  3. klient ma problem z płatnością (błędny BLIK czy cokolwiek). Ponawia płatność i po stronie bramki generuje się nowy paymentId (YYY-YY-YY-YY). Załóżmy, że zapłaci i wraca do sklepu ale jego paymentId to YYY-YY-YY-YY. Sprawdzamy z URL paymentId ?paymentId=YYY-YY-YY-YY&paymentStatus=CONFIRMED. Symbol XXX-XX-XX-XX ma status ABANDONED i nie ma żadnych informacji o powiazaniu YYY-YY-YY-YY z XXX-XX-XX-XX
  4. Sprawdzamy status płatności wykorzystując paymentId powrotu YYY-YY-YY-YY ( ?paymentId=YYY-YY-YY-YY&paymentStatus=CONFIRMED). I nie możemy z niczym tego powiązać.

Na początku utrzymujemy paymentId XXX-XX-XX-XX (przykład) następnie podczas podnoszenia płatności w bramce (poza sklepem) tworzona jest nowa sesja YYY-YY-YY-YY. ?paymentId=YYY-YY-YY-YY&paymentStatus=CONFIRMED. Do czego podpiąć YYY-YY-YY-YY my nie mamy informacji jakiej transakcji to dotyczy.

Jak wykonać zwrot kiedy to też bazuje na paymentId? My mamy informacje o XXX-XX-XX-XX a nie o YYY-YY-YY-YY
Rozwiązanie kiedy ktoś musi łączyć wpłaty logując się do panelu jest słabe.

paynow-support commented

Dzień dobry,

dziękujemy za zgłoszenie. Podnoszenie płatności, a co za tym idzie ich wiązanie, bazuje na parametrze externalId. Po krótce wygląda to tak:

  • w przypadku podnoszenia, przy tworzeniu się nowej płatności wyślemy notyfikację z takim samym externalID jak przy starej, porzuconej płatności,

  • czyli płatność porzucona i podnoszona jest połączona tym samym externalId,

  • na podstawie notyfikacji NEW i przesłanym w niej externalId następuję połączenie płatności i zamówienia.

Szczegółowo opisany ten proces jest w dokumentacji:
https://docs.paynow.pl/#section/Payments/Payment-recovery

W razie dodatkowych pytań, pozostajemy do dyspozycji.

Zespół paynow

designezpl commented

"w przypadku podnoszenia, przy tworzeniu się nowej płatności wyślemy notyfikację z takim samym externalID jak przy starej, porzuconej płatności," - notyfikacje gdzie? Na adres powrotu sklepu?
"czyli płatność porzucona i podnoszona jest połączona tym samym externalId" - owszem ale po waszej stronie a nie w API. Niestety wszystko bazuje na paymentId który się zmienia. Odpytanie o status również bazuej na paymentId, więc słabo.

paynow-support commented

Dzień dobry,

notyfikacje wysyłamy na ustalony adres powiadomień. W standardowym procesie, to wysyłane przez nas powiadomienia są źródłem wiedzy o statusie transakcji, a nie odpytania z Państwa strony. Zachęcamy do skorzystania z funkcji powiadomień - z pełnym opisem ich działania zapoznają się Państwo w dokumentacji: https://docs.paynow.pl

externalId jest wartością niezbędną dla requestu płatności i po stronie API łączy ze sobą transakcje. Jeżeli skonfigurują Państwo adres powiadomień, problem z łączeniem transakcji zniknie.

z pozdrowieniami,
zespół Paynow

designezpl commented

Faktycznie przychodzi takie powiadomienie i tam wszystko jest. Dokumentacja jest bardzo uboga w tej kwestii powinniście to rozszerzyć. Pozdrawiam