Skip to main content

Smart Flows Orchestration

As companies grow their digital payments infrastructure also grows and get more complex. In many business models the adoption of multiple providers must be done in a strategic way to optimize charge approve rates for charges with specific caracteristics, as well as the operation costs.

The Smart Flows Orchestration put at your disposal Conditional Operators which can be configured to alter the behavior of your charges, such as changing providers priority or activating an anti-fraud provider to improve security, as they are being processed.

With this feature the charges being processed by Malga will follow the behavior defined in the Smart Flow linked to the Merchant and Payment Method being used.

Unique paths inside a Smart Flow are called Branches. As of now, each Payment Method can have up to one active Smart Flow with up to one anti-fraud provider and up to three payment providers by each branch.


New Smart Flows must be created with the assistence of the Malga support team. If you wish to change the configurations of your Smart Flow, please contact the Malga support team.

Conditional Operators

The Conditional Operators are flow splitters which can be configured using logic components in addition to data available in the charges to define which providers should be used to process that charge. These operators can use native data from charges, such as the amount, installments quantity and the brand of the selected card or metadata sent in the metadata field inside the charges payload.

Table of Supported Operators

OperatorDescriptionOperands TypeExpression Example
lt (<)Lesser thannumbertransaction.amount < 5000
gt (>)Greater thannumbertransaction.amount > 5000
le (<=)Lesser than or equalnumbertransaction.amount <= 5000
ge (>=)Greater than or equalnumbertransaction.amount >= 5000
eq (=)Equal tonumber, stringtransaction.installments = 0
ne (!=)Not Equal tonumber, stringtransaction.installments != 0
andLogic operator ANDbooleantransaction.installments = 0 and transaction.amount < 5000
orLogic operator ORbooleantransaction.installments = 0 or transaction.amount < 5000

Available charge properties

Most charge properties may be used to compose charge processing rules with the Conditional Operators. All the available properties can be found in the table that follows.

amountnumberCharged amount in cents
currencystringCurrency identifier using the ISO 4217 format
cardBinstringSix first card digits, also known as Bank Identification Number or Issuer Identification Number
brandstringCard brand (exclusive to cards)
installmentsnumberInstallments quantity for the charge (exclusive to credit transactions)
metadata.*-Property used for insertion of additional fields in the charge. It is possible to add properties of the following type: number, string, boolean, object ou list

Using transactions metadata

It is possible to send metadata with your charges to use it in the Smart Flow. This charge property accepts any other aditional property inside of it, allowing you to process business rules for choosing which providers should process any given transaction using Malga's engine.

"metadata": {
"stringProperty": "value for property 1",
"numericProperty": 10,
"numericProperty2": 10.5,
"listProperty": ["element1", "element2"],
"objectProperty": {
"subProp1": "value"

Metadata usage example

Additional charge data are extremelly flexible and allows you to process business rules using Malga's internal engine. For example, if you'd like to use properties that don't usually exist in a Malga charge, it is possible to add these properties using the metadata field, as shown in the following example:

Smart Flow Example

In this case if the value of the metadata.daysToEvent is greater than 60 there will be no anti-fraud providers used to protect this charge. In the same way the arbitrary property daysToEvent is sent within the charge, any other property sent in the metadata field can be used to process conditional rules.

ChargeAnti-fraudFirst ProviderSecond ProviderThird Provider
daysToEvent = 61; amount = 550; installments = 2-PagSeguro 2PagSeguro 3Adyen
daysToEvent = 45; amount = 300; installments = 6Clearsale 2PagSeguro 1PagSeguro 3Adyen
daysToEvent = 70; amount = 1200; installments = 3Clearsale 1PagSeguro 2PagSeguro 3Adyen

Even though it is possible to send metadata with list or nested objects, there still aren't compatible operators for these property types.

Load Balancing

It is possible to distribute charges to different branches of the Smart Flow using the math/random property. This property generates a random number between 0 and 1 and can be used in combination with the logic operators to create load balancing rules, such as the example that follows, where 60% of the transactions are sent through the true branch and 40% are sent through the false branch: math/random < 0.6

Load Balancing Example

Payment Providers Behavior

The Payment Providers are configured in a priority order inside the Smart Flow. When the charge is not properly approved in a provider, if the root cause of the error is retryable, the charge follows on to be processed by the next configured provider in the Smart Flow. If there isn't any new provider configured after the last retryable error, the charge is returned as failed.


There can be up to three Payment Providers configured in a unique branch of your Smart Flow.

Possible failure causes table

Rejection MotiveRetryable?

Anti-fraud Provider Behavior

In a Smart Flow it is possible to configure Anti-fraud Providers to protect your transactions. Their behavior can be verified in our documentation. In a single branch of the Smart Flow there can only be one configured anti-fraud provider. 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 this type of protection off, using different strategies for charges with different caracteristics. These rules are processed on a transaction basis, following the Smart Flow configuration.


Retries based on anti-fraud providers happen in the pre authorization stage, so once the transaction is pre authorized in a provider it will finish it's whole lifecycle within the same provider until it is captured or failed.