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.
info
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
| Operator | Description | Operands Type | Expression Example |
|---|---|---|---|
| lt (<) | Lesser than | number | transaction.amount < 5000 |
| gt (>) | Greater than | number | transaction.amount > 5000 |
| le (<=) | Lesser than or equal | number | transaction.amount <= 5000 |
| ge (>=) | Greater than or equal | number | transaction.amount >= 5000 |
| eq (=) | Equal to | number, string | transaction.installments = 0 |
| ne (!=) | Not Equal to | number, string | transaction.installments != 0 |
| and | Logic operator AND | boolean | transaction.installments = 0 and transaction.amount < 5000 |
| or | Logic operator OR | boolean | transaction.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.
| Property | Type | Description |
|---|---|---|
| amount | number | Charged amount in cents |
| currency | string | Currency identifier using the ISO 4217 format |
| cardBin | string | Six first card digits, also known as Bank Identification Number or Issuer Identification Number |
| brand | string | Card brand (exclusive to cards) |
| installments | number | Installments 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:
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.
| Charge | Anti-fraud | First Provider | Second Provider | Third Provider |
|---|---|---|---|---|
| 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
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
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.
info
There can be up to three Payment Providers configured in a unique branch of your Smart Flow.
Possible failure causes table
| Rejection Motive | Retryable? |
|---|---|
fraud_suspect | YES |
generic | YES |
insuficient_funds | YES |
invalid_cvv | YES |
issuer_not_available | YES |
restricted_card | YES |
try_again | YES |
card_not_supported | NO |
expired_card | NO |
fraud_confirmed | NO |
invalid_amount | NO |
invalid_data | NO |
invalid_installment | NO |
invalid_merchant | NO |
invalid_pin | NO |
lost_card | NO |
not_permitted | NO |
pickup_card | NO |
pin_try_exceeded | NO |
security_violation | NO |
service_not_allowed | NO |
stolen_card | NO |
transaction_not_allowed | NO |
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.
info
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.