App and Payments

      App and Payments

        Article summary

        Apps are increasingly being used in combination with the Buckaroo payment environment. The use of Buckaroo's hosted payment page is not a problem because it is responsive and forms itself within the space that is given for it. The problem arises when redirecting to the payment environments of the various acquirers. Think, for example, of the banks that offer iDEAL, but also, for example, the 3D Secure environments of the various Credit Card providers.

        The secure environments of banks and credit card companies often wish to break out. This breakout is mandated by the banks to ensure that the authorization of the payment takes place without the App being able to intercept or store the details. If the payer cannot be routed to the App, he will still have to log into the bank or credit card environment via the regular method. This often leads to an extra moment of withdrawal in the purchase process because a Random Reader, tan code or other mechanism is often required.

        Note for developers

        The following link is interesting for the developers of the App(s) where an explanation is given about the behavior of an operating system in combination with an App : Handling Page Navigation.
        This webpage explains how with the definition of a Webview the standard behavior of the operating system of a device (such as a telephone or tablet) can be overwritten with another action. Below is an example of a Webview in which only the Buckaroo URLs are displayed in a browser and the rest is opened in the associated (banking) App.

        Copy the code below into the Merchant App definition

        private class BuckarooWebViewClient extends WebViewClient {
        public boolean shouldOverrideUrlLoading(WebView view, String url) {
        if (Uri.parse(url).getHost().equals("")) {
        // This is a Buckaroo URL, try to open the bank app
        Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse(url));
        return true;
        // Otherwise, the link is not a Buckaroo URL so do not override; let my WebView load the page
        return false;
        } }


        Buckaroo supports JSON as a frequently used interface for mobile Apps. A request is sent to Buckaroo containing the desired payment method and the data necessary to start the payment method as immediately as possible. For iDEAL, this can be, for example, the payer's bank and for Credit Cards the type of card. The login details of the bank or the Credit Card details are then entered by the payer on one of the following environments / screens:

        • The iDEAL payment environment of the specified or chosen bank of the payer
        • The Client Side Encryption module where the Credit Card data is entered in a PCI compliant manner. The alternative is to use Buckaroo's Hosted Payment Page to enter the details of the CreditCards.
        • The 3D Secure page of the credit card company that performs the card-not-present security check
        • The payer's PayPal environment where the details of the PayPal wallet are entered

        After the payer has completed the payment cycle, a redirect is performed. This redirect takes place to a URL that was indicated to Buckaroo when the transaction was submitted. This returns the user to the Merchant's App. The result of the payment is also sent with the redirect. Based on this, the Merchant can show the correct message to the payer in the App. Think of a thank you page for a successful payment and a "try again" for payments that have failed. By means of a push message, the result can be passed on to the backend of the Merchant via a separate/own channel. This push contains the same data as the redirect, so that the delivery of the desired products or services can be started or maintained immediately.

        Was this article helpful?

        What's Next