In case you get a PENDING response that contains a REDIRECTURL, redirect the consumer to that URL. Store the REDIRECTSECRET in the session or persistent storage to be able to verify the response later (see Redirect to MerchantRedirectURL - shared secret).

👍

Note

Do not modify the REDIRECTURL. This includes any query parameters which are required for the Payment Gateway to match and authenticate the transaction.

This redirect can be performed either by HTTP GET (302 redirect) or through an auto-submit HTTP POST. The example below shows an auto-submit HTTP POST form:

🚧

Warning

We do not recommend using IFrames. This causes the scheme's pages not to render correctly and not complete the payment.

Make sure you use the device-native web view (Safari for iOS and Chrome for Android) for the in-app rendering of the scheme's HTML pages. Using third-party rendering engines causes the scheme's pages not to render correctly.

Redirecting to MerchantRedirectURL - shared secret

After performing the transaction on the bank's site, the consumer is redirected back to the MerchantRedirectURL specified in your original request (or statically configured for your contract).

👍

Note

We recommend always using a session (and cookie)-based system on the client site. This way a consumer can be identified after being redirected to the site.

The redirect to the MerchantRedirectURL is done using an HTTP GET request. It will pass the following parameters:

The shared secret is only known to you and the Payment Gateway. We pass the REDIRECTSECRET to you in the initial transaction response. Using the algorithm above, you can verify that the Payment Gateway generated the redirection.

After successfully verifying the signature cs you can call GETTXSTATUS to get the transaction result or GETTXSTATUSBYMERCHANTTXID.