Bramka płatnicza - zasady działania, HTTP

Witam,
piszę pracę dyplomową. Rozwiązania biznesowe w transakcjach internetowych.

Próbuje rozwikłać działanie aplikacji, sklepu do którego działania używana jest bramka płatnicza. Szukałem informacji na temat na próżno :(

Przykładowo: mam aplikację, gdzie warstwa serwisowa podczas dokonywania płatności przekierowuje mnie do bramki, gdzie rejestrowana jest transakcja. Formularz i jego obsługę programuje na poziomie własnej aplikacji. Użytkownik, który dokona zakupu, przejdzie po skompletowaniu zamówienia do bramki - tak to chyba działa. Wysyłam żądzanie GET na podstawie formularza i będę potrzebował po rejestracji płatności jakiegoś powrotu z bramki callback, funkcja zwrotna. Płatność powinna zostać zajestrowana w systemie i no super.

Kompletnie jednak nie rozumiem, gdzie przechodzą te dane, jak działa protokół HTTP, gdzie znajduje się oczekująca transakcja gdy przejdę do bramki. Gdzie to siedzi, w ciasteczku? Jak zobaczyć te dane? i jak działa do licha ta bramka, poza aplikacją a jednak razem.

Proszę o pomoc w szukaniu informacji, nie chodzi mi tylko o dokumentację np. dotpay ale coś jeszcze :)

To zacznij od protokołu HTTP i przekierowań, parametrów wywołania HTTPS. Bo tu by trzeba książkę napisać.

Bramki działają zazwyczaj w bardzo prosty sposób:
Kiedy ktoś chce zapłacić u Ciebie za jakiś produkt, przekierowujesz go do bramki, podając w zapytaniu takie dane jak kwota, nazwa transakcji, email klienta, ale też Twoje ID, które dostałeś od dostawcy bramki i ew. jakiś dodatkowy klucz, który musisz sobie w ich panelu wygenerować. W ten sposób bramka wie, że to jest płatność dla Ciebie i potem na tej podstawie będzie wypłacać Ci pieniądze (bo to nie jest tak, że dostajesz te pieniądze od razu. Musisz poczekać na przelew od dostawcy bramki, ja mam je ustawione przykładowo na 4x w miesiącu).
W tym przekierowaniu do bramki podajesz też adres dla callbacku i jeśli transakcja się zakończy to bramka przekieruje użytkownika na ten właśnie adres, zazwyczaj dodając jako parametr URLa status płatności, np. że się powiodła i Ty po swojej stronie musisz to przekierowanie i parametr obsłużyć.
Jak dobrze pamiętam to zazwyczaj są to zapytania GET, więc wszystkie dane przesyłasz po prostu w adresie.

Nie ma tutaj żadnej magii, która by jakoś specjalnie łączyła oba serwisy.

Dziękuje za pomoc, coś tam rozumiem jednak UglyMan na razie nie wszystko :) czasem trudno opisać problem :)

"W tym przekierowaniu do bramki podajesz też adres dla callbacku i jeśli transakcja się zakończy to bramka przekieruje użytkownika na ten właśnie adres".

W zasadzie nie rozumiem powyższego zdania i to stanowi problem :)

Chodzi o to że przechodząc na inna domene - masz sklep w domenie abc.pl a przechodzisz do paymyorder.pl to obsłużeniu płatności paymyorder musi wiedzieć gdzie wrócić do twojego sklepu ze statusem płatności. Takie rzeczy robi się w konfiguracji konta u operatora płatności. Podajesz link do swojego sklepu. Coś w stylu abc.pl/pozaplacie/id=id_transacji/status=status_płatności i wtedy wiesz, czy udało sie opłacić zamówienie czy nie.

A może to tego mi brakuje:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

:)

Zobacz sobie coś takiego:
https://www.evoluted.net/thinktank/web-development/paypal-php-integration
Prosto wytłumaczone, nawet jak nie znasz PHPa.

Możesz też spojrzeć sobie na znacznie lepiej udokumentowany oauth 2 authorization code flow - zasada działania jest identyczna, z tym że zamiast płatności masz logowanie i dawanie apce dostępu do różnych rzeczy, a zamiast statusu transakcji dostajesz token do autoryzacji.