How its works
To capture payment results via iframe, an event mechanism is used within the user's browser. It is separated into three stages:
Open the iFrame
...
We request a URL so that the user can make the payment and we place this url inside an iframe on our page. Now the user can see the fields and fill them in to make a purchase.
PSP handles the request and redirects the iframe to “specified url”
...
At this point, the PSP already has all sufficient order and user data to make the payment, so it processes this data and redirects the user to the page that was specified ( RBI Backend ) inside the iframe.
The RBI backend handles the redirection and returns a hidden script to the user.
...
When the PSP redirects the iframe to the specified url, in this case our backend, it obtains all the data received by the PSP and sends an event to the RBI that the payment has already been released or returned an error.
Paycomet Issues
Iframe redirect the parent page
Our biggest challenge in this implementation is that the page within the iframe contains a script that causes the RBI page to be changed instead of the iframe. To do this, we would have to change the payment flow via the paycomet iframe to deal with this redirection, because once the user is expelled from the RBI page, all of the user's context until then is lost.
...
Another “solution” would be to display this Apple Pay button within a popup, but it would not fit into the layout and would be a suspended button on the user's screen.
Solution
Paycomet fixed this issue and asked us for the AccountId and TerminalId values to make this change.
| Note |
|---|
With this in mind, we need to request that it be changed in the production environments of each registered terminal so that the same problem does not occur in these environments. |