Intro
As companies grow, the structure of digital payments also grows and becomes more complex. In many business models, the use of multiple providers needs to be done strategically to optimize the approval of collections with specific characteristics, as well as operating costs.
Intelligent Flows provide Conditional Operators that can be configured to change the way your charges are processed, such as modifying provider priorities or activating an anti-fraud provider to improve security at the time of processing. With this functionality, here at Malga, the charges follow the path defined in the Smart Flow linked to the merchant and payment method being used.
Unique paths within a Smart Flow are called branches. At the moment, each payment method can have up to one active Smart Flow with up to one anti-fraud provider and up to three billing providers per branch.
Conditional Operators
Conditional pperators are flow separators that can be configured using logical comparators in conjunction with data available in the charges to decide which providers will be used to process that charge. Conditionals can use native data from the charges, such as the amount, number of installments and the selected card brand or metadata sent in the metadata field of the charges.
Table of Supported Operators
Logical Operator OR
| Operador | Descrição | Tipo dos Operandos | Exemplo de Expressão |
|---|---|---|---|
| lt (<) | Less than | number | transaction.amount < 5000 |
| gt (>) | More than | number | transaction.amount > 5000 |
| le (<=) | Less or equal to | number | transaction.amount <= 5000 |
| ge (>=) | More of equal to | number | transaction.amount >= 5000 |
| eq (=) | Equal to | number, string | transaction.installments = 0 |
| ne (!=) | Different from | number, string | transaction.installments != 0 |
| and | Logical operator AND | boolean | transaction.installments = 0 and transaction.amount < 5000 |
| or | Logical operator OR | boolean | transaction.installments = 0 or transaction.amount < 5000 |
Available Charge Properties
Charge properties can be used to compose charges processing rules alongside Conditional Operators. The properties currently mapped for use in processing rules are in the following table.
| Property | Type | Description |
|---|---|---|
| amount | number | Amount of charge in cents |
| currency | string | Currency identifier for charge processing, ISO 4217 format |
| cardBin | string | The first six digits of a card, known as the Bank Identification Number or Issuer Identification Number |
| brand | string | Card brand (unique for cards) |
| installments | number | Number of installments to be charged (unique for credit type transactions) |
| metadata | - | PProperty for inserting additional fields in the charge. Properties of type number, number, string, boolean or object can be added |
Using transaction metadata
It is possible to send metadata from the charge for use in your Smart Flows. This property is a special property of the charge that accepts any properties within it, enabling you to process business rules by choosing which providers should process that transaction using the Malga engine.
{
[...],
"paymentFlow": {
"metadata": {
"stringProperty": "value for property 1",
"numericProperty": 10,
"numericProperty2": 10.5,
"listProperty": ["element1", "element2"],
"objectProperty": {
"subProp1": "value"
}
[...]
}
},
[...]
}
Example of Metadata usage
The additional data of the charges are extremely flexible and serve to allow you to process your business rules using Malga's internal engine. For example, if you want to use properties that do not normally exist in a Malga charge, you can add these properties using the metadata field, as shown in the following example:
In this scenario if the value of metadata.daysToEvent is greater than 60 no anti-fraud providers are used to protect the charge. As well as sending the arbitrary daysToEvent property, any property can be sent with a charge to process conditional rules.
| Charge | Antifraud | Provider 1 | Provider 2 | Provider 3 |
|---|---|---|---|---|
| daysToEvent = 61; amount = 550; installments = 2 | - | PagSeguro 2 | PagSeguro 3 | Adyen |
| daysToEvent = 45; amount = 300; installments = 6 | Clearsale 2 | PagSeguro 1 | PagSeguro 3 | Adyen |
| daysToEvent = 70; amount = 1200; installments = 3 | Clearsale 1 | PagSeguro 2 | PagSeguro 3 | Adyen |
info
Although it is possible to send metadata by passing a list of elements or objects nested in metadata for processing, there are still no operators compatible with these types of properties.
Charge Distribution
It is possible to distribute charges in branches of the Intelligent Flow using the math/random property. This property generates a random number between 0 and 1 and can be accessed in conjunction with logical operators to create load distribution rules, as in the following example, where 60% of transactions are sent by the true branch and 40% are sent by the false branch:math/random < 0.6
Behavior of Billing Providers
The Charging Providers are configured in a priority order within the Smart Flows. Once a charge is not properly approved at a provider, if the cause of the error allows it to be retried, the charge goes on to be processed at the next provider configured in the Smart Flow. If there is no new provider to try after the last retry error returned, the charge is returned as failed.
info
Up to three billing providers can be configured in a single branch of your Smart Flow.
Causes of failure can be viwed here.
Behavior of Anti-fraud Providers
In a Smart Flow it is possible to configure Anti-Fraud Providers to protect your transactions and their behavior can be checked in our documentation. Within a single branch of the Smart Flow it is possible to configure only one anti-fraud provider, i.e. it is not possible to process multiple anti-fraud providers for a single charge.
This type of configuration allows you to switch between multiple Anti-Fraud Providers, or even turn off this type of protection, using different strategies for charges of different characteristics. These rules are processed charge by charge according to the characteristics configured in the Smart Flow.
info
The retry based on anti-fraud providers happens at the pre-authorization stage, so once pre-authorized in a provider the transaction ends its life cycle in this provider until the moment of capture or failure.