White label wallet providers

Overview

Developing a white-label product for card issuing, intended for sale to unknown customers from as many countries as possible, is a very challenging task. A significant part of its complexity arises from the inability to use a single payment processor.

For this reason, companies seeking to develop a white-label wallet product typically choose one of several possible approaches:

• Integrate with a single payment processor,
• Do not integrate with any payment processor, keeping their product in an almost-finished state.

Each of these approaches has its upsides and downsides.

Approach 1: Integrate with a single payment processor

If you choose to integrate with a single payment processor, one obvious upside is that, at least for some clients, you have a completely finished product. Another benefit is that as soon as you have somebody purchasing your product, you can, with their agreement, actually demonstrate how your product really works to new clients.

On the other hand, if you make a mistake with your choice of the payment processor, it might be very difficult to find a first (and the most important) client, and you might end up having to do a lot of extra development to adapt your product to other payment processors. This extra development also brings concerns about testing the product thoroughly on a new payment processor.

Approach 2: Don’t fully integrate with a single payment processor, keep your product almost finished

This approach makes more sense in terms of resource spending: you develop the product to a basic level, and then invest extra effort only when necessary and in the required direction. However, it comes with its own challenges:

• The product is not fully finished, so each potential sale involves additional effort (and expenses) that can be hard to estimate.
• Since the product is not fully finished, it cannot be easily demonstrated to potential clients.

What is the right approach?

The Perfect solution would be the one that guarantees several things:

• Thorough testing of the product,
• Easy demonstration to potential clients without relying on existing clients,
• A fully finished product ready for timely delivery to clients,
• Compatibility with any territory and payment processor,
• Minimal team effort in maintaining payment processor integration.

Now, let's see how our solution with Nautilus aligns with these goals.

Nautilus comes with a transaction simulator and a test engine

Nautilus features a built-in transaction simulator, an indispensable tool for developing any product intended for card issuance. It allows you to simulate a wide range of card transactions, aiding in the debugging of your wallet. This tool is instrumental for inspecting your system's behavior in minute detail.

The test engine facilitates both performance and functional testing. By grouping individual functional tests together, you can create regression tests that provide confidence in your system's behavior as you advance with your build.

With Nautilus you can easily demonstrate your product

Nautilus includes a comprehensive transaction simulator that serves not only for simulating transactions during development but also for demonstrating card transactions to potential clients. With a wallet integrated with Nautilus, there is no distinction between transactions from the production mode's payment processor and those from Nautilus simulator during development. This allows you to fully showcase your product using Nautilus alone.

For instance, your wallet can update balances, display updated monetary statistics to potential clients, and if you're developing a mobile application that interacts with the wallet, it can receive push notifications, and more. Leveraging Nautilus' test engine, which can submit numerous transactions quickly, you can even demonstrate your system's behavior as if it were used by hundreds or thousands of people.

In essence, using just Nautilus allows you to completely demonstrate your product to clients without the need for actual money or cards, and without requiring a contract with a payment processor or BIN issuer.

Minimal development when changing the payment processor/territory

If you are using Nautilus to develop your wallet product, you also rely on Nautilus data feed for transaction data. However, as Nautilus doesn't serve as an abstraction layer for card creation and control, you will need to stub code for creating cards or changing their status. Fortunately, this is usually a straightforward task, as both card creation and control functions are simple RPCs with two possible outcomes.

When it comes to transaction data, the structure of data that Nautilus returns does not depend on any payment processor. Once you integrate with Nautilus, it will handle the data from any payment processor your system works with using the same feed.

Using Nautilus makes you independent of the payment processor for transaction data integration (which is the challenging part), but it does require a little bit of development to replace card creation and control stubs with calls to the chosen payment processor. The small amount of development needed can usually be accurately estimated in advance.

Work with any payment processor

Once again, because Nautilus delivers its data in a structure that doesn’t depend on the payment processor, if you develop a wallet with Nautilus, it will be able to work in any country with any payment processor with just minimal changes.

No need to maintain the payment processor integration

If your product is integrated with Nautilus, you don’t have to worry about maintaining transaction data integration with a payment processor. Whatever changes there might be needed over time, we will take care of them, while making sure to keep our interface stable.

Nautilus interface is fully versioned, so no matter what extensions are introduced in a newer version, the version you integrated with stays exactly as it was, and you don’t need to migrate to the new one unless you want to.