Overview

An overview of the Accounting as a Service payment module to accept payments with cards, wallets, and other payment methods in your web shop or mobile application.

The Accounting as a Service payment module is designed to cover the needs of merchants running an online business, such as a web shop or mobile application offering products for sale and consumption. The module is specifically made for providing an easy solution to merchants when dealing with payment functionality and its related sensitive data.

Using the payment module of Accounting as a Service creates the following key advantages:

  • All sensitive data related to customers' financial information that falls under strict regulations such as the Payment Card Industry Data Security Standard (PCI DSS) which is linked to heavy compliance processes is handled separately from the merchant's system and data storage. As a result, your system does not need to be PCI DSS compliant, while at the same time you can offer all types of online payment functionalities to your customers.
  • In its role of acting as the underlying system of Riverty as a distributing payment service provider, Accounting as a Service has been designed to remove the technical burden for merchants by building and maintaining the connections to many different payment methods. By connecting to one distributor, your web shop will be able to accept payment methods of several types.

Main service components

Here is a list of the most important components of the payment module to cover the business requirements of the typical end-to-end process of a payment scenario, usually starting with the customer checking out on your web shop and ending with the financial transaction to be completed to credit the money to the merchant's bank account:

  • Pre-built payment UI: The pre-built payment UI is made of two main parts. A front end component and a corresponding back end component. The former is represented by the front end widget as the core component of the pre-built UI solution that comes along with the payment module of Accounting as a Service. The widget consists of a JavaScript-based UI component that is integrated in your front end, e.g. in your web shop or customer portal. The component is highly customizable and can be adapted to your needs, allowing you to match the styling of your brand, and the language of your shopper. The back end component is referred to as Widget API, as it provides the business logic and necessary end points for the front end widget to work with.
  • Payment processing engine: The payment processing engine is the main component of the payment module. It handles the payment execution process with key tasks such as authorization, capture and debit execution. The core element of the engine is the transaction with each instance handling and representing a request for payment execution. The state machine of the transaction serves to keep track of the progress of each payment execution.
  • Notifications: Accounting as a Service supports the concept of notifications, allowing the merchant to be informed upon certain events happening inside the system. The concept is based around the idea of having different notification types, for which the merchant can provide a URL to be called back whenever an event of such type occurs. In the scope of the payment module, the notification handling has been mainly built on top of the transaction (and its state model) as the core element that needs to be processed by the payment processing engine.
  • Fraud management: The fraud management module is optional and integrated with the payment processing engine, and as such does not provide any dedicated interface to the outside. The module provides a set of control mechanisms to be applied on incoming payments requests to identify and avoid fraud attacks. The module is disabled by default. For more information, please contact us.

Main entities

Before walking through the list of the most important entities of the payment module, you may want to have a look at the list of Accounting as a Service's common main entities shared among all modules. In addition to the common main entities, these are the following key entities, when interacting with the payment module:

  • payment-method: There are a number of ways in which a merchant can receive payments from a customer. Each payment-method represents a specific type of payment, such as payments using a VISA card or payments via PayPal. Accounting as a Service supports a variety of payment methods. Typical types of methods are card payment, online payment or wallet payments.
  • payment-instrument: The payment-instrument brings together the payment-method and its method-specific sensitive payment information (e.g. when paying by VISA card, the name of the cardholder, the card number, the expiration date and the security code will be needed). The information needed as part of the payment-instrument depends on the associated payment-method. The payment-instrument and its data is needed by the payment processing engine to execute the payment and in the scope of a transaction. The payment token refers to a stringified unique identifier of a payment-instrument in Accounting as a Service. The payment token is used to reference the payment-instrument in the scope of a transaction.
  • registration: In order to support reusing a payment-instrument a registration will be needed. Using a registration is required when dealing with recurring payments to ease the payment process for both, the customer and the merchant. The registration token refers to a stringified unique identifier of a registration in Accounting as a Service. The registration token is used to reference the registration in the scope of a transcation.
  • transaction: The transaction is the core element of the payment processing engine. Each transaction represents a request for payment execution that needs to be processed by the engine. As it also serves to monitor the progress and state of a payment execution, the transaction comes along with a state machine. The status information can be retrieved at any point in time via the REST API using the transaction token as the unique identifier of a transaction in Accounting as a Service.

Entity-Relationship-Model

The following simplified diagram illustrates the relationship between the main entities of this module.

ERM-payment_overview__entities

Standard business scenario

The payment module has been created to cover the needs of the following business scenario.

Sample scenario

A customer checks out from a web shop. When it comes to the selection of the payment method, he will be presented with the front end widget from the pre-built UI solution, where he selects his preferred payment method from the list of available payment methods and fills out all required payment details. Once all information has been provided and the payment has been validated by Accounting as a Service, the checkout process can move on, and the customer will be presented by the web shop with a screen to confirm his order. Upon the customer confirming the order, the payment execution takes place and end ups with the customer being informed about the payment confirmation.

Process flow

A BPMN-like description of the process flow, as outlined in the sample scenario.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.

Payment acceptance

To accept payment methods, a merchant needs a payment acceptance contract for each specific payment method. When using Accounting as a Service, the following contract options exist:

  • Direct contract with the payment method provider.
  • A contract with an external so-called "collecting PSP" who bundles contracts and collects funds from the single payment method providers. Collected funds will then be transferred on a regular basis to the merchant.
  • Use AAccounting as a Service as collecting PSP.

Regardless of the payment method to be supported, the merchant needs to technically connect to the related payment method provider. When supporting multiple payment methods, the most efficient and user-friendly way is to make use of a payment service provider that supports all of your payment methods via one interface or widget.

Accounting as a Service has been provided with the flexibility to support all the before mentioned ways of integration via its payment module. Setting up the appropriate configuration of all payment methods in combination with their PSP is part of the onboarding procedure and therefore included in your technical application.

Collecting PSP vs. Technical PSP

When it comes to payment service providers (PSP), there exist different stereotypes of providers having different characteristics. Accounting as a Service can be seen as both, a Collecting PSP (CPSP) and a Technical PSP (TPSP).

Accounting as a Service in the role of a Collecting PSP (CPSP)

The following characteristics apply when acting as Collecting PSP.

  • Accounting as a Service may act as a collecting service provider, settling provides professional services connected with the collection of funds processed through Alternative Payment Methods (APMs) directly to the merchant bank
  • No own contracts need to be signed with single payment providers, only one contract with Accounting as a Service is necessary.
  • Accounting as a Service collects funds for the payment methods in scope on a trusted collecting bank account owned by Accounting as a Service.
  • Merchant receives payout of funds from Accounting as a Service on the bank account, which is managed and reconciled by the accounting module of Accounting as a Service.
  • Reporting and/or merchant support is fully provided by Accounting as a Service.
Accounting as a Service in the role of a Technical PSP (TPSP)

The following characteristics apply when acting as Technical PSP.

  • Accounting as a Service only provides a technical gateway a merchant can use to process payment methods in scope.
  • Merchant must sign own contracts with each payment providers or with a 3rd party collecting PSP.
  • Funds are transferred into the bank account, which is managed and reconciled by the accounting module of Accounting as a Service.
  • Reporting and/or merchant support is provided by 3rd party payment provider(s).

Transaction states

While the transaction belongs to the main entities of the payment module, it is the core element of the payment processing engine and serves to keep track of every incoming payment request while being processed by the engine. For this reason, the status field is one of the key properties of the transaction.

The transaction status refers to the state machine, as shown in the following illustration. (For better readability, intermediate states are indicated with dotted lines).

Notification handling of the payment module is based on the state model of the transaction (and registration). For more information, check out the page about notifications.

High-level process description
An overview using BPMN to describe the process flow
Checkout the BPMN illustration to get an overview of the process, including the various activities and participating main actors.