Abstraction Layer for Transaction Data

Wallets using Nautilus do not depend on a specific payment processor, because Nautilus delivers the same, highly normalized, transaction data structure no matter which payment processor is the source of the transaction data.

Overview

Nautilus stands between the payment processor and the wallet, accepting data from the payment processor and transforming it to make it easier for the wallet to consume. Because Nautilus delivers the same data structure, regardless of the payment processor used, a wallet integrated with Nautilus is not dependent on a specific payment processor. Moreover, Nautilus data structures are optimized for use by wallets, making integration with Nautilus faster and easier than integrating with a payment processor’s transaction data feed.

How is the data structured

Nautilus transaction data is highly structured, in contrast to the transaction data delivered by most payment processors. We decided to create a dedicated data structure for each transaction type, containing only the fields relevant to that specific transaction. On the other hand, payment processors usually send all transactions in the same format, regardless of their representation. Consequently, it falls to the wallet to determine which fields are genuinely pertinent to the transaction, leading to potentially serious consequences if it interprets a wrong (but present) field. In Nautilus, if a data field is present, it is inherently applicable to the transaction, and using it is not considered an error.

Nautilus categorizes transactions into the following types when it comes to the action they represent:

  • Account Check
  • PIN operation
  • Debit
  • Credit
  • Balance Inquiry

Each of these transactions has its own dedicated structure (although many of them share some elements). This structure contains only relevant fields.

The data delivered tells the wallet how it should process the transaction

Since Nautilus uses different structures for different transaction types, it also delivers data to different endpoints on the wallet side. For each action performed, the wallet might be required to execute different operations:

  • Authorize a transaction,
  • Acknowledge an authorization advice,
  • Revert an authorization, or
  • Settle a transaction.

Nautilus delivers each action and transaction type to a dedicated endpoint (the actual number of combinations is not a simple product, as not all of them are possible). This way, as soon as the wallet receives data, it knows what is expected of it—whether to simply acknowledge the data, authorize the request, reverse it, or settle it.

Due to different actions and operations required from the wallet, the data expected in return is also different. For example, if the wallet is expected to authorize a transaction, it should return an authorization code. However, for simple acknowledgment operations like settlements, reversals, and advice, a simple reply is sufficient.

Because each transaction type and operation have a dedicated endpoint, Nautilus enforces time limits only on operations that have restricted response times mandated by card schemes. Operations such as simple acknowledgments in settlements, reversals, and advice are not time restricted.