Overview#
Once you have activated the connections you want to use in your payment processing, you need to have at least one flow published before submitting transactions to Tuna. In case you don't, you will get an error message in your checkout
A flow stands for how and when each connection will take place in your payment processing. For each flow, you must define at least the Filters and the Authorization Scheme, but can also include a Fraud Verification and Custom Connections.
You can define as many flows as you want, but please have in mind that all transactions will be submitted first to the flows on the top and then to the ones in the bottom until they find a flow that matches their profile. To change the processing priority of your flows, just define the order desired and submit them to be published.
note
Except for the homologation account, all your accounts will have a Default Flow in a draft status. It is mandatory to define and publish the Default Flow. It will always be located in the bottom of your published Flows, therefore it will work as your else case when the transaction does not match the criteria of the previous Flows.
Inside a Flow, the transaction will follow the order of the steps defined in the top to the bottom until the payment is either captured or rejected.
Filters#
They are a set of criteria that defines the profile of the transactions that will be processed by the flow. They are always located at the top of the flow and they are the first thing considered in the payment processing. In case the transaction does not match the filter criteria, it will not be processed by the current flow and will be submitted to the next flow.
note
For the Default Flow, the Filters are pre-set with Transaction IS EQUAL TO All transactions and it cannot be changed.
You can combine AND and OR operators in the Filters to define the profile of the transactions that will be processed by the flow. For example:
If the transaction has: Category.Name IN {Smartphones, Alcohol Drinks} AND Payment.Amount GREATER THAN R$ 1.000,00.
Except for credit card payments, the Filter criterion most used is the Payment.method.type because it will restrict the options you can use as the Authorization Scheme. However, there are other Filter criteria available:
| Filter Name | Type | Description |
|---|---|---|
| Category.Name | String | Item category defined by you. In case you want to include two or more categories, inform all of them separated by comma. Ex: Smartphones,Computer. |
| Operating.System | Picklist | The Operating System of the customer. Ex: iOS, Android. |
| Payment.Amount | Number (double) | Value the customer paid in this transaction. Amount in local currency . Ex: 100.75 stands for R$100.75 |
| PaymentData.PaymentMethods.Amount | Number (double) | Value the customer paid with a specific payment method. Amount in local currency. Ex: 80.01 stands for $80,01 |
| Installments | Select | Number of installments of the payment. Ex: 5. |
| Payment.method.type | Picklist | Name of the payment type. Ex: CreditCard. |
| BIN | Number | The customer's Card Bank Identification Number. Ex: 4040. |
| Brand.Name | Picklist | The customer's Card Brand. Ex: Master, Visa, Amex. |
| Customer.Data.Email | String | The customer's Email on this transaction. It can be an exact (for in and not in) or a flexible (for contains) match. For lists, inform all of them separated by comma. Ex: (contains) _@tuna.uy_ OR (in) _tinaturner@tuna.uy,jonhdoe@tuna.uy_ |
| BillingAddress.State | String | The customer's Billing Address State. If more than one state, inform all of them separated by comma. Ex: SC,SP. |
| BillingAddress.City | String | The customer's Billing Address City. If more than one state, inform all of them separated by comma. Ex: Florianópolis,São Paulo. |
| BillingAddress.Postal_code | Number | The customer's Billing Address Postal Code, without special characters. If more than one state, inform all of them separated by comma. Ex: 88035320 |
| DeliveryAddress.State | String | The customer's Delivery Address State. If more than one state, inform all of them separated by comma. Ex: SC,SP. |
| DeliveryAddress.City | String | The customer's Delivery Address City. If more than one state, inform all of them separated by comma. Ex: Florianópolis,São Paulo. |
| DeliveryAddress.Postal_code | Number | The customer's Delivery Address Postal Code, without special characters. If more than one state, inform all of them separated by comma. Ex: 88035320 |
| Custom.name | String | You can set up any custom value from your integration. Ex: Custom.userid |
| PaymentData.AntiFraud.Data.{Name} | String | Variables implemented by you via api at PaymentData.AntiFraud.Data.{name}. |
| Operator Name | Type | Description |
|---|---|---|
| all in | List | All values must be in the list. It is used to compare a list with a list. |
| all not in | List | None of the values can be in the list. It is used to compare a list with a list. |
| any in | List | At least one of the values must be in the list. It is used to compare a list with a list. |
| any not in | List | None of the values can be in the list. It is used to compare a list with a list. |
| in | List | The value must be in the list. It is used to compare a value with a list. |
| not in | List | The value cannot be in the list. It is used to compare a value with a list. |
| greater than | Value | Numeric field. |
| greater than or equal to | Value | Numeric field. |
| less than | Value | Numeric field. |
| less than or equal to | Value | Numeric field. |
| is equal to | Value | Numeric field. |
| starts with | Value | Text field, but in some cases it can be just digits. |
| contains | Value | Text field. |
| not contains | Value | Text field. |
Authorization Scheme#
It defines which payment connections take care of the payment authorization and capture. Therefore, it is mandatory to include one Authorization Scheme in each Flow. You can place your authorization scheme anywhere between the Filters and the final action.
You need at least one payment connection active on the Connection menu to create an Authorization Scheme, but you can add more than one depending on your retrial and volume allocation strategy. Only active payment connections will be available to be included in an Authorization Scheme. Make sure you include all the payment connections required for the payment methods you want to offer to your customers in your checkout.
Retrial: a retrial strategy makes sense when you want to submit the transaction to another payment connection when the previous one failed to respond or denied the transaction. You can add an attempt, a retrial and a second retrial in each Authorization Scheme.
note
A payment might be rejected due to several reasons. In some cases, it can be reverted. Therefore, to increase the odds of having a better authorization rate, you should consider adding a retrial strategy.
Volume allocation: In case you have a volume threshold negotiated with a payment connection, you should consider defining the percentage of the transaction you want to submit to each provider in the Authorization Scheme you will use in the Flow. You can define your volume allocation between your retrial strategy.
tip
If you have better connection fees for Visa with a specific payment connection provider, you can set the filter as Brand.Name IN Visa AND Payment.method.type IN CreditCard and include this connection in the Authorization Scheme included in the Flow.
For credit cards, the payment connection can just authorize or actually capture the payment. Authorization means that the payment was approved, but the customer has not been charged. Capture means that the payment was approved and the customer was charged.
Depending on the fraud risk or commercial condition agreed with your connections, it might make sense to first run your anti-fraud analysis before capturing the payment or to just authorize the payment before submitting the transaction to the anti-fraud analysis. You have the flexibility to place your Authorization Scheme and set your anti-fraud variables in the Flow to better reflect your payment processing strategy.
Fraud Verification#
It is your strategy to prevent fraud occurrences, such as chargebacks and attacks from malicious users or bots. This setup is optional, but highly recommended specially for credit card payments. You can add as many anti-fraud connections as you want. You just need to activate them in the Connection menu to make it available to be used in your Flows. You can place one or more Fraud Verification anywhere between the Filters and the final action.
The Fraud Verification setup is similar to the Filters one. The main difference is that you must inform what action to take when the filter condition is true. You can add variables from to the anti-fraud connections included in the Flow, from the Filters and from any other custom connection that you hired. The operators for Filters are the same for Fraud Verification.
note
With the Fraud Verification you can define, for example, that you just want to capture transactions from the Electronic category if the score from the anti-fraud is above 80.
Custom Connections#
It is a connection developed on demand. It can be a custom integration or feature developed just for your business that you want to use in your Flows. Please contact Tuna at golive@tuna.uy for further details.
In this section you will also find by default an empty template that you can include variables from Filters and Fraud Verification. It is optional and can be placed anywhere between the Filters and the final action.
Publish Flows#
You need Flows published to process payments on your website. Otherwise, you will get an error in your checkout if you do not.
You can create as many Flows as you want, select the ones that you actually want to use, define their order and submit them to be published. For now, you can submit Flows to be published, but we need to evaluate your Flows before actually publishing them. You will know that they are ready to use because we will give you feedback about it, but you can also check whether your Flow menu reflects the changes you have asked for. You will see a green dot right after the name of the Flows published. In case you have any questions, please contact us at golive@tuna.uy.
note
Make sure you have covered all the scenarios and payment methods you want for your checkout. The Default Flow should be designed to be as generic as possible since all the cases not covered by the Flows on the top will be processed by it.
Flow Metrics#
Once you have Flows published and start to process real transactions, you will see some KPIs for each Flow from the moment they were published up to now: Income, Approved, Fees and Fraud Costs. You will see both the rate and the absolute value for these metrics. In addition to that, in Transactions and Total Value, you will also find the percentage and the absolute amount of the payment processed by each Flow and in total.
These metrics are designed to support you in evaluating the results of your Flows. They are specially useful if you are running an A/B Test and want to compare the actual results of the hypothesis you are testing.
Transactions#
It stands for the total of the payment methods processed by the Flows. In case an order was divided into two or more payment methods or transactions, it will count as one. It includes all transactions (i.e. both approved and rejected ones).
Total Value#
It stands for the total amount of payment methods processed by the Flows. In case an order of R$100 was divided into two payment methods or transactions, but just R$60 was submitted to Tuna, it will consider only R$ 60 in the total amount. It includes all transactions (i.e. both approved and rejected ones).
This metric also appears in the Flow level in absolute value and as percentage of the total amount.
Income#
It informs the amount of the approved transactions minus the fees and fraud costs. The percentage stands for the ratio between the Income and the Total Value. This metric will give you an overview about your margin for all the transactions processed at Flow level.
Approved#
It informs the amount of the approved transactions. The percentage stands for the ratio between the Approved and Total Value. This metric will give you an overview about your authorization rate for all the transactions processed at Flow level.
Fees#
It informs the amount of the processing costs of the connections you included in the Flow. The percentage stands for the ratio between the Fees and the Approved. This metric will give you an overview about how much your connection fees represent from your approved transactions at Flow level.
note
This metric considers the fees set up in the connection fee tab located just below the connection configuration tab. Therefore, it is highly recommended that you keep all your connection fees updated.
Fraud Costs#
It informs the amount of the cost related to fraud, such as chargeback. The percentage stands for the ratio between the Fraud Costs and Approved. This metric will give you an overview about the efficiency of your anti-fraud strategy at Flow level.
note
Chargeback is when a cardholder reports to the card issuer that he does not recognize that charge. But if it is a legitimate transaction, you can start a chargeback dispute. Keep in mind that the dispute process can be subject to additional charges on top of the processing fees (Fees).