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:
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:
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.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.The following simplified diagram illustrates the relationship between the main entities of this module.
The payment module has been created to cover the needs of the following business 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.
A BPMN-like description of the process flow, as outlined in the sample scenario.
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:
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.
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).
The following characteristics apply when acting as Collecting PSP.
The following characteristics apply when acting as Technical PSP.
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.