Charge flows are used when you want to charge your customer. Depending on the payment method we then decide if we can charge the customer directly or if we have to send out an e-mail, sms etc to collect his payment details. How and when this happens can be decided in the Charge Flow Levels.
Recurring payment is an interesting concept for customer loyalty and convenience. Especially in the e-commerce sector. Charge Flow is a concept that can be used from your side if you sell goods and you want to control when a client should be charged. In this case you are able to create a transaction over the API using the token (see below for more details). The application is now trying to charge the specified token. If this fails the charge flow process will make sure that your customer is contacted to update the payment information which significantly reduces your workload to implement recurring processes.
|
Important
|
In case you want to sell subscriptions for digital goods have a look at our subscription API that allows you to create, products and do all kinds of different pricing and billing methods. |
You can use Charge Flows also for your call center / webshop integration whenever you do want to collect payment information asynchronous. I. e. you want to send your customers an email that contains a payment link out of your shop in order to not collect the payment informations directly on the phone. This has the great advantage for you that you save transactions fees as MoTo transactions are more expensive and you are able to process payments with all possible payment methods. Charge Flows will then automatically remind your customers depending on your charge flow levels (see below).
We distinguish between three different ways of charging the customer. Charge Flows and Charge Flow levels can be set up under Space > Configuration > Charge Flows.
You have to first set up a charge flow and then associate the different levels to a charge flow. The charge flow level define the process on how you want to charge the customer and if the charge fails how you want to retrieve t the payment information from him.
We offer you three ways on how you can possible charge the customer or retrieve the payment information in case the charge fails or the payment information are not yet collected.
-
Using a Token: A token represents basically a reference to stored payment information inside the platform. In case a customer has an valid associated token we can use the token to charge the customer directly.
-
Asynchronous Charge: Some Payment Methods allow you to charge the client without his interaction. All you need is the relevant payment information (i. e. to send an invoice). In this case we can also charge the customer using the present information.
-
Sending a Link: in case none of the mechanism above is working, a link is sent to the client. The link is pointing to the payment page. There the customer can select any configured payment method and complete the transaction. How and when this link is sent is defined in the Charge Flow Levels. See also Delivery of Payment Link.
The charge flow configuration defines how exactly the above strategies are applied. You might want to adjust the configurations as you need.
A Token represents a reference to stored payment information. Have a look at the Tokenization Documentation to find out how token can be used and applied to transactions.
A charge flow can be created in the back office. Go to Space > Payment > Configuration > Charge Flows and click on Charge Flow to add one.
The charge flow levels come only into play when there is no or not a valid token and the asynchronous charge
was not possible. They determine how and when the transaction information are gathered.
As soon as the charge flow is created you can create a Charge Flow Level. In the Charge Flow Level
you can decide the Type which defines how the customer will be notified. Depending on the Type you do have
the possibility to provide additional settings.
You can create as many Charge Flow Levels as you want. While processing the charge flow all levels
are considered until the merchant has successfully provided the payment information and the state of the
transaction is in the Fulfill state. The charge attempt is considered Failed once all the charge
flow level are processed unsuccessfully.
You have the option to create multiple charge flows for different occasions. You are able to assign conditions under Space > Payment > Configuration > Conditions on the different Charge Flows. To determine the Charge Flow configuration the following steps are taken:
-
The relevant charge flows are determined by applying all configured conditions.
-
The priority of the current level configuration is selected.
-
All level configuration of a particular flow are sorted ascending.
-
We choose the level configuration with the next higher priority as the one of the current level configuration.
|
Important
|
The priority indicates the sort order of the level configurations. A low value indicates that the level configuration is executed before any level with a higher value. Any change to this value affects future level configuration selections. This means if you change the priority the sort order will be assessed once the next level is due. |
Charge Flows can be triggered over the backend or via the API.
You can create transactions out of the application under Space > Payment > Transaction > Create. You can provide the relevant transaction information directly in your browser
Figure 1. How to create a customer not present transaction with charge flows.
Charge Flows can be applied to pending transactions. All you need to do is to create a transaction using the
Transaction Create Service.
Once the transaction is created you can use the Apply Flow Operation on the Charge Flow Service to trigger the charge using a Charge Flow. This will now trigger the charge process as described above.
A charge flow consists of different levels. Each level can have its own type. The type defines if and how the payment link is delivered to the customer. The type is only relevant if the charging was not successful and the customer must provide payment details to complete the transaction.
The following delivery types exist:
-
Email: The email level type sends the payment link by email to the customer. The prerequisite is an email address defined on the transaction. To use this delivery option, the email feature must be activated. -
No Action: This type prevents the delivery of the payment link so it is possible to try to charge the customer with a token without taking any measures in case the charge fails. This is useful for retry strategies. For some payment methods and in some countries, retries are more useful than immediately informing the customer about the failure. -
External Application: The external application type allows to delegate the transmission of the payment link to the customer to an external application. The external application must register a webhook for the entity Charge Flow Level Payment Link. Whenever a charge flow level requires the transmission of a payment link, such an entity is created and the webhook URL is called. The external application listening to the URL can use the Web Service API to retrieve the payment link. The external application then transmits the link to the customer.