get '/kam' => 'payments#comeback'
Jest parameter get
Trochę dziwne bo https://sandbox.przelewy24.pl/trnVerify zwraca odpowiedź (bez danych) jakby w innym formacie niż jest opisany w dokumentacji. A teraz to w ogóle nic nie zwraca.
http://downforeveryoneorjustme.com/www.przelewy24.pl
It’s not just you! http://www.przelewy24.pl looks down from here.
Chyba trafiłeś po prostu na weekendowe problemy w p24 
Teraz faktycznie nawet ich strona główna przestała na chwilę działać ale już się podniosła. Kurcze jak dla mnie to coś u mnie musi nie grać bo musiałbym mieć okropnego pecha z tymi przerwami w P24, od czwartku próbuje coś w tym temacie podziałać i ciągle dostawałem ten sam błąd 
Przede wszystkim dziwne jest to, że nie p24 nie przesyłają parametrów wraz z przekierowaniem POST (jak to robili dotychczas w trybie testowym)- przez co, przy braku parametrów wspomniana wyżej metoda zwraca {} więc wykorzystywana odpowiedź z tej metody generuje brakujące pola przy weryfikacji i wtedy z kolei p24 zwracają odpowiedź w innym niż format określony w dokumentacji np.
error=err054&errorMessage=Niezgodność kwoty transakcji
I przy próbie interpretacji błędnie zbudowanej odpowiedzi wyskakuje błąd, o którym piszesz.
aaaa!
metoda ‘comeback’ powinna byc POST!
czyli
post '/kam' => 'payments#comeback'
Po zmianie na POST i wykonaniu transakcji po przekierowaniu otrzymuję błąd
No route matches [GET] "/kam"
Tak jak już wspomniałem, kiedyś pierwsze przekierowanie było także POST i w środowisku developerskim/sandbox przekazywało te same parametry co w żądaniu zwrotnym. Teraz jeszcze przejrzałem dokumentacje i jest jasno określone, że już tak nie jest:
5.4 Odbiór wyniku transakcji
W zależności od wyniku transakcji wywołany zostanie jeden z przekazanych do systemu Przelewy24.pl adres url:
Transakcja prawidłowa
Wywołany adres url: p24_url_return. Wywołanie następuje gdy nastąpiła prawidłowa wpłata przez klienta.
W przypadku przekierowań dla transakcji poprawnej i niepoprawnej – nie są wysyłane żadne dodatkowe pola. Jest to zwykłe przekierowanie metodą GET. Informacja o płatności jest wysyłana wyłącznie na adres p24_url_status.
Czyli powinieneś ustawić dwa niezależne adresy:
config.url_status = '/kam'
config.url_return = '/finish' #ale i tak go nadpiszesz każdorazowo
# routes.rb
post '/kam' => 'payments#comeback'
get '/finish' => 'payments#finish'
A dla testów żądań zwrotnych/Informacja o płatności musisz uruchomić aplikację dostępną normalnie w sieci by autotmat p24 mógł wysłać do Ciebie zapytanie.
A na ekranie finish powinno być coś takiego:
Trwa przetwarzanie płatności
A adres p24_url_return, możesz tworzyć dla każdej płatności osobno - dzięki temu po powrocie użytkownika będziesz mógł rozpoznać na którą płatność czeka.
Czyli po prostu w kontrolerze payments zrobić pustą akcję
def finish
end
Ustawić routes.rb tak jak napisałeś i aby przestestować sprawność muszę to zrobić w środowisku produkcyjnym w mojej aplikacji która normalnie funkcjonuje w sieci, tak?
Czyli wychodzi na to, że w środowisku developerskim nie da się przeprowadzić poprawnie transakcji która zostanie poprawnie zweryfikowana w panelu sandboxa.
@Wacaw wielkie dzięki za dotychczasową pomoc, jest już spory progres, przelewy24 zwracają dane ale nie dochodzi do weryfikacji transakcji ani do uruchomienia akcji payment_success
I, [2017-03-21T19:48:21.713683 #68391] INFO -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] Rendering payments/show.html.erb within layouts/application
I, [2017-03-21T19:48:21.730328 #68391] INFO -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] Rendered vendor/bundle/ruby/2.3.0/gems/przelewy24_payment-0.2.0/app/views/przelewy24_payment/_payment_form.html.haml (13.1ms)
I, [2017-03-21T19:48:21.730502 #68391] INFO -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] Rendered payments/show.html.erb within layouts/application (16.7ms)
D, [2017-03-21T19:48:21.733232 #68391] DEBUG -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] e[1me[36mUser Load (0.3ms)e[0m e[1me[34mSELECT "users".* FROM "users" WHERE "users"."id" = ? ORDER BY "users"."id" ASC LIMIT ?e[0m [["id", 1], ["LIMIT", 1]]
I, [2017-03-21T19:48:21.733924 #68391] INFO -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] Rendered layouts/_footer.html.erb (0.0ms)
D, [2017-03-21T19:48:21.735089 #68391] DEBUG -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] e[1me[36mPost Load (0.5ms)e[0m e[1me[34mSELECT "posts".* FROM "posts" ORDER BY created_at desc LIMIT ?e[0m [["LIMIT", 4]]
I, [2017-03-21T19:48:21.736212 #68391] INFO -- : [3fa6808d-28fa-4f73-b150-c5c2c4a6ed76] Completed 200 OK in 28ms (Views: 22.0ms | ActiveRecord: 1.2ms)
I, [2017-03-21T19:48:30.422233 #68391] INFO -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] Started POST "/kam" for 91.216.191.182 at 2017-03-21 19:48:30 +0100
I, [2017-03-21T19:48:30.423090 #68391] INFO -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] Processing by PaymentsController#comeback as */*
I, [2017-03-21T19:48:30.423157 #68391] INFO -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] Parameters: {"p24_session_id"=>"TepBHwqth2WVzLK7296x", "p24_amount"=>"2400", "p24_order_id"=>"109119688", "p24_pos_id"=>"58769", "p24_merchant_id"=>"58769", "p24_method"=>"25", "p24_statement"=>"p24-D09-119-688", "p24_currency"=>"PLN", "p24_sign"=>"5be0ee432827eecb7c76734494e36d15"}
D, [2017-03-21T19:48:30.470381 #68391] DEBUG -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] e[1me[36mPayment Load (0.2ms)e[0m e[1me[34mSELECT "payments".* FROM "payments" WHERE "payments"."session_id" = ? ORDER BY "payments"."id" ASC LIMIT ?e[0m [["session_id", "TepBHwqth2WVzLK7296x"], ["LIMIT", 1]]
I, [2017-03-21T19:48:31.095539 #68391] INFO -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] No template found for PaymentsController#comeback, rendering head :no_content
I, [2017-03-21T19:48:31.095800 #68391] INFO -- : [cb327ce7-a26d-4c27-8c85-90d1713ec142] Completed 204 No Content in 673ms (ActiveRecord: 0.2ms)
I, [2017-03-21T19:48:31.882970 #68391] INFO -- : [8ff4fb77-0bdf-4520-b5d5-4c6f7e870229] Started GET "/finish" for 109.173.154.202 at 2017-03-21 19:48:31 +0100
I, [2017-03-21T19:48:31.883629 #68391] INFO -- : [8ff4fb77-0bdf-4520-b5d5-4c6f7e870229] Processing by PaymentsController#finish as HTML
I, [2017-03-21T19:48:31.885201 #68391] INFO -- : [8ff4fb77-0bdf-4520-b5d5-4c6f7e870229] Rendering payments/finish.html.erb within layouts/application
I, [2017-03-21T19:48:31.885542 #68391] INFO -- : [8ff4fb77-0bdf-4520-b5d5-4c6f7e870229] Rendered payments/finish.html.erb within layouts/application (0.2ms)
Oto log z przeprowadzenia płatności, gdy dodałem dla comeback pusty widok oczywiście nie pokazywał się ten błąd jednak płatność nadal nie była weryfikowana.
edit.
Jeszcze wcześniej w logach występował błąd
Can't verify CSRF token authenticity.
z którym sobie poradziłem dodając na początku kontrolera płatności
skip_before_action :verify_authenticity_token
Jeśli chodzi o akceptowanie przyjmowania danych bez tokenu CSRF to akceptuj to tylko dla tej pojedynczej akcji, byś resztę miał zabezpieczoną, czyli
# zamisat
skip_before_action :verify_authenticity_token
# powinno byc
protect_from_forgery :except=> [:comeback]
Teoretycznie metoda comeback powinna wysłać potwierdzenie do Przelewy24 i wywołać odpowiednią funkcję na podstawie wyniku. Skoro twierdzisz, że podane transakcje dalej nie zostały odebrane (czyt. jest jakiś błąd) to teraz musisz sobie wyświetlić błędy używając funkcji payment_error, np. coś z tego:
def payment_error(payment_params, code, description)
# puts code
# puts description
# P24Transaction.find_by_session_id(payment_params[:p24_session_id]).update(status: 'rejected', error_code: code, error_message: description)
head 200
endZabezpieczenia już poprawione
Ale jakby nie patrzeć to żadne błędy nie wyszły
I, [2017-03-21T21:15:50.514954 #24717] INFO -- : [910a9d96-4adf-44f4-8f41-ac78e85c0a73] Started POST "/kam" for 91.216.191.182 at 2017-03-21 21:15:50 +0100
I, [2017-03-21T21:15:50.516164 #24717] INFO -- : [910a9d96-4adf-44f4-8f41-ac78e85c0a73] Processing by PaymentsController#comeback as */*
I, [2017-03-21T21:15:50.516259 #24717] INFO -- : [910a9d96-4adf-44f4-8f41-ac78e85c0a73] Parameters: {"p24_session_id"=>"cyXhTxyhh3qzZeEe9JxS", "p24_amount"=>"2400", "p24_order_id"=>"109119709", "p24_pos_id"=>"58769", "p24_merchant_id"=>"58769", "p24_method"=>"146", "p24_statement"=>"p24-A09-119-709", "p24_currency"=>"PLN", "p24_sign"=>"55fcfc368be3b4dec5bf3406126c6c22"}
D, [2017-03-21T21:15:50.595574 #24717] DEBUG -- : [910a9d96-4adf-44f4-8f41-ac78e85c0a73] e[1me[36mPayment Load (0.2ms)e[0m e[1me[34mSELECT "payments".* FROM "payments" WHERE "payments"."session_id" = ? ORDER BY "payments"."id" ASC LIMIT ?e[0m [["session_id", "cyXhTxyhh3qzZeEe9JxS"], ["LIMIT", 1]]
I, [2017-03-21T21:15:50.975003 #24717] INFO -- : [910a9d96-4adf-44f4-8f41-ac78e85c0a73] Completed 200 OK in 459ms (ActiveRecord: 0.2ms)
I, [2017-03-21T21:15:51.754353 #24717] INFO -- : [cdcc78a1-9874-4d65-8895-4f9604943314] Started GET "/finish" for 109.173.154.202 at 2017-03-21 21:15:51 +0100
Nie mam już kompletnie pomysłu co może być nie tak, w sandboxie nadal wszystkie transakcje widnieją jako do wykorzystania
Już działa! 
Przyczyną była źle ustawiona kwota zamówienia w payment_verify, płatność jest poprawnie weryfikowana i potwierdzana, wszystko pięknie ale został mi jeszcze jeden mały problem, mianowicie z akcją payment_success
def payment_success
payment = Payment.find_by_session_id(payment_params[:p24_session_id])
payment.status = "Sporządzanie porady"
end
Chciałbym aby status płatności zmieniał się na “Sporządzanie porady” ale w logach otrzymuje błąd
ArgumentError (wrong number of arguments (given 0, expected 1)):
Mam nadzieję, że to ostatnie ogarnąłeś! Bo
ArgumentError (wrong number of arguments (given 0, expected 1)): - czyli błąd związany z argumentami (błędna liczba arugmentów (podano 0, oczekiwano 1)) znaczy dokładnie to co znaczy 
zabrakło parametru w definicji metody, powinno być:
def payment_success(payment_params)